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

直播協(xié)議選擇

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

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

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

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

基于HLS的直播流URL是一個m3u8的文件，里面包含了最近若干個小視頻TS(一種視頻封裝格式，這里就不擴(kuò)展介紹)文件，如http://www.ucloud.cn/helloworld.m3u8 是一個直播留鏈接，其內(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個TS文件，每個TS文件包含5秒的視頻內(nèi)容，那么整體的延遲就是25秒。當(dāng)然可以縮短列表的長度和單個TS文件的大小來降低延遲，***來說可以縮減列表長度為1，1秒內(nèi)容的m3u8文件，但是極易受網(wǎng)絡(luò)波動影響造成卡頓。通過公網(wǎng)的驗證，目前按同城網(wǎng)絡(luò)可以做到比較好的效果是5~7秒的延遲，也是綜合流暢度和內(nèi)容延遲的結(jié)果。那么HTML5是否可以有更低延遲直接打開的直播流技術(shù)呢?我們在***會探討這個問題。

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

UDP：單個數(shù)據(jù)報，不用建立連接，簡單，不可靠，會丟包，會亂序

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

實時音視頻流的場景不需要可靠保障，因此也不需要有重傳的機(jī)制，實時的看到圖像聲音，網(wǎng)絡(luò)抖動時丟了一些內(nèi)容，畫面模糊和花屏，完全不重要。TCP為了重傳會造成延遲與不同步，如某一截內(nèi)容因為重傳，導(dǎo)致1秒以后才到，那么整個對話就延遲了1秒，隨著網(wǎng)絡(luò)抖動，延遲還會增加成2秒、3秒，如果客戶端播放是不加以處理將嚴(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廠商沒有支持基于RTP直播的，所以目前國內(nèi)主流還是RTMP或HTTP-FLV。

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

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

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

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

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

1、后端兼容

2、傳輸

3、解碼播放

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

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

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

點擊閱讀：關(guān)于直播，所有的技術(shù)細(xì)節(jié)都在這里了(一)   http://www.scjtxx.cn/art/201605/511219.htm

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