一、視頻直播協議

在直播領域大概可以分類兩種類型的在直播：一種是交互式直播，另外一種是非交互式直播。

非交互式直播（如：閱兵直播、NBA直播、歐冠直播等）交互性不強，允許延遲10秒或者10秒以上，特點是源比較少，適合做多路轉碼（用戶可以根據網絡條件觀看）。

交互式直播的典型場景有：秀場直播、游戲直播等。這些直播因為對主播和觀眾的互動性要求比較高，所以要求延遲在5s以內。交互式直播的特點是：源比較多，不適合做多路轉碼，中間服務器只作為中轉角色。

直播內容傳輸的介質是網絡，而網絡中傳播視頻或者音頻時需要使用對應的協議，目前適合直播場景的常用協議有如下幾種。

1.RTMP協議 (HTML 5不支持，Flash支持)

RTMP是一種流媒體協議，是Adobe的專利協議。基於TCP，在國內的使用流行度很高。

流行原因：開源軟件和開源庫的支持穩定完整，最常用的推流和拉流的解決方案基本上能夠很穩定的運行。如：開源的librtmp推流庫，服務端有nginx-rtmp插件，拉流有ijkPlayer播放庫。

2.HTTP-FLV協議 (HTML 5 不支持，Flash支持)

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

3.HLS協議 (HTML 支持，Flash支持)

即Http Live Streaming，是由蘋果提出基於HTTP的流媒體傳輸協議。HLS有一個非常大的優點：HTML5可以直接打開播放；這個意味着可以把一個直播鏈接通過微信等轉發分享，不需要安裝任何獨立的APP，有瀏覽器即可，所以流行度很高。社交直播APP，HLS可以說是剛需。基於HLS的直播流URL是一個m3u8的文件，里面包含了最近若干個小視頻TS（一種視頻封裝格式，這里就不擴展介紹）文件。這種播放形式的延時比較高（與TS文件的大小有關系），同城網絡下能夠做到5~7秒的延時。

4.RTP/RTCP協議

即 Real-time Transport Protocol，用於Internet上針對多媒體數據流的一種傳輸層協議。RTCP傳輸交互控制的信令，RTP傳輸實際的媒體數據。

RTP在視頻監控、視頻會議、IP電話上有廣泛的應用，因為視頻會議、IP電話的一個重要的使用體驗：內容實時性強。

對比上述3種協議，RTP和它們有一個重要的區別就是默認是使用UDP協議來傳輸數據，而RTMP和HTTP是基於TCP協議傳輸。

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

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