直播協議的選擇：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，參考播放器 如ijkplayer、大牛直播播放器。
• 基於 TCP 長鏈接，不須要屢次建連。

所以業界大部分直播業務都會選擇用 RTMP 做爲流媒體協議。一般會將數據流封裝成 FLV 經過 HTTP 提供出去。可是這樣也有一些問題須要解決：

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