构建直播平台的基础之一-—传输协议该如何选择？

这三年网路直播非常火，国外好多网路直播平台都做的风生水起，非常是熊猫直播、斗鱼、花椒等。投资人为了把平台做大做强，大把大把烧钱数据传输协议有哪些，搞的好多男子伴们都很心动想跳槽去做直播。作为建立直播平台的基础之一-——传输合同，我们该怎么选择呢？这么首先我们就要了解那些合同的原理及特性。

RTMP——RealTimeMessagingProtocol（实时消息传输合同）

RTMP是由Adobe公司提出的，在互联网TCP/IP五层体系结构中应用层，RTMP合同是基于TCP合同的，也就是说RTMP实际上是使用TCP作为传输合同。TCP合同在处在传输层，是面向联接的合同，还能为数据的传输提供可靠保障，因而数据在网路上传输不会出现丢包的情况。不过这些可靠的保障也会导致一些问题，也就是说上面的数据包没有交付到目的地，旁边的数据也难以进行传输。辛运的是，目前的网路带宽基本上可以满足RTMP合同传输普通质量视频的要求。

RTMP传输的数据的基本单元为Message，然而实际上传输的最小单元是Chunk（消息块），由于RTMP合同为了提高传输速率，在传输数据的时侯，会把Message分拆开来，产生更小的块，这种块就是Chunk。

消息（Message）的结构

消息的结构

Message结构剖析

1.MessageType：它是一个消息类型的ID，通过该ID接收方可以判定接收到的数据的类型，因而做相应的处理。MessageTypeID在1-7的消息用于合同控制，这种消息通常是RTMP合同自身管理要使用的消息，用户通常情况下无需操作其中的数据。MessageTypeID为8，9的消息分别用于传输音频和视频数据。MessageTypeID为15-20的消息用于发送AMF编码的命令，负责用户与服务器之间的交互，例如播放，暂停等。

2.PlayloadLength：消息负载的宽度，即音视频相关信息的的数据宽度，4个字节

3.TimeStamp：时间戳，3个字节。

4.StreamID：消息的惟一标示。分拆消息成Chunk时添加该ID，因而在还原时按照该ID辨识Chunk属于那个消息。

5.MessageBody：消息体，承载了音视频等信息。

消息块（Chunk）

消息块结构

通过上图可以看出，消息块在结构上与与消息类似，有Header和Body。

1.BasicHeader：基本的腹部信息，在腹部信息上面包含了chunkstreamID（流通道Id数据传输协议有哪些，拿来标示指定的通道）和chunktype（chunk的类型）。

2.MessageHeader：消息的腹部信息，包含了要发送的实际信息（可能是完整的，也可能是一部份）的描述信息。MessageHeader的格式和厚度取决于BasicHeader的chunktype。

3.ExtendedTimeStamp：扩充时间戳。

4.ChunkData：块数据。

RTMP在传输数据的时侯，发送端会把须要传输的媒体数据封装成消息，之后把消息拆分成消息块，再一个一个进行传输。接收端收到消息块后，按照MessageStreamID重新将消息块进行组装、组合成消息，再解除该消息的封装处理就可以还原出媒体数据。由此可以看出，RTMP收发数据是以Chunk为单位，而不是以Message为单位。须要注意的是，RTMP发送Chunk必须是一个一个发送，旁边的Chunk必须等上面的Chunk发送完成。

RTSP

RTSP（RealTimeStreamingProtocol）是TCP/UDP合同体系中的一个应用层合同，由阿根廷学院,网景和RealNetworks公司递交的IETFRFC标准.该合同定义了一对多应用程序怎样有效地通过IP网路传输多媒体数据。RTSP在体系结构上坐落RTP和RTCP之上，它使用TCP或则RTP完成数据传输，目前市场上大多数采用RTP来传输媒体数据。

RTSP和RTP/RTCP之间是哪些关系呢？下边是一个精典的流媒体传输流程图

RTSP和RTP/RTCP之间的关系

一次基本的RTSP操作过程:

首先，顾客端联接到流服务器并发送一个RTSP描述命令（DESCRIBE）。

流服务器通过一个SDP描述来进行反馈，反馈信息包括流数目、媒体类型等信息。

顾客端再剖析该SDP描述，并为会话中的每一个流发送一个RTSP构建命令(SETUP)，RTSP构建命令告诉服务器顾客端用于接收媒体数据的端口。流媒体联接构建完成后，

顾客端发送一个播放命令(PLAY)，服务器就开始在UDP上传送媒体流（RTP包）到顾客端。在播放过程中顾客端还可以向服务器发送命令来控制快进、快退和暂停等。

最后，顾客端可发送一个中止命令(TERADOWN)来结束流媒感受话。

由上图可以看出，RTSP处于应用层，而RTP/RTCP处于传输层。RTSP负责构建以及控制会话，RTP负责多媒体数据的传输。而RTCP是一个实时传输控制合同，配合RTP做控制和流量监控。封装发送端及接收端（主要）的统计报表。这种信息包括丢包率，接收晃动等信息。发送端按照接收端的反馈信息做响应的处理。RTP与RTCP相结合似乎保证了实时数据的传输，但也有自己的缺点。最明显的是当有许多用户一起加入会话进程的时侯，因为每位参与者都周期发送RTCP信息包，致使RTCP包猖獗(flooding)。

RTSP的恳求报文结构如右图

RTSP恳求报文结构

简单的RTSP消息交互过程

C表示RTSP顾客端,S表示RTSP服务端

第一步：查询服务器端可用方式

C->SOPTIONrequest//寻问S有什么方式可用

S->COPTIONresponse//S回应信息的public头数组中包括提供的所有可用方式

第二步：得到媒体描述信息

C->SDESCRIBErequest//要求得到S提供的媒体描述信息

S->CDESCRIBEresponse//S回应媒体描述信息，通常是sdp信息

第三步：构建RTSP会话

C->SSETUPrequest//通过Transport头数组列举可接受的传输选项，恳请S构建会话

S->CSETUPresponse//S构建会话，通过Transport头数组返回选择的具体转输选项，并返回构建的SessionID;

第四步：恳求开始传送数据

C->SPLAYrequest//C恳求S开始发送数据

S->CPLAYresponse//S回应当恳求的信息

第五步：数据传送播放中

S->C发送流媒体数据//通过RTP合同传送数据

第六步：关掉会话，退出

C->SEARDOWNrequest//C恳求关掉会话

S->CTEARDOWNresponse//S回应当恳求

上述的过程只是标准的、友好的rtsp流程，但实际的需求中并不一定按此过程。其中第三和第四步是必需的！第一步，只要服务器和顾客端约定好有什么方式可用，则option恳求可以不要。第二步，假如我们有其他途径得到媒体初始化描述信息（例如http恳求等等），则我们也不须要通过rtsp中的describe恳求来完成。