流媒体传输知识整理（二）

RTSP协议

即时串流协定（也成实时流传输协议）Real Time Streaming Protocol，属应用层协议。RTSP在体系结构上位于RTP和RTCP之上，它使用TCP或RTP完成数据传输。

基于文本的协议，用于在客户端和服务器端建立和协商实时流会话。

HTTP与RTSP相比，HTTP传送HTML，而RTSP传送的是多媒体数据。HTTP请求由客户机发出，服务器作出响应；使用RTSP时，客户机和服务器都可以发出请求，即RTSP可以是双向的。

 

RTSP是用来控制声音或影像的多媒体串流协议，并允许同时多个串流需求控制，传输时所用的网络通讯协定并不在其定义的范围内，服务器端可以自行选择使用TCP或UDP来传送串流内容，它的语法和运作跟HTTP 1.1类似，但并不特别强调时间同步，所以比较能容忍网  RTSP络延迟。而前面提到的允许同时多个串流需求控制（Multicast），除了可以降低服务器端的网络用量，更进而支持多方视讯会议（Video Conference）。因为与HTTP1.1的运作方式相似，所以代理服务器〈Proxy〉的快取功能〈Cache〉也同样适用于RTSP，并因RTSP具有重新导向功能，可视实际负载情况来转换提供服务的服务器，以避免过大的负载集中于同一服务器而造成延迟

该协议目的在于控制多个数据发送连接，为选择发送通道，如UDP、组播UDP与TCP，提供途径，并为选择基于RTP上发送机制提供方法。

实时流协议（RTSP）建立并控制一个或几个时间同步的连续流媒体。尽管连续媒体流与控制流交换是可能的，通常它本身并不发送连续流。换言之，RTSP充当多媒体服务器的网络远程控制。RTSP连接没有绑定到传输层连接，如TCP。在RTSP连接期间，RTSP用户可打开或关闭多个对服务器的可传输连接以发出RTSP请求。此外，可使用无连接传输协议，如UDP。RTSP流控制的流可能用到RTP，但RTSP操作并不依赖用于携带连续媒体的传输机制。

协议支持的操作如下：

(1)从媒体服务器上检索媒体：用户可通过HTTP或其它方法提交一个演示描述。如演示是组播，演示式就包含用于连续媒体的的组播地址和端口。如演示仅通过单播发送给用户，用户为了安全应提供目的地址。

(2)媒体服务器邀请进入会议：媒体服务器可被邀请参加正进行的会议，或回放媒体，或记录其中一部分，或全部。这种模式在分布式教育应用上很有用，会议中几方可轮流按远程控制按钮。

(3)将媒体加到现成讲座中：如服务器告诉用户可获得附加媒体内容，对现场讲座显得尤其有用。如HTTP/1.1中类似，RTSP请求可由代理、通道与缓存处理。

 

RTP、RTCP、RTSP在OSI模型中的位置：

 

 

RTP、RTCP、RTSP数据处理流程：

  RTSP 协议：

RTSP协议的数据发送不占用协议带宽，并且以不同的协议发送。

HTTP是一个不对称协议，客户端发出请求，服务器应答。在RTSP中，客户端和服务器都可发出请求，且请求是有状态的。

RTSP在任何情况下，必须保持一定状态，以便在请求确认后的很长时间内，仍可设置参数，控制媒体流。虽然大多数实时媒体采用RTP作为传输协议，但RTSP并不绑定RTP。

 

1、初始化

在建立连接之前，客户端应向服务器提出测试请求，即要求服务器向客户端发送相应的测试数据包。初始化的目的，是为了获取客户端和服务器之间的一些网络参数，估测基本网络状况，并以此选择相应的网络传输协议，使客户端获得最佳观看效果。

接到这个请求之后，服务器将根据自身情况进行如下测试：

● 利用同客户端建立的RTSP通道，采用TCP协议，下发测试数据包。

● 采用UDP协议，向客户端下发测试数据包。

测试数据包仅做测试用，上面带有相应的时间和顺序信息，其内部数据并无任何意义。

需要向RTSP增加一个新的方法TEST，以支持这种传输前的测试工作。

2、TCP传输

如果在TCP测试中，客户端反馈良好，即丢包率在可承受范围之内，并且在规定时间内到达，那么就认为客户端同服务器之间的网络状况良好， 可以采用RTP over TCP的方式发送数据。由于TCP没有丢包（其自身具有重传机制），网络状况又属于良好，因此客户端将有较高的视听享受。

当子网内存在防火墙时，就需要采用RTSP附加数据传输方式。即把音视频数据直接打包，在RTSP通信信道内传输。这种传输方式也存在一定的问题：

● 传输过程中，只是把音视频文件当成一个普通文件来处理，而没有考虑到它的音视频特性，不利于以后的扩展。

● 音频与视频文件没有分离，不利于某些特殊需求的场合。例如，客户端需要对音、视频做不同的处理。

● 客户端的反馈和RTSP的控制信息也是通过同一条RTSP信道传送，因此控制效率不高。

因此，一般情况下，都默认使用RTP over TCP的方式发送数据。

3、UDP传输

如果在TCP测试中，客户端的反馈存在比较大的问题，即网络情况不理想，就应该考虑进行UDP测试。

目前初步采取的措施，在服务器端准备了两种码率的视频文件——高码率和低码率。

收到客户端的TEST方法后，将采用UDP协议下发测试包。采取的策略是每间隔2秒，下发一个1500字节的UDP数据包。当丢包率处于一定范围（75％～85％）之内，就认为客户端的网络状况基本良好，可以下发高码率的电影文件;否则，认为测试不成功，由于网络状况的限制，仅对客户端下发低码率的电影文件。

在基于UDP的播放过程中，可能会出现轻微的马赛克，这是完全可以接受的。这些马赛克出现的主要原因是：

● 不可靠连接造成的网络丢包，为客户端被动丢包。

● 高质量文件（DVD－>MP4）的高数据量，使得客户端解码线程和显示线程出现拥塞，从而出现客户端主动丢包。

但从整体而言，UDP传输消耗的带宽，要比TCP小许多。在一般的视频点播要求下，使用基于UDP的传输线路，是完全可以满足要求的。

4、传输反馈

在传输过程中，主要采取的方式是RTP over TCP或RTP over UDP，因此，在RTP端口之外，还存在一个回传端口RTCP。

在服务器收到客户端的RTCP回传信息后，需要对其进行判断。如果客户端的丢包率、解码率等指标在一定限度之下，就认为目前传送的视频文件可令客户端获得最大程度的音视频享受;否则，考虑改为传输更低码率的视频文件或放弃这次RTSP会话，以避免更大范围的拥塞。

 

RTMP协议

实时消息传送协议，为Adobe Systems公司为flash播放器和服务器间音频、视频和数据传输开发的私有协议。该协议建立在TCP或者轮询HTP协议之上。此协议就像是一个用来封装数据包（数据可为AMF格式数据或者FLV中的音、视频数据）的容器。采用的默认端口为1935.此协议的详细构造参考官方文档：http://wwwimages.adobe.com/www.adobe.com/content/dam/Adobe/en/devnet/rtmp/pdf/rtmp_specification_1.0.pdf

数据代码示例(Flex代码)：

var videoInstance:Video = your_video_instance;

var nc:NetConnection = new NetConnection();

var connected:Boolean = nc.connect("rtmp:/localhost/myapp");

var ns:NetStream = new NetStream(nc);

videoInstance.attachVideo(ns);

ns.play("flvName");

注意，由于TCP协议数据的传输有数据包大小的限制（一般为1500字节），而RTMP协议中，一个消息的数据包可能很大，（一个视频帧可能就比较大，几十KB或者几百KB），这样，一个RTMP协议包，TCP一次是传输不完的，所以需要分成多个chunk传输，也就是说，一个RTMP协议数据包可能有多个chunk包，然而，一个RTMP协议数据包只能有一个head头和消息体。

它有三种变种：

　　1)工作在TCP之上的明文协议，使用端口1935；

　　2)RTMPT封装在HTTP请求之中，可穿越防火墙；

3)RTMPS类似RTMPT，但使用的是HTTPS连接；