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

直播協議選擇

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

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

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

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

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

#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

假設列表里面的包含5個TS文件，每個TS文件包含5秒的視頻內容，那么整體的延遲就是25秒。當然可以縮短列表的長度和單個TS文件的大小來降低延遲，***來說可以縮減列表長度為1，1秒內容的m3u8文件，但是極易受網絡波動影響造成卡頓。通過公網的驗證，目前按同城網絡可以做到比較好的效果是5~7秒的延遲，也是綜合流暢度和內容延遲的結果。那么HTML5是否可以有更低延遲直接打開的直播流技術呢?我們在***會探討這個問題。

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

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

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

實時音視頻流的場景不需要可靠保障，因此也不需要有重傳的機制，實時的看到圖像聲音，網絡抖動時丟了一些內容，畫面模糊和花屏，完全不重要。TCP為了重傳會造成延遲與不同步，如某一截內容因為重傳，導致1秒以后才到，那么整個對話就延遲了1秒，隨著網絡抖動，延遲還會增加成2秒、3秒，如果客戶端播放是不加以處理將嚴重影響直播的體驗。

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

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

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

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

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

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

1、后端兼容

2、傳輸

3、解碼播放

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

從測試結果看，該項目的代碼相對較薄，還沒達到工業級的成熟度，需要大規模應用估計需要自填不少坑，有興趣的同學可以學習研究。

以上就是直播云：直播應用層協議及傳輸層協議的選擇以及對直播體驗影響的分析 。關于接入網絡優化、內容緩存與傳輸策略優化、終端優化，請參閱接下來發布的其他部分。

點擊閱讀：關于直播，所有的技術細節都在這里了(一)接入網絡優化

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