直播協定的選擇：RTMP vs. HLS

前言

随着直播業務的興起，越來越多的直播平台開始湧現，這火熱的程度好像一個應用不帶上直播業務出來都不好意思跟人打招呼。想要做一個直播業務，主要包括三個部分：采集推流端、流媒體服務端、播放端。這裡不多說，就主要結合 iOS 平台，從觀看端出發，介紹一下對直播協定的選擇。

通常在 iOS 平台做直播業務，會有兩種協定可供選擇：HLS 和 RMTP。

HLS，是蘋果公司實作的基于 HTTP 的流媒體傳輸協定，全稱 HTTP Live Streaming，可支援流媒體的直播和點播，主要應用在 iOS 系統，為 iOS 裝置（如 iPhone、iPad）提供音視訊直播和點播方案。

RTMP，實時消息傳輸協定，Real Time Messaging Protocol，是 Adobe Systems 公司為 Flash 播放器和伺服器之間音頻、視訊和資料傳輸開發的開放協定。協定基于 TCP，是一個協定族，包括 RTMP 基本協定及 RTMPT/RTMPS/RTMPE 等多種變種。RTMP 是一種設計用來進行實時資料通信的網絡協定，主要用來在 Flash/AIR 平台和支援RTMP協定的流媒體/互動伺服器之間進行音視訊和資料通信。

上面是這兩種協定的簡介，那它們在實際應用中會有什麼差異呢？

HLS

先說說 HLS。HLS 的基本原理就是當采集推流端将視訊流推送到流媒體伺服器時，伺服器将收到的流資訊每緩存一段時間就封包成一個新的 ts 檔案，同時伺服器會建立一個 m3u8 的索引檔案來維護最新幾個 ts 片段的索引。當播放端擷取直播時，它是從 m3u8 索引檔案擷取最新的 ts 視訊檔案片段來播放，進而保證使用者在任何時候連接配接進來時都會看到較新的内容，實作近似直播的體驗。相對于常見的流媒體直播協定，例如 RTMP 協定、RTSP 協定等，HLS 最大的不同在于直播用戶端擷取到的并不是一個完整的資料流，而是連續的、短時長的媒體檔案，用戶端不斷的下載下傳并播放這些小檔案。這種方式的理論最小延時為一個 ts 檔案的時長，一般情況為 2-3 個 ts 檔案的時長。HLS 的分段政策，基本上推薦是 10 秒一個分片，這就看出了 HLS 的缺點：

通常 HLS 直播延時會達到 20-30s，而高延時對于需要實時互動體驗的直播來說是不可接受的。

HLS 基于短連接配接 HTTP，HTTP 是基于 TCP 的，這就意味着 HLS 需要不斷地與伺服器建立連接配接，TCP 每次建立連接配接時的三次握手、慢啟動過程、斷開連接配接時的四次揮手都會産生消耗。

不過 HLS 也有它的優點：

資料通過 HTTP 協定傳輸，是以采用 HLS 時不用考慮防火牆或者代理的問題。

使用短時長的分片檔案來播放，用戶端可以平滑的切換碼率，以适應不同帶寬條件下的播放。

HLS 是蘋果推出的流媒體協定，在 iOS 平台上可以獲得天然的支援，采用系統提供的 AVPlayer 就能直接播放，不用自己開發播放器。

image

RTMP

相對于 HLS 來說，采用 RTMP 協定時，從采集推流端到流媒體伺服器再到播放端是一條資料流，是以在伺服器不會有落地檔案。這樣 RTMP 相對來說就有這些優點：

延時較小，通常為 1-3s，參考播放器 如ijkplayer,

大牛直播SDK

播放器

基于 TCP 長連接配接，不需要多次建連。

是以業界大部分直播業務都會選擇用 RTMP 作為流媒體協定。通常會将資料流封裝成 FLV 通過 HTTP 提供出去。但是這樣也有一些問題需要解決：

iOS 平台沒有提供原生支援 RTMP 或 HTTP-FLV 的播放器，這就需要開發支援相關協定的播放器。