直播從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，但也勉強可用。