這兩年網絡直播特別火，國內很多網絡直播平臺都做的風生水起，特別是熊貓直播、斗魚、花椒等。投資人為了把平臺做大做強，大把大把燒錢，搞的很多小伙伴們都很心動想跳槽去做直播。作為構建直播平臺的基礎之一 -—— 傳輸協議，我們該如何選擇呢？那么首先我們就要了解這些協議的原理及特點。
RTMP——Real Time Messaging Protocol（實時消息傳輸協議）
RTMP是由Adobe公司提出的，在互聯網TCP/IP五層體系結構中應用層，RTMP協議是基于TCP協議的，也就是說RTMP實際上是使用TCP作為傳輸協議。TCP協議在處在傳輸層，是面向連接的協議，能夠為數據的傳輸提供可靠保障，因此數據在網絡上傳輸不會出現丟包的情況。不過這種可靠的保障也會造成一些問題，也就是說前面的數據包沒有交付到目的地，后面的數據也無法進行傳輸。幸運的是，目前的網絡帶寬基本上可以滿足RTMP協議傳輸普通質量視頻的要求。
RTMP傳輸的數據的基本單元為Message，但是實際上傳輸的最小單元是Chunk（消息塊），因為RTMP協議為了提升傳輸速度，在傳輸數據的時候，會把Message拆分開來，形成更小的塊，這些塊就是Chunk。
消息（Message）的結構
Message結構分析
1.Message Type：它是一個消息類型的ID，通過該ID接收方可以判斷接收到的數據的類型，從而做相應的處理。Message Type ID在1-7的消息用于協議控制，這些消息一般是RTMP協議自身管理要使用的消息，用戶一般情況下無需操作其中的數據。Message Type ID為8，9的消息分別用于傳輸音頻和視頻數據。Message Type ID為15-20的消息用于發送AMF編碼的命令，負責用戶與服務器之間的交互，比如播放，暫停等。
2.Playload Length： 消息負載的長度，即音視頻相關信息的的數據長度，4個字節
3.TimeStamp：時間戳，3個字節。
4.Stream ID：消息的唯一標識。拆分消息成Chunk時添加該ID，從而在還原時根據該ID識別Chunk屬于哪個消息。
5.Message Body：消息體，承載了音視頻等信息。
消息塊（Chunk）
通過上圖可以看出，消息塊在結構上與與消息類似，有Header和Body。
1.Basic Header：基本的頭部信息，在頭部信息里面包含了chunk stream ID（流通道Id，用來標識指定的通道）和chunk type（chunk的類型）。
2.Message Header：消息的頭部信息，包含了要發送的實際信息（可能是完整的，也可能是一部分）的描述信息。Message Header的格式和長度取決于Basic Header的chunk type。
3.Extended TimeStamp：擴展時間戳。
4.Chunk Data：塊數據。
RTMP在傳輸數據的時候，發送端會把需要傳輸的媒體數據封裝成消息，然后把消息拆分成消息塊，再一個一個進行傳輸。接收端收到消息塊后，根據Message Stream ID重新將消息塊進行組裝、組合成消息，再解除該消息的封裝處理就可以還原出媒體數據。由此可以看出，RTMP收發數據是以Chunk為單位，而不是以Message為單位。需要注意的是，RTMP發送Chunk必須是一個一個發送，后面的Chunk必須等前面的Chunk發送完成。
RTSP
RTSP（Real Time Streaming Protocol）是TCP/UDP協議體系中的一個應用層協議，由哥倫比亞大學, 網景和RealNetworks公司提交的IETF RFC標準.該協議定義了一對多應用程序如何有效地通過IP網絡傳輸多媒體數據。RTSP在體系結構上位于RTP和RTCP之上，它使用TCP或者RTP完成數據傳輸，目前市場上大多數采用RTP來傳輸媒體數據。
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消息交互過程
C表示RTSP客戶端,S表示RTSP服務端
第一步：查詢服務器端可用方法
C->S OPTION request //詢問S有哪些方法可用
S->C OPTION response //S回應信息的public頭字段中包括提供的所有可用方法
第二步：得到媒體描述信息
C->S DESCRIBE request //要求得到S提供的媒體描述信息
S->C DESCRIBE response //S回應媒體描述信息，一般是sdp信息
第三步：建立RTSP會話
C->S SETUP request //通過Transport頭字段列出可接受的傳輸選項，請求S建立會話
S->C SETUP response //S建立會話，通過Transport頭字段返回選擇的具體轉輸選項，并返回建立的Session ID;
第四步：請求開始傳送數據
C->S PLAY request //C請求S開始發送數據
S->C PLAY response //S回應該請求的信息
第五步： 數據傳送播放中
S->C 發送流媒體數據 // 通過RTP協議傳送數據
第六步：關閉會話，退出
C->S EARDOWN request //C請求關閉會話
S->C TEARDOWN response //S回應該請求
上述的過程只是標準的、友好的rtsp流程，但實際的需求中并不一定按此過程。 其中第三和第四步是必需的！第一步，只要服務器和客戶端約定好有哪些方法可用，則option請求可以不要。第二步，如果我們有其他途徑得到媒體初始化描述信息（比如http請求等等），則我們也不需要通過rtsp中的describe請求來完成。
HLS ——?HTTP Live Streaming
HTTP Live Streaming（縮寫是HLS）是一個由蘋果公司提出的基于Http協議的的流媒體網絡傳輸協議。是蘋果公司QuickTime X和iPhone軟件系統的一部分。它的工作原理是把整個流分成一個個小的基于HTTP的文件來下載，每次只下載一些。當媒體流正在播放時，客戶端可以選擇從許多不同的備用源中以不同的速率下載同樣的資源，允許流媒體會話適應不同的數據速率。在開始一個流媒體會話時，客戶端會下載一個包含元數據的extended M3U (m3u8)playlist文件，用于尋找可用的媒體流。
HLS協議的優點：
1.跨平臺性：支持iOS/Android/瀏覽器，通用性強。
2.穿墻能力強：由于HLS是基于HTTP協議的，因此HTTP數據能夠穿透的防火墻或者代理服務器HLS都可以做到，基本不會遇到被防火墻屏蔽的情況。
3.切換碼率快（清晰度）：自帶多碼率自適應，客戶端可以選擇從許多不同的備用源中以不同的速率下載同樣的資源，允許流媒體會話適應不同的數據速率。客戶端可以很快的選擇和切換碼率，以適應不同帶寬條件下的播放。
3.負載均衡：HLS基于無狀態協議（HTTP），客戶端只是按照順序使用下載存儲在服務器的普通TS文件，做負責均衡如同普通的HTTP文件服務器的負載均衡一樣簡單。
HLS的缺點：
1.實時性差：蘋果官方建議是請求到3個片之后才開始播放。所以一般很少用HLS做為互聯網直播的傳輸協議。假設列表里面的包含5個 ts 文件，每個 TS 文件包含5秒的視頻內容，那么整體的延遲就是25秒。蘋果官方推薦的ts時長時10s，所以這樣就會大改有30s（n x 10）的延遲。
2.文件碎片化嚴重：對于點播服務來說, 由于 TS 切片通常較小, 海量碎片在文件分發, 一致性緩存, 存儲等方面都有較大挑戰.
HLS協議由三部分組成：HTTP+M3U8+TS
HTTP：傳輸協議
M3U8：索引文件
TS：音視頻媒體信息,視頻的編碼格式為H.264，音頻格式為AAC。
HLS的工作原理：
1.填入請求m3u8的url，通過http請求。
2.sever返回一個m3u8的播放列表，該列表包含了5段數據的url。
3.客戶端解析m3u8播放列表后，按順序的拿每一段數據的url去獲取ts流。
HLS如何切片問題
Media encoder將視頻源中的視頻數據轉碼到目標編碼格式（H264）的視頻數據，之后，在stream segmenter模塊將視頻切片。切片的結果就是index file（m3u8）和ts文件，如上圖。
參考文獻：
