计算机网络中传输协议和控制协议

二、流媒体传输协议

为了保证流式传输的顺利进行,必须要有合适的传输协议做保证。传统的TCP协议有较大的开销,不适合承担实时数据的传输,因此在流式传输的实现方案中,一般采用HTTP/TCP来传输流媒体控制信息,而用RTP/UDP来传输实时流媒体数据。目前比较常见的流媒体传输协议主要有以下几种。

1.资源预留协议(RSVP)

RSVP是一种用于互联网上质量整合服务的协议。它允许主机在网络上请求特殊服务质量用于特殊应用程序数据流的传输。路由器也使用RSVP发送服务质量(QOS)请求给所有结点(沿着流路径)并建立和维持这种状态以提供请求服务。通常RSVP请求将会引起每个节点数据路径上的资源预留。

RSVP原本是为网络会议应用开发的,后被IETF集成到通用的资源预留解决方案中。它主要由施乐公司、MIT和加州大学信息科学学院共同研制, 1994年11月研制完成, 1997年9月成为Internet标准。

RSVP协议的基本工作原理是这样的:首先,发送端向接收端发送RSVP信息, RSVP信息与其他IP数据包通过各个路由器到达目的地;接收端收到后,根据自身情况逆向发起资源预留请求,资源预留信息沿原来信息包相反的方向对沿途各个路由器进行资源预留。

2.实时传输协议RTP与RTCP

RTP为数据提供了具有实时特征的终端对终端传送服务,如在组播或单播网络服务下的交互式视音频或仿真数据。应用程序在UDP上执行RTP以便使用其多路技术和检验服务。RTP可以与其他适合的底层网络或传输协议共同使用。如果底层网络提供组播分配,那么RTP可以使用该组播分配支持多路目标文件的数据传输。

RTP原本用于网络中传输语音,由Lawrence Berkeley国际实验室的网络研究工作组于1991年2月发布, 1995年11月正式成为Internet标准。微软的Netmeeting软件就基于RTP协议。

RTP协议的基本工作原理是通过时戳同步多个数据流,为接收端确定数据到达,保证时间的一致性,通过顺序编号在接收端对数据包进行顺序重组,通过源标识确定数据的准确发送源,通过有效载荷,接收端播放数据内容。但是RTP本身并不能为按顺序传送数据包提供可靠的传送机制,也不提供流量控制或拥塞控制,它依靠RTCP提供这些服务。RTCP实时传输控制协议是RTP协议的姊妹协议,它是一个控制协议,本身并不能传输流媒体数据而只能与RTP协议共同合作,为顺序传输数据包提供可靠的传送机制,同时对网络流量和阻塞进行相关控制。

3.实时流协议(RTSP)

RTSP协议是一个类似于HTTP的应用层协议,它定义了如何有效地通过IP网络传送多媒体数据,是在服务器和客户端建立和控制音视频流的协议,在服务器与客户端之间扮演着远程遥控器的角色,或者说它就是通过客户端对服务器上的音视频流做播放、录制等操作的请求。

RTSP协议是由RealNetworks公司、网景公司和哥伦比亚大学共同于1996年10月开发的, 1998年4月正式成为Internet标准。目前得到了网景、Apple、IBM、SUN等公司的广泛支持,但是它一直没有得到计算机软件业巨头微软公司的认可。

RTSP协议与HTTP协议在功能上有一定的重叠,最明显的交叉是在流媒体内容的发布上,流媒体内容大多是通过网页进行发布的,目前的协议规范同时允许网页服务器和流媒体服务器支持RTSP实现。例如,演示描述可通过HTTP协议传输而真正的流媒体数据通过RTSP协议获取,这样减少了基于浏览器情况下的往返传递时间。当然也支持独立的RTSP服务器与客户端通信。但是RTSP协议与HTTP协议还是有区别的,它是为了在IP网络上传输流媒体数据而创建的协议,具有流协议的基本特征。第一, RTSP协议是一个对称协议,即在RTSP中,客户端和服务器都可发出请求,而且请求是有状态的,但HTTP协议是一个不对称协议,客户端发出请求,服务器应答。其次, RTSP协议在任何情况下,必须保持一定状态,以便在请求确认后的很长时间内,仍可设置参数,控制媒体流,而HTTP协议是一个无状态协议。