直播協議詳解 rtmp、hls、http-flv、WebRTC、rtsp
本期我們詳細討論直播的相關協議，包括：HTTP-FLV、HLS、RTMP、Web-RTC、RTSP等等。
我們將會詳細介紹這些協議的工作原理、應用場景、及延遲的原因。
我們按這樣的順序討論：
- RTMP、HTTP-FLV
- HLS
- Web-RTC
- RTSP
一、RTMP、HTTP-FLV協議
RTMP和HTTP-FLV都是建立在FLV封裝之上的。
RTMP一般用作直播源推流，HTTP-FLV一般用作直播觀看。
1.1 我們先討論RTMP
RTMP協議是既可以推流、也可以拉流的協議。
RTMP地址是rtmp://開頭的，且推流地址與播放地址是一樣的。
但是由於瀏覽器摒棄了Flash播放器，而且據說高併發下可能會出現一些不穩定的問題，所以RTMP一般只用作直播源推流、推流到直播CDN等場景。
RTMP協議需要特定的流媒體服務軟體，如SRS、加入了RTMP外掛的Nginx等。
在往期直播工作原理中討論過，此類流媒體服務軟體實際上就是音影片資料的中轉站，資料一般只在記憶體中迴圈覆蓋，不會寫入磁碟。
RTMP協議的延遲是比較低的，大概在1-3秒左右。
RTMP通訊是建立在TCP長連線通道上的，在封裝音影片資料時會強制切片，限制每個資料包的大小。
強制切片也一定程度保證了實時性。有一定的弱網抵抗能力，因為每個資料包都不會太大，所以當某個資料包校驗失敗時，重新傳送的成本不會太大，但也由於合併資料包會加大CPU壓力，所以是有一定的效能消耗的。
RTMP協議還有一些變種協議，如RTMPT、RTMPS等，這裡不作展開討論。
1.2 我們再討論HTTP-FLV協議
地址是http://開頭的，是基於HTTP協議的HTTP-FLV可以簡單地理解為RTMP的HTTP協議版本。功能和工作原理上是相似的，上面提到的RTMP切片資料功能HTTP-FLV也是有的。
但是，HTTP-FLV協議一般只能用作拉流觀看。
HTTP-FLV協議的延遲也是比較低的，大概在1-3秒左右，但實際體驗下來 HTTP-FLV延遲會略高於RTMP，但是HTTP-FLV相對RTMP適配更多的播放場景。
HTTP-FLV直播流一般需要需加入外掛才能播放，如網頁需要引入flv.js後，瀏覽器才能播放。HTTP-FLV直播流，這裡需要特別感謝B站開源的flv.js，它促進了HTTP-FLV在瀏覽器的普及。
HTTP-FLV協議需要特定的流媒體服務軟體，如加入了HTTP-FLV外掛的Nginx等。
值得一提的是，Nginx的HTTP-FLV外掛是包含RTMP功能的，所以一般HTTP-FLV的流媒體服務，推流是以RTMP協議，拉流是用HTTP-FLV協議。
現在比較流行的方案是，直播源推流是RTMP協議，直播拉流觀看是HTTP-FLV協議。
二、HLS協議
HLS協議一般只用作拉流觀看，但是從嚴格意義上講，HLS協議並不是流式協議。
它工作原理很簡單，就是透過HTTP協議下載靜態檔案。
不同的是，HLS協議的檔案由兩部分組成，一是多個只有幾秒長度的.ts碎片影片檔案，另一個是記錄這些影片檔案地址的.m3u8索引檔案，且這些靜態檔案都是直接寫入磁碟的。
更具體的說，HLS觀看地址是以http://開頭、.m3u8結尾的，實際上這個地址就是索引檔案的地址，客戶端獲取到索引檔案後，就可以下載對應的碎片影片檔案並開始播放了。
由於HLS協議實際上是透過HTTP協議請求檔案的，且HLS相關檔案是直接寫入磁碟的，所以並不需要特殊的流媒體服務軟體，使用Nginx等HTTP服務就可以了。
HLS協議可以用於點播和直播觀看，其適配多種播放場景，一般加入外掛就可以播放了，如網頁加入HLS的js外掛就可以播放了，蘋果裝置是原生支援HLS協議的。
點播的場景下，也就是普通網路影片觀看的場景下。
.m3u8索引檔案會記錄所有的碎片影片檔案地址，HLS在點播的場景下，優勢是更加明顯的。
由於HLS的相關檔案是無狀態的靜態檔案，且每個檔案的大小是有限的，所以負載均衡、CDN加速的效果更佳明顯。
HLS協議的點播影片，會比.mp4、.flv的影片更快地播放出來，且在載入中跳轉影片也會更加順滑。
直播的場景下，轉碼軟體可以直接生成HLS相關檔案到磁碟，客戶端透過HTTP服務下載檔案即可。
另外，也可以在Nginx加入RTMP外掛，轉碼軟體以RTMP協議推流到Nginx，再由Nginx生成HLS相關檔案。
其中，後一種方案更加推薦，因為它對於前期研發和後期對接直播CDN的過度更加順滑。
另外，直播場景下的HLS相關檔案與點播是有些不同的。
影片流資料每幾秒會打包成一個以.ts為字尾的碎片影片檔案，每生成一個新的影片檔案都會同步更新.m3u8索引檔案。
且碎片影片檔案的個數是有上限的，當達到上限後，預設會將最舊的影片檔案刪除且更新.m3u8索引檔案。
所以在直播的場景下，客戶端也需要不斷定時重新獲取.m3u8索引檔案。
HLS協議在直播的場景下是沒什麼優勢的。
雖然HLS協議的直播流也可以適配很多播放場景，但是由於需要生成靜態檔案，直播延遲很大，大概在5-30秒左右，使用直播CDN的話，由於邊緣節點同步等問題，直播延遲甚至可能會達到1分鐘左右。
當然HLS協議也有一定的優勢，在直播時移，也就是直播轉點播，或者錄播，也就是點播轉直播的場景， 理論上只需要修改索引檔案就可以了。
另外，HLS協議的.m3u8索引檔案支援二級索引，就是高畫質、標清、流暢等多個觀看地址可以整合到一個索引檔案。播放器可以根據當前頻寬自動切換不同的觀看地址，大部分網頁播放器的“自動”也是因為這個。
這裡補充一個HLS協議的小知識點。
由於HLS協議的影片檔案、索引檔案都是直接寫入磁碟的 ，所以如果長時間且多個直播流同時處理，會造成磁碟寫入壓力過大，機械磁碟可能會磁軌會損壞，固態硬碟的壽命會加速衰減。
這種情況下，最好掛載一段記憶體空間作為HLS相關檔案的寫入位置，則不會造成磁碟寫入壓力過大的問題。
補充說明一下，HLS協議是蘋果推出的標準，與HLS協議類似的還有MPEG-DASH協議 HLS、MPEG-DASH的工作原理都是差不多的，只是區域性標準不一樣，這裡不作展開。
三、WebRTC協議
WebRTC協議其實並不是為了直播場景而設計的，WebRTC是一種點對點的影片/語音通話協議。
由於WebRTC是基於UDP的，建立通訊後，會不斷以流式傳送資料，所以延遲會比RTMP還要低。
在一些互動性較高的直播場景，如直播帶貨等場景，會使用WebRTC作為推流和觀看協議 WebRTC的延遲理論上可以達到1秒內。
WebRTC協議支援推流和拉流，地址一般是以webrtc://開頭的，且推流和拉流地址一般也是一樣的。
WebRTC雖然是點對點的協議，但是應用在直播場景的話，是需要搭建WebRTC伺服器作為流媒體服務的，流媒體服務軟體可以使用SRS。
這裡順便一提，SRS是國內研發的一個比較流行的開源流媒體服務軟體，目前4.0已經囊括了RTMP、HLS、WebRTC、HTTP-FLV等主流協議。
- https://ossrs.io
- https://ossrs.net
- https://github.com/ossrs/srs
四、RTSP協議
RTSP一般不用作直播場景，RTSP一般用作攝像頭、監控等硬體裝置的實時影片流觀看與推送上。
儘管RTSP協議也支援推流/拉流，且支援TCP、UDP切換以及其他諸多優點。
但是泛用性不足，特別是現在的瀏覽器都不支援RTSP的播放。
總結
以上是常用的直播協議的介紹，其中提到的延遲都是單純的通訊延遲，如果要放眼整個直播流程，延遲將會進一步放大。
因為直播延遲包括推流延遲、轉碼延遲、拉流延遲，即使使用WebRTC作為推流和拉流協議，最終的延遲也會有幾秒的延遲。
至於直播延遲的問題，雖然以上協議起了關鍵作用，但是往往起不到絕對作用。
直播延遲的降低，會涉及到很多問題。如禁止B幀、GPU硬體加速、流媒體服務快取I幀、位元速率限制等等細節問題，後續我們會出具體內容詳細討論。
原文：https://www.cnblogs.com/eddyz/p/17869403.html