RTMP和HLS的詳細(xì)比較

互聯(lián)網(wǎng)上的兩種主要的分發(fā)方式：HLS和RTMP，什么時(shí)候用誰，完全決定于應(yīng)用場(chǎng)景。

還有其他的分發(fā)方式，這些分發(fā)方式不屬于互聯(lián)網(wǎng)常見和通用的方式，不予以比較：

UDP：譬如YY的實(shí)時(shí)應(yīng)用，視頻會(huì)議等等，或者RTSP之類。這類應(yīng)用的特點(diǎn)就是實(shí)時(shí)性要求特別高，以毫秒計(jì)算。TCP家族協(xié)議根本就滿足不了要求，所以HTTP/TCP都不靠譜。這類應(yīng)用沒有通用的方案，必須自己實(shí)現(xiàn)分發(fā)（服務(wù)端）和播放（客戶端）。P2P：譬如RTMFP或者各家自己的協(xié)議。這類應(yīng)用的特點(diǎn)是節(jié)省帶寬。目前PC/flash上的RTMFP比較成熟，Android上的P2P屬于起步群雄紛爭(zhēng)標(biāo)準(zhǔn)不一，IOS上P2P應(yīng)該沒有聽說過。RTSP：這種不是互聯(lián)網(wǎng)上的主要應(yīng)用，在其他領(lǐng)域譬如安防等有廣泛應(yīng)用。

另外，HTTP的也分為幾種：

HTTP progressive：早期流媒體服務(wù)器分發(fā)http文件時(shí)，以普通的http文件分發(fā)，這種叫做漸進(jìn)式下載，意思就是如果文件很大譬如1小時(shí)時(shí)長1GB大小，想從中間開始播放是不行的。但這種方式已經(jīng)是作古了，很多http服務(wù)器支持http文件的seek，就是從中間開始播放。HTTP stream：支持seek的HTTP流，譬如各家視頻網(wǎng)站的點(diǎn)播分發(fā)方式?；蛘呱晕?fù)雜點(diǎn)的，譬如把一個(gè)大文件切幾段之后分發(fā)。目前在pc/flash上點(diǎn)播國內(nèi)的主流分發(fā)是這種方式。HLS：這種是現(xiàn)在適配方式最廣（除了flash, 需要額外的as庫支持），在PC上有vlc，Android/IOS原生播放器就支持播放HLS，HTML5里面的url可以寫HLS地址?？傊?，在移動(dòng)端是以HLS為主。HDS：adobe自己的HLS，一坨屎。DASH：各家提出的HLS，目前還沒有廣泛應(yīng)用。

對(duì)比以下互聯(lián)網(wǎng)上用的流媒體分發(fā)方式：

HLS：apple的HLS，支持點(diǎn)播和直播。HTTP：即HTTP stream，各家自己定義的http流，應(yīng)用于國內(nèi)點(diǎn)播視頻網(wǎng)站。RTMP：直播應(yīng)用，對(duì)實(shí)時(shí)性有一定要求，以PC為主。 RTMP

RTMP本質(zhì)上是流協(xié)議，主要的優(yōu)勢(shì)是：

實(shí)時(shí)性高：RTMP的實(shí)時(shí)性在3秒之內(nèi)，經(jīng)過多層CDN節(jié)點(diǎn)分發(fā)后，實(shí)時(shí)性也在3秒左右。在一些實(shí)時(shí)性有要求的應(yīng)用中以RTMP為主。支持加密：RTMPE和RTMPS為加密協(xié)議。雖然HLS也有加密，但在PC平臺(tái)上flash對(duì)RTMPE/RTMPS支持應(yīng)該比較不錯(cuò)。穩(wěn)定性高：在PC平臺(tái)上flash播放的最穩(wěn)定方式是RTMP，如果做CDN或者大中型集群分發(fā)，選擇穩(wěn)定性高的協(xié)議一定是必要的。HTTP也很穩(wěn)定，但HTTP是在協(xié)議上穩(wěn)定；穩(wěn)定性不只是服務(wù)端的事情，在集群分發(fā)，服務(wù)器管理，主備切換，客戶端的支持上，RTMP在PC分發(fā)這種方式上還是很有優(yōu)勢(shì)。編碼器接入：編碼器輸出到互聯(lián)網(wǎng)（還可以輸出為udp組播之類廣電應(yīng)用），主要是RTMP。譬如專業(yè)編碼器，或者flash網(wǎng)頁編碼器，或者FMLE，或者ffmpeg，或者安防攝像頭，都支持RTMP輸出。若需要接入多種設(shè)備，譬如提供云服務(wù)；或者希望網(wǎng)頁直接采集攝像頭；或者能在不同編碼器之間切換，那么RTMP作為服務(wù)器的輸入?yún)f(xié)議會(huì)是最好的選擇。系統(tǒng)容錯(cuò)：容錯(cuò)有很多種級(jí)別，RTMP的集群實(shí)現(xiàn)時(shí)可以指定N上層，在錯(cuò)誤時(shí)切換不會(huì)影響到下層或者客戶端，另外RTMP的流沒有標(biāo)識(shí)，切到其他的服務(wù)器的流也可以繼續(xù)播放。HLS的流熱備切換沒有這么容易。若對(duì)于直播的容錯(cuò)要求高，譬如降低出問題的概率，選擇RTMP會(huì)是很好的選擇。可監(jiān)控：在監(jiān)控系統(tǒng)或者運(yùn)維系統(tǒng)的角度看，流協(xié)議應(yīng)該比較合適監(jiān)控。HTTP的流監(jiān)控感覺沒有那么完善。這個(gè)不算絕對(duì)優(yōu)勢(shì)，但比較有利。

RTMP的劣勢(shì)是：

協(xié)議復(fù)雜：RTMP協(xié)議比起HTTP復(fù)雜很多，導(dǎo)致性能低下。測(cè)試發(fā)現(xiàn)兩臺(tái)服務(wù)器直連100Gbps網(wǎng)絡(luò)中，HTTP能跑到60Gbps，但是RTMP只能跑到10Gbps，CPU占用率RTMP要高很多。復(fù)雜協(xié)議導(dǎo)致在研發(fā)，擴(kuò)展，維護(hù)軟件系統(tǒng)時(shí)都沒有HTTP那么方便，所以HTTP服務(wù)器現(xiàn)在大行其道，apache/nginx/tomcat，N多HTTP服務(wù)器；而RTMP協(xié)議雖然早就公開，但是真正在大規(guī)模中分發(fā)表現(xiàn)良好的沒有，adobe自己的FMS在CDN中都經(jīng)常出問題。Cache麻煩：流協(xié)議做緩存不方便。譬如點(diǎn)播，若做RTMP流協(xié)議，邊緣緩存RTMP會(huì)很麻煩。如果是HTTP，緩存其實(shí)也很麻煩，但是HTTP服務(wù)器的緩存已經(jīng)做了很久，所以只需要使用就好。這是為何點(diǎn)播都走HTTP的原因。 HTTP

HTTP說的是HTTP流，譬如各大視頻網(wǎng)站的點(diǎn)播流。

HTTP本質(zhì)上還是文件分發(fā)，主要的優(yōu)勢(shì)是：

性能很高：HTTP的性能沒得說，協(xié)議簡單，各種HTTP高性能服務(wù)器也完善。如果分發(fā)的量特別大，譬如點(diǎn)播視頻網(wǎng)站，沒有直播的實(shí)時(shí)性要求，HTTP協(xié)議是最好選擇。沒有碎片：HTTP比HLS沒有碎片，HTTP分發(fā)大文件會(huì)比小文件分發(fā)方便很多。特別是存儲(chǔ)，小文件的性能超低，是個(gè)硬傷。穿墻：互聯(lián)網(wǎng)不可能不開放HTTP協(xié)議，否則就不叫互聯(lián)網(wǎng)。所以任何端口封掉，也不會(huì)導(dǎo)致HTTP流看不了。（不過RTMP也能穿墻，用RTMPT協(xié)議）。

HTTP的劣勢(shì)是：

實(shí)時(shí)性差：基本上沒有實(shí)時(shí)性這個(gè)說法。原生支持不好：就PC上flash對(duì)于HTTP流支持還可以，Android/IOS上似乎只能mp4，總之移動(dòng)端對(duì)于HTTP的支持不是很完善。 HLS

HLS是Apple的開放標(biāo)準(zhǔn)，在Android3?以上也原生支持.

HLS的主要優(yōu)勢(shì)是：

性能高：和HTTP一樣。穿墻：和HTTP一樣。原生支持很好：IOS上支持完美。Android上支持差些。PC/flash上現(xiàn)在也有各種as插件支持HLS。

HLS的主要劣勢(shì)是：

實(shí)時(shí)性差：基本上HLS的延遲在10秒以上。文件碎片：若分發(fā)HLS，碼流低，切片較小時(shí)，小文件分發(fā)不是很友好。特別是一些對(duì)存儲(chǔ)比較敏感的情況，譬如源站的存儲(chǔ)，嵌入式的SD卡。 應(yīng)用方式

參考HTTP和RTMP

推薦的方式是：

編碼器輸出RTMP協(xié)議。流媒體系統(tǒng)接入使用RTMP協(xié)議。流媒體系統(tǒng)內(nèi)部直播分發(fā)使用RTMP。PC+直播+實(shí)時(shí)性要求高：使用flash播放RTMP。PC+直播+沒有實(shí)時(shí)性要求：使用RTMP或者HLS均可。PC+點(diǎn)播：使用HTTP或者HLS。Apple IOS/OSX：都使用HLS（實(shí)時(shí)性要求高得自己解析RTMP，或者使用外部庫，譬如https://www.vitamio.org）

Andorid：和IOS一樣，不過可以確定的是可以自己開發(fā)支持RTMP。
原文鏈接：https://github.com/ossrs/srs/wiki/v1_CN_RTMP.PK.HTTP