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

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 就能直接播放，不用自己開發播放器。

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

延時較小，通常為 1-3s。
基於 TCP 長連線，不需要多次建連。

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

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