這兩年網(wǎng)絡(luò)直播特別火，國(guó)內(nèi)很多網(wǎng)絡(luò)直播平臺(tái)都做的風(fēng)生水起，特別是熊貓直播、斗魚(yú)、花椒等。投資人為了把平臺(tái)做大做強(qiáng)，大把大把燒錢，搞的很多小伙伴們都很心動(dòng)想跳槽去做直播。作為構(gòu)建直播平臺(tái)的基礎(chǔ)之一 -—— 傳輸協(xié)議，我們?cè)撊绾芜x擇呢？那么首先我們就要了解這些協(xié)議的原理及特點(diǎn)。

RTMP——Real Time Messaging Protocol（實(shí)時(shí)消息傳輸協(xié)議） RTMP是由Adobe公司提出的，在互聯(lián)網(wǎng)TCP/IP五層體系結(jié)構(gòu)中應(yīng)用層，RTMP協(xié)議是基于TCP協(xié)議的，也就是說(shuō)RTMP實(shí)際上是使用TCP作為傳輸協(xié)議。

TCP協(xié)議在處在傳輸層，是面向連接的協(xié)議，能夠?yàn)閿?shù)據(jù)的傳輸提供可靠保障，因此數(shù)據(jù)在網(wǎng)絡(luò)上傳輸不會(huì)出現(xiàn)丟包的情況。不過(guò)這種可靠的保障也會(huì)造成一些問(wèn)題，也就是說(shuō)前面的數(shù)據(jù)包沒(méi)有交付到目的地，后面的數(shù)據(jù)也無(wú)法進(jìn)行傳輸。幸運(yùn)的是，目前的網(wǎng)絡(luò)帶寬基本上可以滿足RTMP協(xié)議傳輸普通質(zhì)量視頻的要求。

RTMP傳輸?shù)臄?shù)據(jù)的基本單元為Message，但是實(shí)際上傳輸?shù)淖钚卧荂hunk（消息塊），因?yàn)镽TMP協(xié)議為了提升傳輸速度，在傳輸數(shù)據(jù)的時(shí)候，會(huì)把Message拆分開(kāi)來(lái)，形成更小的塊，這些塊就是Chunk。 消息（Message）的結(jié)構(gòu)

?

Message結(jié)構(gòu)分析

1.Message Type：它是一個(gè)消息類型的ID，通過(guò)該ID接收方可以判斷接收到的數(shù)據(jù)的類型，從而做相應(yīng)的處理。Message Type ID在1-7的消息用于協(xié)議控制，這些消息一般是RTMP協(xié)議自身管理要使用的消息，用戶一般情況下無(wú)需操作其中的數(shù)據(jù)。

Message Type ID為8，9的消息分別用于傳輸音頻和視頻數(shù)據(jù)。Message Type ID為15-20的消息用于發(fā)送AMF編碼的命令，負(fù)責(zé)用戶與服務(wù)器之間的交互，比如播放，暫停等。

2.Playload Length： 消息負(fù)載的長(zhǎng)度，即音視頻相關(guān)信息的的數(shù)據(jù)長(zhǎng)度，4個(gè)字節(jié) 3.TimeStamp：時(shí)間戳，3個(gè)字節(jié)。

4.Stream ID：消息的唯一標(biāo)識(shí)。拆分消息成Chunk時(shí)添加該ID，從而在還原時(shí)根據(jù)該ID識(shí)別Chunk屬于哪個(gè)消息。

5.Message Body：消息體，承載了音視頻等信息。 消息塊（Chunk）

通過(guò)上圖可以看出，消息塊在結(jié)構(gòu)上與與消息類似，有Header和Body。

1.Basic Header：基本的頭部信息，在頭部信息里面包含了chunk stream ID（流通道Id，用來(lái)標(biāo)識(shí)指定的通道）和chunk type（chunk的類型）。

2.Message Header：消息的頭部信息，包含了要發(fā)送的實(shí)際信息（可能是完整的，也可能是一部分）的描述信息。Message Header的格式和長(zhǎng)度取決于Basic Header的chunk type。

3.Extended TimeStamp：擴(kuò)展時(shí)間戳。

4.Chunk Data：塊數(shù)據(jù)。 RTMP在傳輸數(shù)據(jù)的時(shí)候，發(fā)送端會(huì)把需要傳輸?shù)拿襟w數(shù)據(jù)封裝成消息，然后把消息拆分成消息塊，再一個(gè)一個(gè)進(jìn)行傳輸。接收端收到消息塊后，根據(jù)Message Stream ID重新將消息塊進(jìn)行組裝、組合成消息，再解除該消息的封裝處理就可以還原出媒體數(shù)據(jù)。由此可以看出，RTMP收發(fā)數(shù)據(jù)是以Chunk為單位，而不是以Message為單位。需要注意的是，RTMP發(fā)送Chunk必須是一個(gè)一個(gè)發(fā)送，后面的Chunk必須等前面的Chunk發(fā)送完成。

RTSP RTSP（Real Time Streaming Protocol）是TCP/UDP協(xié)議體系中的一個(gè)應(yīng)用層協(xié)議，由哥倫比亞大學(xué), 網(wǎng)景和RealNetworks公司提交的IETF RFC標(biāo)準(zhǔn).該協(xié)議定義了一對(duì)多應(yīng)用程序如何有效地通過(guò)IP網(wǎng)絡(luò)傳輸多媒體數(shù)據(jù)。RTSP在體系結(jié)構(gòu)上位于RTP和RTCP之上，它使用TCP或者RTP完成數(shù)據(jù)傳輸，目前市場(chǎng)上大多數(shù)采用RTP來(lái)傳輸媒體數(shù)據(jù)。

RTSP和RTP/RTCP之間是什么關(guān)系呢？下面是一個(gè)經(jīng)典的流媒體傳輸流程圖

?

一次基本的RTSP操作過(guò)程: 首先，客戶端連接到流服務(wù)器并發(fā)送一個(gè)RTSP描述命令（DESCRIBE）。

流服務(wù)器通過(guò)一個(gè)SDP描述來(lái)進(jìn)行反饋，反饋信息包括流數(shù)量、媒體類型等信息。 客戶端再分析該SDP描述，并為會(huì)話中的每一個(gè)流發(fā)送一個(gè)RTSP建立命令(SETUP)，RTSP建立命令告訴服務(wù)器客戶端用于接收媒體數(shù)據(jù)的端口。

流媒體連接建立完成后， 客戶端發(fā)送一個(gè)播放命令(PLAY)，服務(wù)器就開(kāi)始在UDP上傳送媒體流（RTP包）到客戶端。 在播放過(guò)程中客戶端還可以向服務(wù)器發(fā)送命令來(lái)控制快進(jìn)、快退和暫停等。 最后，客戶端可發(fā)送一個(gè)終止命令(TERADOWN)來(lái)結(jié)束流媒體會(huì)話。

由上圖可以看出，RTSP處于應(yīng)用層，而RTP/RTCP處于傳輸層。RTSP負(fù)責(zé)建立以及控制會(huì)話，RTP負(fù)責(zé)多媒體數(shù)據(jù)的傳輸。而RTCP是一個(gè)實(shí)時(shí)傳輸控制協(xié)議，配合RTP做控制和流量監(jiān)控。封裝發(fā)送端及接收端（主要）的統(tǒng)計(jì)報(bào)表。這些信息包括丟包率，接收抖動(dòng)等信息。發(fā)送端根據(jù)接收端的反饋信息做響應(yīng)的處理。

文章最后掃馬可以領(lǐng)取免費(fèi)學(xué)習(xí)資料

?

RTP與RTCP相結(jié)合雖然保證了實(shí)時(shí)數(shù)據(jù)的傳輸，但也有自己的缺點(diǎn)。最顯著的是當(dāng)有許多用戶一起加入會(huì)話進(jìn)程的時(shí)候，由于每個(gè)參與者都周期發(fā)送RTCP信息包，導(dǎo)致RTCP包泛濫(flooding)。 RTSP的請(qǐng)求報(bào)文結(jié)構(gòu)如下圖

?

簡(jiǎn)單的RTSP消息交互過(guò)程

C表示RTSP客戶端,S表示RTSP服務(wù)端 第一步：查詢服務(wù)器端可用方法 C->S OPTION request //詢問(wèn)S有哪些方法可用 S->C OPTION response //S回應(yīng)信息的public頭字段中包括提供的所有可用方法

第二步：得到媒體描述信息 C->S DESCRIBE request //要求得到S提供的媒體描述信息 S->C DESCRIBE response //S回應(yīng)媒體描述信息，一般是sdp信息

第三步：建立RTSP會(huì)話 C->S SETUP request //通過(guò)Transport頭字段列出可接受的傳輸選項(xiàng)，請(qǐng)求S建立會(huì)話 S->C SETUP response //S建立會(huì)話，通過(guò)Transport頭字段返回選擇的具體轉(zhuǎn)輸選項(xiàng)，并返回建立的Session ID;

第四步：請(qǐng)求開(kāi)始傳送數(shù)據(jù) C->S PLAY request //C請(qǐng)求S開(kāi)始發(fā)送數(shù)據(jù) S->C PLAY response //S回應(yīng)該請(qǐng)求的信息

第五步： 數(shù)據(jù)傳送播放中 S->C 發(fā)送流媒體數(shù)據(jù) // 通過(guò)RTP協(xié)議傳送數(shù)據(jù)

第六步：關(guān)閉會(huì)話，退出 C->S EARDOWN request //C請(qǐng)求關(guān)閉會(huì)話 S->C TEARDOWN response //S回應(yīng)該請(qǐng)求 上述的過(guò)程只是標(biāo)準(zhǔn)的、友好的rtsp流程，但實(shí)際的需求中并不一定按此過(guò)程。 其中第三和第四步是必需的！第一步，只要服務(wù)器和客戶端約定好有哪些方法可用，則option請(qǐng)求可以不要。第二步，如果我們有其他途徑得到媒體初始化描述信息（比如http請(qǐng)求等等），則我們也不需要通過(guò)rtsp中的describe請(qǐng)求來(lái)完成。

HLS —— HTTP Live Streaming HTTP Live Streaming（縮寫是HLS）是一個(gè)由蘋果公司提出的基于Http協(xié)議的的流媒體網(wǎng)絡(luò)傳輸協(xié)議。是蘋果公司QuickTime X和iPhone軟件系統(tǒng)的一部分。它的工作原理是把整個(gè)流分成一個(gè)個(gè)小的基于HTTP的文件來(lái)下載，每次只下載一些。當(dāng)媒體流正在播放時(shí)，客戶端可以選擇從許多不同的備用源中以不同的速率下載同樣的資源，允許流媒體會(huì)話適應(yīng)不同的數(shù)據(jù)速率。在開(kāi)始一個(gè)流媒體會(huì)話時(shí)，客戶端會(huì)下載一個(gè)包含元數(shù)據(jù)的extended M3U (m3u8)playlist文件，用于尋找可用的媒體流。

HLS協(xié)議的優(yōu)點(diǎn)： 1.跨平臺(tái)性：支持iOS/Android/瀏覽器，通用性強(qiáng)。 2.穿墻能力強(qiáng)：由于HLS是基于HTTP協(xié)議的，因此HTTP數(shù)據(jù)能夠穿透的防火墻或者代理服務(wù)器HLS都可以做到，基本不會(huì)遇到被防火墻屏蔽的情況。 3.切換碼率快（清晰度）：自帶多碼率自適應(yīng)，客戶端可以選擇從許多不同的備用源中以不同的速率下載同樣的資源，允許流媒體會(huì)話適應(yīng)不同的數(shù)據(jù)速率。客戶端可以很快的選擇和切換碼率，以適應(yīng)不同帶寬條件下的播放。 3.負(fù)載均衡：HLS基于無(wú)狀態(tài)協(xié)議（HTTP），客戶端只是按照順序使用下載存儲(chǔ)在服務(wù)器的普通TS文件，做負(fù)責(zé)均衡如同普通的HTTP文件服務(wù)器的負(fù)載均衡一樣簡(jiǎn)單。

HLS的缺點(diǎn)： 1.實(shí)時(shí)性差：蘋果官方建議是請(qǐng)求到3個(gè)片之后才開(kāi)始播放。所以一般很少用HLS做為互聯(lián)網(wǎng)直播的傳輸協(xié)議。假設(shè)列表里面的包含5個(gè) ts 文件，每個(gè) TS 文件包含5秒的視頻內(nèi)容，那么整體的延遲就是25秒。蘋果官方推薦的ts時(shí)長(zhǎng)時(shí)10s，所以這樣就會(huì)大改有30s（n x 10）的延遲。 2.文件碎片化嚴(yán)重：對(duì)于點(diǎn)播服務(wù)來(lái)說(shuō), 由于 TS 切片通常較小, 海量碎片在文件分發(fā), 一致性緩存, 存儲(chǔ)等方面都有較大挑戰(zhàn).

HLS協(xié)議由三部分組成：HTTP+M3U8+TS HTTP：傳輸協(xié)議 M3U8：索引文件 TS：音視頻媒體信息,視頻的編碼格式為H.264，音頻格式為AAC。 HLS的工作原理：

?1.填入請(qǐng)求m3u8的url，通過(guò)http請(qǐng)求。 2.sever返回一個(gè)m3u8的播放列表，該列表包含了5段數(shù)據(jù)的url。 3.客戶端解析m3u8播放列表后，按順序的拿每一段數(shù)據(jù)的url去獲取ts流。

?

HLS如何切片問(wèn)題 Media encoder將視頻源中的視頻數(shù)據(jù)轉(zhuǎn)碼到目標(biāo)編碼格式（H264）的視頻數(shù)據(jù)，之后，在stream segmenter模塊將視頻切片。切片的結(jié)果就是index file（m3u8）和ts文件，如上圖。

總結(jié)

以上是生活随笔為你收集整理的视频传输协议详解（RTMP、RTSP、HLS）的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。