從Html5直播到互動直播，看直播協議的選擇

目前，國內主流的直播協議有HLS、RTMP、HTTP FLV，適用於不一樣的直播場景。

1、HLS、RTMP與HTTP FLV

1.HLS

HLS 全稱是 HTTP Live Streaming, 是一個由 Apple 公司實現的基於 HTTP 的媒體流傳輸協議. 它跟 DASH 協議的原理很是相似. 經過將整條流切割成一個小的能夠經過 HTTP 下載的媒體文件, 而後提供一個配套的媒體列 表文件, 提供給客戶端, 讓客戶端順序地拉取這些媒體文件播放, 來實現看上去是在播放一條流的效果。

HLS 協議基於 HTTP，主要內容是關於 M3U8 這個文本協議的。其實生成和解析都很是簡單， HLS 的請求流程是：

• http 請求 m3u8 的 url。

• 服務端返回一個 m3u8 的播放列表，這個播放列表是實時更新的，通常一次給出5段數據的 url。

• 客戶端解析 m3u8 的播放列表，再按序請求每一段的 url，獲取 ts 數據流。

HLS 的優點

• 客戶端支持簡單, 只須要支持 HTTP 請求便可, HTTP 協議無狀態, 只須要按順序下載媒體片斷便可.

• 使用 HTTP 協議網絡兼容性好, HTTP 數據包也能夠方便地經過防火牆或者代理服務器, CDN 支持良好.

• Apple 的全系列產品支持, 因爲 HLS 是蘋果提出的, 因此在 Apple 的全系列產品包括 iphone, ipad, safari 都不須要安裝任何插件就能夠原生支持播放 HLS, 如今, Android 也加入了對 HLS 的支持.

• 自帶多碼率自適應, Apple 在提出 HLS 時, 就已經考慮了碼流自適應的問題.

HLS 的劣勢

• 相比 RTMP 這類長鏈接協議, 延時較高, 難以用到互動直播場景.

• 對於點播服務來講, 因爲 TS 切片一般較小, 海量碎片在文件分發, 一致性緩存, 存儲等方面都有較大挑戰.

2. RTMP

RTMP協議是一個互聯網TCP/IP五層體系結構中應用層的協議。RTMP協議中基本的數據單元稱爲消息。當RTMP協議在互聯網中傳輸數據的時候，消息會被拆分紅更小的單元，稱爲消息塊。RTMP傳輸媒體數據的過程當中，發送端首先把媒體數據封裝成消息，而後把消息分割成消息塊，最後將分割後的消息塊經過TCP協議發送出去。接收端在經過TCP協議收到數據後，首先把消息塊從新組合成消息，而後經過對消息進行解封裝處理就能夠恢復出媒體數據。

RTMP的優點

• 速度快，誤碼率低，延遲低

• RTMP 是專爲流媒體服務而生，協議在制定的時候就考慮到不少底層的優化

• 消息塊的傳輸可以提供更加穩定的直播環境，在硬件上要求會更高，可是卻可以緩解http的繁瑣的傳輸介質。
  RTMP的劣勢

不支持Html5傳播、瀏覽器推送
基於TCP協議,雖然開發難度大，推廣度還不夠，對於開發人員來講門檻比較高。
對硬件要求相較於HLS較高

3.HTTP FLV

HTTP FLV是一種將直播流模擬成FLV文件，經過HTTP協議進行下載的模式來實現流媒體傳輸的協議。

HTTP FLV 結合了 RTMP 的低延時，以及能夠複用現有HTTP分發資源的流式協議。它的實時性和RTMP相等，與RTMP相比又省去了部分協議交互時間，首屏時間更短，可拓展的功能也更多。

HTTP FLV的優點

• 能夠在必定程度上避免防火牆的干擾

• 能夠很好的兼容HTTP 302跳轉，作到靈活調度

• 可使用HTTPS作加密通道

• 很好的支持移動端（Android，IOS）

2、直播協議HLS、RTMP與HTTP FLV的簡單對比

3、總結

RTMP格式目前在國內是用比較多，國內CDN廠商也多支持RTMP協議。HLS做爲蘋果提出的直播協議，在iOS端佔據了不可撼動的地位，同時又便於傳播。HTTP FLV使用相似RTMP流式協議的HTTP長鏈接，需由特定流媒體服務器分發的，兼顧二者的優勢。

又拍雲一站式直播解決方案基於又拍雲CDN，支持 RTMP、HTTP-FLV 和 HLS協議，而且經過智能調度、鏈路保障、追幀處理、丟幀處理以及業界獨創的 HLS+ 技術，將RTMP、HTTP FLV直播延遲控制在1秒內，將HLS協議控制在4秒左右。

推薦閱讀：

WebSocket+MSE——HTML5 直播技術解析

讓Chrome看不了WWDC直播的HLS技術詳解

技術乾貨|HLS 協議詳解及優化技術解析