文章轉自： "直播協議的選擇：RTMP vs. HLS" 前言 隨著直播業務的興起，越來越多的直播平臺開始涌現，這火熱的程度好像一個應用不帶上直播業務出來都不好意思跟人打招呼。想要做一個直播業務，主要包括三個部分：採集推流端、流媒體服務端、播放端。這裡不多說，就主要結合 iOS 平臺，從觀看端出發， ...
文章轉自：直播協議的選擇：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 就能直接播放，不用自己開發播放器。
RTMP
相對於 HLS 來說，採用 RTMP 協議時，從採集推流端到流媒體伺服器再到播放端是一條數據流，因此在伺服器不會有落地文件。這樣 RTMP 相對來說就有這些優點：
- 延時較小，通常為 1-3s。
- 基於 TCP 長連接，不需要多次建連。
因此業界大部分直播業務都會選擇用 RTMP 作為流媒體協議。通常會將數據流封裝成 FLV 通過 HTTP 提供出去。但是這樣也有一些問題需要解決：
- iOS 平臺沒有提供原生支持 RTMP 或 HTTP-FLV 的播放器，這就需要開發支持相關協議的播放器。
