RTMP HTTP HLS協議比較

rtmp hls http 直播協議一次看個夠

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

優勢：實時性高：

經過測量發現，在網路狀況良好時：

. 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支援應該比較不錯。

穩定性高：

編碼器接入：

編碼器輸出到網際網路（還可以輸出為udp組播之類**應用），主要是rtmp。譬如專業編碼器，或者flash網頁編碼器，或者fmle，或者ffmpeg，或者安防攝像頭，都支援rtmp輸出。若需要接入多種裝置，譬如提供雲服務；或者希望網頁直接採集攝像頭；或者能在不同編碼器之間切換，那麼rtmp作為伺服器的輸入協議會是最好的選擇。

系統容錯：

可監控：

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

劣勢：協議複雜：

rtmp協議比起http複雜很多，導致效能低下。

測試發現兩台伺服器直連100gbps網路中，http能跑到60gbps，但是rtmp只能跑到10gbps，cpu佔用率rtmp要高很多。複雜協議導致在研發，擴充套件，維護軟體系統時都沒有http那麼方便，所以http伺服器現在大行其道，apache/nginx/tomcat，n多http伺服器；而rtmp協議雖然早就公開，但是真正在大規模中分發表現良好的沒有，adobe自己的fms在cdn中都經常出問題。

流協議做快取不方便。譬如點播，若做rtmp流協議，邊緣快取rtmp會很麻煩。如果是http，快取其實也很麻煩，但是http伺服器的快取已經做了很久，所以只需要使用就好。這是為何點播都走http的原因。

有累積延遲：

技術一定要知道弱點，rtmp有個弱點就是累積誤差，原因是rtmp基於tcp不會丟包。所以當網路狀態差時，伺服器會將包快取起來，導致累積的延遲；待網路狀況好了，就一起發給客戶端。這個的對策就是，當客戶端的緩衝區很大，就斷開重連。

優勢：效能很高：

沒有碎片：

http比hls沒有碎片，http分發大檔案會比小檔案分發方便很多。特別是儲存，小檔案的效能超低，是個硬傷。

穿牆：網際網路不可能不開放http協議，否則就不叫網際網路。所以任何埠封掉，也不會導致http流看不了。（不過rtmp也能穿牆，用rtmpt協議）。

劣勢：實時性差：

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

原生支援不好：

就pc上flash對於http流支援還可以，android/ios上似乎只能mp4，總之移動端對於http的支援不是很完善。

優勢：效能高：

和http一樣。

穿牆：和http一樣。

相容性高：

ios、android、html5原生支援。

劣勢：實時性差：

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

檔案碎片：

若分發hls，碼流低，切片較小時，小檔案分發不是很友好。特別是一些對儲存比較敏感的情況，譬如源站的儲存，嵌入式的sd卡。

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

優勢：實時性高：

經過測量發現，在網路狀況良好時：

. 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支援應該比較不錯。

穩定性高：

編碼器接入：

編碼器輸出到網際網路（還可以輸出為udp組播之類**應用），主要是rtmp。譬如專業編碼器，或者flash網頁編碼器，或者fmle，或者ffmpeg，或者安防攝像頭，都支援rtmp輸出。若需要接入多種裝置，譬如提供雲服務；或者希望網頁直接採集攝像頭；或者能在不同編碼器之間切換，那麼rtmp作為伺服器的輸入協議會是最好的選擇。

系統容錯：

可監控：

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

劣勢：協議複雜：

rtmp協議比起http複雜很多，導致效能低下。

測試發現兩台伺服器直連100gbps網路中，http能跑到60gbps，但是rtmp只能跑到10gbps，cpu佔用率rtmp要高很多。複雜協議導致在研發，擴充套件，維護軟體系統時都沒有http那麼方便，所以http伺服器現在大行其道，apache/nginx/tomcat，n多http伺服器；而rtmp協議雖然早就公開，但是真正在大規模中分發表現良好的沒有，adobe自己的fms在cdn中都經常出問題。

流協議做快取不方便。譬如點播，若做rtmp流協議，邊緣快取rtmp會很麻煩。如果是http，快取其實也很麻煩，但是http伺服器的快取已經做了很久，所以只需要使用就好。這是為何點播都走http的原因。

有累積延遲：

技術一定要知道弱點，rtmp有個弱點就是累積誤差，原因是rtmp基於tcp不會丟包。所以當網路狀態差時，伺服器會將包快取起來，導致累積的延遲；待網路狀況好了，就一起發給客戶端。這個的對策就是，當客戶端的緩衝區很大，就斷開重連。

優勢：效能很高：

沒有碎片：

http比hls沒有碎片，http分發大檔案會比小檔案分發方便很多。特別是儲存，小檔案的效能超低，是個硬傷。

穿牆：網際網路不可能不開放http協議，否則就不叫網際網路。所以任何埠封掉，也不會導致http流看不了。（不過rtmp也能穿牆，用rtmpt協議）。

劣勢：實時性差：

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

原生支援不好：

就pc上flash對於http流支援還可以，android/ios上似乎只能mp4，總之移動端對於http的支援不是很完善。

優勢：效能高：

和http一樣。

穿牆：和http一樣。

相容性高：

ios、android、html5原生支援。

劣勢：實時性差：

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

檔案碎片：

若分發hls，碼流低，切片較小時，小檔案分發不是很友好。特別是一些對儲存比較敏感的情況，譬如源站的儲存，嵌入式的sd卡。

開源協議比較

freedom與free price是不同的，商業軟體就必須保密麼？明白了吧。開源注重的是 分享，你賣多少錢是你的事，當然也有例外。gtk 採用的是lgpl協議的自由軟體包，是gnu專案的一部分 lipcap 採用的是bsd協議。附 linux和gcc編譯器都是gpl許可的，但我們可以自由地區使用它...

STP協議和OSPF協議比較

這倆協議都涉及網路拓撲，看起來相似，但實質上不一樣，所以使用的演算法不一樣。首先，目的不同，stp協議是為了消除環路，而ospf是為了找最佳路徑。注意，ospf能檢測出環路，但這不代表它會消除環路，環路存在就存在，它不會管這一點，因為環路存在不影響路由器之間的網路關係。相對的，stp不消除環路會影響...

開源協議 幾張開源協議比較

每天在做軟體的時候都能遇到很多開原協議，一直不是很清楚有什麼區別，今天參考了一下別人的文章，在這裡做個總結。你可以將軟體複製到你的電腦，你客戶的電腦，或者任何地方。複製份數沒有任何限制。可自由分發 可以用來盈利 你可以在分發軟體的時候收費，但你必須在收費前向你的客戶提供該軟體的 gnu gpl 許可...