目前，國內主流的直播協議有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秒左右。