上篇我們講述了如何讓直播內(nèi)容以“最短”路徑從主播到觀眾上，傳輸層面獲得***延遲，在本篇中我們會(huì)介紹直播應(yīng)用層協(xié)議及傳輸層協(xié)議的選擇以及對(duì)直播體驗(yàn)影響的分析。

直播協(xié)議選擇

國(guó)內(nèi)常見(jiàn)公開的直播協(xié)議有幾個(gè)：RTMP、HLS、HDL(HTTP-FLV)、RTP，我們來(lái)逐一介紹。

RTMP協(xié)議：是Adobe的專利協(xié)議，現(xiàn)在大部分國(guó)外的CDN已不支持。在國(guó)內(nèi)流行度很高。原因有幾個(gè)方面：1、開源軟件和開源庫(kù)的支持穩(wěn)定完整。如斗魚主播常用的OBS軟件，開源的librtmp庫(kù)，服務(wù)端有nginx-rtmp插件。2、播放端安裝率高。只要瀏覽器支持FlashPlayer就能非常簡(jiǎn)易的播放RTMP的直播，協(xié)議詳解可以Google了解。相對(duì)其他協(xié)議而言，RTMP協(xié)議初次建立連接的時(shí)候握手過(guò)程過(guò)于復(fù)雜(底層基于TCP，這里說(shuō)的是RTMP協(xié)議本身的交互)，視不同的網(wǎng)絡(luò)狀況會(huì)帶來(lái)給首開帶來(lái)100ms以上的延遲?；赗TMP的直播一般內(nèi)容延遲在2~5秒。

HTTP-FLV協(xié)議：即使用HTTP協(xié)議流式的傳輸媒體內(nèi)容。相對(duì)于RTMP，HTTP更簡(jiǎn)單和廣為人知，而且不擔(dān)心被Adobe的專利綁架。內(nèi)容延遲同樣可以做到2~5秒，打開速度更快，因?yàn)镠TTP本身沒(méi)有復(fù)雜的狀態(tài)交互。所以從延遲角度來(lái)看，HTTP-FLV要優(yōu)于RTMP。

HLS 協(xié)議：即Http Live Streaming，是由蘋果提出基于HTTP的流媒體傳輸協(xié)議。HLS有一個(gè)非常大的優(yōu)點(diǎn)：HTML5可以直接打開播放;這個(gè)意味著可以把一個(gè)直播鏈接通過(guò)微信等轉(zhuǎn)發(fā)分享，不需要安裝任何獨(dú)立的APP，有瀏覽器即可，所以流行度很高。社交直播APP，HLS可以說(shuō)是剛需，下來(lái)我們分析下其原理 。

基于HLS的直播流URL是一個(gè)m3u8的文件，里面包含了最近若干個(gè)小視頻TS(一種視頻封裝格式，這里就不擴(kuò)展介紹)文件，如http://www.ucloud.cn/helloworld.m3u8 是一個(gè)直播留鏈接，其內(nèi)容如下：

#EXTM3U

#EXT-X-VERSION:1

#EXT-X-TARGETDURATION:10

#EXT-X-MEDIA-SEQUENCE:0

#EXTINF:3,

4.ts

#EXTINF:8,

6.ts

#EXTINF:8,

8.ts

#EXTINF:8,

10.ts

假設(shè)列表里面的包含5個(gè)TS文件，每個(gè)TS文件包含5秒的視頻內(nèi)容，那么整體的延遲就是25秒。當(dāng)然可以縮短列表的長(zhǎng)度和單個(gè)TS文件的大小來(lái)降低延遲，***來(lái)說(shuō)可以縮減列表長(zhǎng)度為1，1秒內(nèi)容的m3u8文件，但是極易受網(wǎng)絡(luò)波動(dòng)影響造成卡頓。通過(guò)公網(wǎng)的驗(yàn)證，目前按同城網(wǎng)絡(luò)可以做到比較好的效果是5~7秒的延遲，也是綜合流暢度和內(nèi)容延遲的結(jié)果。那么HTML5是否可以有更低延遲直接打開的直播流技術(shù)呢?我們?cè)?**會(huì)探討這個(gè)問(wèn)題。

RTP協(xié)議：即Real-time Transport Protocol，用于Internet上針對(duì)多媒體數(shù)據(jù)流的一種傳輸層協(xié)議。實(shí)際應(yīng)用場(chǎng)景下經(jīng)常需要RTCP(RTP Control Protocol)配合來(lái)使用，可以簡(jiǎn)單理解為RTCP傳輸交互控制的信令，RTP傳輸實(shí)際的媒體數(shù)據(jù)。RTP在視頻監(jiān)控、視頻會(huì)議、IP電話上有廣泛的應(yīng)用，因?yàn)橐曨l會(huì)議、IP電話的一個(gè)重要的使用體驗(yàn)：內(nèi)容實(shí)時(shí)性強(qiáng)。對(duì)比與上述3種或?qū)嶋H是2種協(xié)議，RTP和它們有一個(gè)重要的區(qū)別就是默認(rèn)是使用UDP協(xié)議來(lái)傳輸數(shù)據(jù)，而RTMP和HTTP是基于TCP協(xié)議傳輸。為什么UDP 能做到如此實(shí)時(shí)的效果呢?關(guān)于TCP和UDP差別的分析文章一搜一大把，這里不在贅述，簡(jiǎn)單概括：

UDP：?jiǎn)蝹€(gè)數(shù)據(jù)報(bào)，不用建立連接，簡(jiǎn)單，不可靠，會(huì)丟包，會(huì)亂序

TCP：流式，需要建立連接，復(fù)雜，可靠 ，有序

實(shí)時(shí)音視頻流的場(chǎng)景不需要可靠保障，因此也不需要有重傳的機(jī)制，實(shí)時(shí)的看到圖像聲音，網(wǎng)絡(luò)抖動(dòng)時(shí)丟了一些內(nèi)容，畫面模糊和花屏，完全不重要。TCP為了重傳會(huì)造成延遲與不同步，如某一截內(nèi)容因?yàn)橹貍?，?dǎo)致1秒以后才到，那么整個(gè)對(duì)話就延遲了1秒，隨著網(wǎng)絡(luò)抖動(dòng)，延遲還會(huì)增加成2秒、3秒，如果客戶端播放是不加以處理將嚴(yán)重影響直播的體驗(yàn)。

總結(jié)一下：在直播協(xié)議的選擇中，如果選擇是RTMP或HTTP-FLV則意味著有2~5秒的內(nèi)容延遲，但是就打開延遲開，HTTP-FLV 要優(yōu)于RTMP。HLS則有5~7秒的內(nèi)容延遲。選擇RTP進(jìn)行直播則可以做到1秒內(nèi)的直播延遲。但就目前所了解，各大CDN廠商沒(méi)有支持基于RTP直播的，所以目前國(guó)內(nèi)主流還是RTMP或HTTP-FLV。

是否有除了HLS外更低延遲的方案?

HLS的優(yōu)點(diǎn)點(diǎn)是顯而易見(jiàn)的：移動(dòng)端無(wú)需安裝APP使用兼容HTML5的瀏覽器打開即可觀看，所有主流的移動(dòng)端瀏覽器基本都支持HTML5，在直播的傳播和體驗(yàn)上有巨大的優(yōu)勢(shì)。而看起來(lái)唯一的缺點(diǎn)：內(nèi)容延遲高(這里也有很多HLS限制沒(méi)有提到，比如必須是H264+AAC編碼，也可認(rèn)為是“缺點(diǎn)”之一)。如果能得到解決，那將會(huì)是直播技術(shù)非常大的一個(gè)進(jìn)步。或者換個(gè)說(shuō)法，有沒(méi)有更低延遲可直接用鏈接傳播的直播方案?不局限于HLS本身。

對(duì)于瀏覽器直接的視頻互動(dòng)，Google一直在推WebRTC，目前已有不少成型的產(chǎn)品出現(xiàn)，可以瀏覽器打開即實(shí)時(shí)對(duì)話、直播。但來(lái)看看如下的瀏覽器覆蓋圖：

非常遺憾的說(shuō)，在直至iOS 9.3上的Safari仍然不能支持WebRTC。繼續(xù)我們的探索，那Websocket支持度如何呢?

除了老而不化的Opera Mini外，所有的瀏覽器都支持WebSocket。這似乎是個(gè)好消息。梳理一下HTML5 WebSocket直播需要解決的問(wèn)題：

1、后端兼容

2、傳輸

3、解碼播放

對(duì)于#1似乎不是特別大問(wèn)題，對(duì)于做過(guò)RTMP轉(zhuǎn)HLS、RTP來(lái)說(shuō)是基本功。#2對(duì)于瀏覽器來(lái)說(shuō)使用HTTP來(lái)傳輸是比較好的選項(xiàng)。對(duì)于#3 這里推薦一個(gè)開源的JS解碼項(xiàng)目jsmpeg: https://github.com/phoboslab/jsmpeg，里面已有一個(gè)用于直播的stream-server.js的NodeJS服務(wù)器。

從測(cè)試結(jié)果看，該項(xiàng)目的代碼相對(duì)較薄，還沒(méi)達(dá)到工業(yè)級(jí)的成熟度，需要大規(guī)模應(yīng)用估計(jì)需要自填不少坑，有興趣的同學(xué)可以學(xué)習(xí)研究。

以上就是直播云：直播應(yīng)用層協(xié)議及傳輸層協(xié)議的選擇以及對(duì)直播體驗(yàn)影響的分析 。關(guān)于接入網(wǎng)絡(luò)優(yōu)化、內(nèi)容緩存與傳輸策略優(yōu)化、終端優(yōu)化，請(qǐng)參閱接下來(lái)發(fā)布的其他部分。

點(diǎn)擊閱讀：關(guān)于直播，所有的技術(shù)細(xì)節(jié)都在這里了(一)接入網(wǎng)絡(luò)優(yōu)化

預(yù)告：延遲與卡頓的矛盾關(guān)系如何解決?有的時(shí)候需要主動(dòng)丟包?欲知內(nèi)容緩存與傳輸策略優(yōu)化技巧，請(qǐng)關(guān)注下篇：《關(guān)于直播，所有的技術(shù)細(xì)節(jié)都在這里了(三)》