目前，國內主流的直播協議有HLS、RTMP、HTTP FLV，適用於不同的直播場景。
一、HLS、RTMP與HTTP FLV
1.HLS
HLS 全稱是 HTTP Live Streaming, 是一個由 Apple 公司實現的基於 HTTP 的媒體流傳輸協議. 它跟 DASH 協議的原理非常類似. 通過將整條流切割成一個小的可以通過 HTTP 下載的媒體檔案, 然後提供一個配套的媒體列 表檔案, 提供給客戶端, 讓客戶端順序地拉取這些媒體檔案播放, 來實現看上去是在播放一條流的效果。
△HLS 原理架構圖
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）
二、直播協議HLS、RTMP與HTTP FLV的簡單對比
|
協議 |
傳輸方式 |
視訊封裝格式 |
延時 |
資料分段 |
HTML5直播 |
應用場景 |
|
HLS |
HTTP流 |
Ts檔案 |
10-30s |
切片 |
支援 |
H5直播，遊戲直播 |
|
RTMP |
tcp流 |
flv tag |
2s |
連續流 |
不支援 |
互動直播 |
|
http flv |
HTTP流 |
flv |
2s |
連續流 |
支援 |
互動直播 |
三、總結
RTMP格式目前在國內是用比較多，國內CDN廠商也多支援RTMP協議。HLS作為蘋果提出的直播協議，在iOS端佔據了不可撼動的地位，同時又便於傳播。HTTP FLV使用類似RTMP流式協議的HTTP長連線，需由特定流媒體伺服器分發的，兼顧兩者的優點。
又拍雲一站式直播解決方案基於又拍雲CDN，支援 RTMP、HTTP-FLV 和 HLS協議，並且通過智慧排程、鏈路保障、追幀處理、丟幀處理以及業界首創的 HLS+ 技術，將RTMP、HTTP FLV直播延遲控制在1秒內，將HLS協議控制在4秒左右。