RTMP HLS HTTP 直播協定一次看個夠RTMPHTTPHLS總結

直播從2016年一路火到了2017年，如今要在自己的App裡加入直播功能，隻要找一個現成的SDK就行了，什麼拍攝、美顔、推流，一條龍服務。不過作為直播身後最重要的部分：推流協定，很多人并不是很清楚。如果你也對直播感興趣，想要了解他背後的各種機制，可以先從這篇文章中了解一下推流協定開始。

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

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比HLS沒有碎片，HTTP分發大檔案會比小檔案分發友善很多。特别是存儲，小檔案的性能超低，是個硬傷。

穿牆：

網際網路不可能不開放HTTP協定，否則就不叫網際網路。是以任何端口封掉，也不會導緻HTTP流看不了。（不過RTMP也能穿牆，用RTMPT協定）。

實時性差：

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

原生支援不好：

就PC上flash對于HTTP流支援還可以，Android/IOS上似乎隻能mp4，總之移動端對于HTTP的支援不是很完善。

HTTP Live Streaming，是Apple的開放标準，基于HTTP流，它最初是蘋果公司針對iPhone、iPod、iTouch和iPad等移動裝置而開發的流，現在見到在桌面也有很多應用了，由于是基于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，但也勉強可用。

轉載： <a href="http://www.cnblogs.com/my_life/articles/5593892.html" target="_blank">http://www.cnblogs.com/my_life/articles/5593892.html</a> <a href="http://blog.chinaunix.NET/uid-26000296-id-4932817.html" target="_blank">http://blog.chinaunix.NET/uid-26000296-id-4932817.html</a> <a href="http://blog.chinaunix.net/uid-26000296-id-4932822.html" target="_blank">http://blog.chinaunix.net/uid-26000296-id-4932822.html</a> <a href="http://blog.csdn.Net/zhangxinrun/article/details/50739237" target="_blank">http://blog.csdn.Net/zhangxinrun/article/details/50739237</a>