RTMP HLS HTTP 直播協議一次看個夠

直播從2016年一路火到了2017年，現在要在本身的App里加入直播功能，只要找一個現成的SDK就好了，什麼拍攝、美顏、推流，一條龍服務。不過做爲直播身後最重要的部分：推流協議，不少人並非很清楚。若是你也對直播感興趣，想要了解他背後的各類機制，能夠先從這篇文章中瞭解一下推流協議開始。

單純從技術角度來看，可以實現直播功能協議中，比較經常使用的是RTMP HLS HTTP這種技術。但具體到應用場景，他們又會有一些不一樣的選擇。

RTMP

---

Real Time Messaging Protocol實時消息傳送協議是Adobe公司爲Flash播放器和服務器之間音頻、視頻和數據傳輸開發的私有協議,未徹底公開。關鍵詞：塊！目前絕大部分秀場直播使用的協議。

優點：

實時性高：

RTMP的實時性在3秒以內，通過多層CDN節點分發後，實時性也在3秒左右。在一些實時性有要求的應用中以RTMP爲主。比起YY的那種UDP私有協議，RTMP算延遲大的，比起HTTP流的延時（通常在10秒以上）RTMP算低延時。通常的直播應用，只要不是電話類對話的那種要求，RTMP延遲是能夠接受的。在通常的視頻會議應用中，RTMP延時也能接受，緣由是別人在說話的時候咱們通常在聽，實際上1秒延時沒有關係，咱們也要思考（話說有些人的CPU處理速度尚未這麼快）。

通過測量發現，在網絡情況良好時：
. RTMP延時能夠作到0.8秒左右。
. 多級邊緣節點不會影響延遲（和SRS同源的某CDN的邊緣服務器能夠作到）
. Nginx-Rtmp延遲有點大，估計是緩存的處理，多進程通訊致使？
. GOP是個硬指標，不過SRS能夠關閉GOP的cache來避免這個影響.
. 服務器性能過低，也會致使延遲變大，服務器來不及發送數據。
. 客戶端的緩衝區長度也影響延遲。譬如flash客戶端的NetStream.bufferTime設置爲10秒，那麼延遲至少10秒以上。

編碼兼容性高：

RTMP其實是如今編碼器輸出的工業標準協議，基本上全部的編碼器（攝像頭之類）都支持RTMP輸出。緣由在於PC市場巨大，PC主要是Windows，Windows的瀏覽器基本上都支持Flash，Flash又支持RTMP支持得很是好。

支持加密：

RTMPE和RTMPS爲加密協議。雖然HLS也有加密，但在PC平臺上flash對RTMPE/RTMPS支持應該比較不錯。

穩定性高：

在PC平臺上flash播放的最穩定方式是RTMP，若是作CDN或者大中型集羣分發，選擇穩定性高的協議必定是必要的。HTTP也很穩定，但HTTP是在協議上穩定；穩定性不僅是服務端的事情，在集羣分發，服務器管理，主備切換，客戶端的支持上，RTMP在PC分發這種方式上仍是頗有優點。

由於RTMP支持的很完善，因此能作到flash播放RTMP流長時間不斷流，當時測試是100萬秒，即10天多能夠連續播放。對於商用流媒體應用，客戶端的穩定性固然也是必須的，不然最終用戶看不了還怎麼玩？我就知道有個教育客戶，最初使用播放器播放http流，須要播放不一樣的文件，結果就總出問題，若是換成服務器端將不一樣的文件轉換成RTMP流，客戶端就能夠一直播放；該客戶走RTMP方案後，通過CDN分發，沒據說客戶端出問題了。

編碼器接入：

編碼器輸出到互聯網（還能夠輸出爲udp組播之類**應用），主要是RTMP。譬如專業編碼器，或者flash網頁編碼器，或者FMLE，或者ffmpeg，或者安防攝像頭，都支持RTMP輸出。若須要接入多種設備，譬如提供雲服務；或者但願網頁直接採集攝像頭；或者能在不一樣編碼器之間切換，那麼RTMP做爲服務器的輸入協議會是最好的選擇。

系統容錯：

容錯有不少種級別，RTMP的集羣實現時能夠指定N上層，在錯誤時切換不會影響到下層或者客戶端，另外RTMP的流沒有標識，切到其餘的服務器的流也能夠繼續播放。HLS的流熱備切換沒有這麼容易。若對於直播的容錯要求高，譬如下降出問題的機率，選擇RTMP會是很好的選擇。

可監控：

在監控系統或者運維繫統的角度看，流協議應該比較合適監控。HTTP的流監控感受沒有那麼完善。這個不算絕對優點，但比較有利。

劣勢：

播放兼容性差：

RTMP最大軟肋，由於是Adobe的私有協議，不少設備都沒法直接播放，好比iOS，須要外掛第三方解碼器，由此會帶來發熱、耗電等問題。HTML5也是沒法直接播放RTMP，所以你看到的不少手機網頁上的直播，是由下面HLS來推流的。

協議複雜：

RTMP協議比起HTTP複雜不少，致使性能低下。

測試發現兩臺服務器直連100Gbps網絡中，HTTP能跑到60Gbps，可是RTMP只能跑到10Gbps，CPU佔用率RTMP要高不少。複雜協議致使在研發，擴展，維護軟件系統時都沒有HTTP那麼方便，因此HTTP服務器如今大行其道，apache/nginx/tomcat，N多HTTP服務器；而RTMP協議雖然早就公開，可是真正在大規模中分發表現良好的沒有，adobe本身的FMS在CDN中都常常出問題。

Cache麻煩：

流協議作緩存不方便。譬如點播，若作RTMP流協議，邊緣緩存RTMP會很麻煩。若是是HTTP，緩存其實也很麻煩，可是HTTP服務器的緩存已經作了好久，因此只須要使用就好。這是爲什麼點播都走HTTP的緣由。

有累積延遲：

技術必定要知道弱點，RTMP有個弱點就是累積偏差，緣由是RTMP基於TCP不會丟包。因此當網絡狀態差時，服務器會將包緩存起來，致使累積的延遲；待網絡情況好了，就一塊兒發給客戶端。這個的對策就是，當客戶端的緩衝區很大，就斷開重連。

HTTP

---

HTTP說的是HTTP流，譬如各大視頻網站的點播流。本質上仍是文件分發

優點：

性能很高：

HTTP的性能沒得說，協議簡單，各類HTTP高性能服務器也完善。若是分發的量特別大，譬如點播視頻網站，沒有直播的實時性要求，HTTP協議是最好選擇。

沒有碎片：

HTTP比HLS沒有碎片，HTTP分發大文件會比小文件分發方便不少。特別是存儲，小文件的性能超低，是個硬傷。

穿牆：

互聯網不可能不開放HTTP協議，不然就不叫互聯網。因此任何端口封掉，也不會致使HTTP流看不了。（不過RTMP也能穿牆，用RTMPT協議）。

劣勢：

實時性差：

基本上沒有實時性這個說法。

原生支持很差：

就PC上flash對於HTTP流支持還能夠，Android/IOS上彷佛只能mp4，總之移動端對於HTTP的支持不是很完善。

HLS

---

HTTP Live Streaming，是Apple的開放標準，基於HTTP流，它最初是蘋果公司針對iPhone、iPod、iTouch和iPad等移動設備而開發的流，如今見到在桌面也有不少應用了，因爲是基於HTTP的，所以不少HTTP的優勢都獲得了繼承。

優點：

性能高：

和HTTP同樣。

穿牆：

和HTTP同樣。

兼容性高：

IOS、Android、HTML5原生支持。

劣勢：

實時性差：

基本上HLS的延遲在10秒以上。

文件碎片：

若分發HLS，碼流低，切片較小時，小文件分發不是很友好。特別是一些對存儲比較敏感的狀況，譬如源站的存儲，嵌入式的SD卡。

總結

---

. PC/Phone+直播+實時性要求高：使用flash播放RTMP。
. PC/Phone+直播+沒有實時性要求：使用RTMP或者HLS都可。
. PC/Phone+點播：使用HTTP或者HLS。
. Phone+WEB+直播：想啥呢，老老實實用HLS吧。

有人說，我又想在手機網頁上播，又想要他延遲低，怎麼辦呢。世上怎麼會有這麼矯情的人，要求這麼多，碰巧咱們公司就有這麼一我的，就是咱們的主管。咱們的產品主打的是輕直播，播放端沒有客戶端，所有經過網頁做爲載體來實現。其實呢，如今仍是有不少解決方案能夠達到這中目的的。大部分視頻流服務商都提供了遠程編碼的功能，流推上去後，自動編碼成RTMP和HLS，你想給App用就拿RTMP流，你想給網頁用你就拿HLS。至於HLS的延遲問題，已經有廠商開始推出優化版的HLS+，對HLS底層進行一些優化以適應低延遲直播的需求。根據咱們內部的測試，已經能將延遲下降到7s左右，雖然趕不上RTMP，但也勉強可用。

轉載：
http://www.cnblogs.com/my_life/articles/5593892.html
http://blog.chinaunix.NET/uid-26000296-id-4932817.html
http://blog.chinaunix.net/uid-26000296-id-4932822.html
http://blog.csdn.Net/zhangxinrun/article/details/50739237