RTMP

Real Time Messaging Protocol實(shí)時(shí)消息傳送協(xié)議是Adobe公司為Flash播放器和服務(wù)器之間音頻、視頻和數(shù)據(jù)傳輸開發(fā)的私有協(xié)議,未完全公開。

優(yōu)勢(shì)：

實(shí)時(shí)性高：

RTMP的實(shí)時(shí)性在3秒之內(nèi)，經(jīng)過(guò)多層CDN節(jié)點(diǎn)分發(fā)后，實(shí)時(shí)性也在3秒左右。在一些實(shí)時(shí)性有要求的應(yīng)用中以RTMP為主。比起YY的那種UDP私有協(xié)議，RTMP算延遲大的，比起HTTP流的延時(shí)（一般在10秒以上）RTMP算低延時(shí)。一般的直播應(yīng)用，只要不是電話類對(duì)話的那種要求，RTMP延遲是可以接受的。在一般的視頻會(huì)議應(yīng)用中，RTMP延時(shí)也能接受。

編碼兼容性高：

RTMP實(shí)際上是現(xiàn)在編碼器輸出的工業(yè)標(biāo)準(zhǔn)協(xié)議，基本上所有的編碼器（攝像頭之類）都支持RTMP輸出。原因在于PC市場(chǎng)巨大，PC主要是Windows，Windows的瀏覽器基本上都支持Flash，F(xiàn)lash又支持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)頁(yè)編碼器，或者FMLE，或者ffmpeg，或者安防攝像頭，都支持RTMP輸出。若需要接入多種設(shè)備，譬如提供云服務(wù)；或者希望網(wǎng)頁(yè)直接采集攝像頭；或者能在不同編碼器之間切換，那么RTMP作為服務(wù)器的輸入?yún)f(xié)議會(huì)是最好的選擇。

系統(tǒng)容錯(cuò)：

容錯(cuò)有很多種級(jí)別，RTMP的集群實(shí)現(xiàn)時(shí)可以指定N上層，在錯(cuò)誤時(shí)切換不會(huì)影響到下層或者客戶端，另外RTMP的流沒(méi)有標(biāo)識(shí)，切到其他的服務(wù)器的流也可以繼續(xù)播放。HLS的流熱備切換沒(méi)有這么容易。若對(duì)于直播的容錯(cuò)要求高，譬如降低出問(wèn)題的概率，選擇RTMP會(huì)是很好的選擇。

可監(jiān)控：

在監(jiān)控系統(tǒng)或者運(yùn)維系統(tǒng)的角度看，流協(xié)議應(yīng)該比較合適監(jiān)控。HTTP的流監(jiān)控感覺(jué)沒(méi)有那么完善。這個(gè)不算絕對(duì)優(yōu)勢(shì)，但比較有利。

劣勢(shì)：

播放兼容性差：

RTMP最大軟肋，因?yàn)槭茿dobe的私有協(xié)議，很多設(shè)備都無(wú)法直接播放，比如iOS，需要外掛第三方解碼器，由此會(huì)帶來(lái)發(fā)熱、耗電等問(wèn)題。HTML5也是無(wú)法直接播放RTMP，因此你看到的很多手機(jī)網(wǎng)頁(yè)上的直播，是由下面HLS來(lái)推流的。

協(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í)都沒(méi)有HTTP那么方便，所以HTTP服務(wù)器現(xiàn)在大行其道，apache/nginx/tomcat，N多HTTP服務(wù)器；而RTMP協(xié)議雖然早就公開，但是真正在大規(guī)模中分發(fā)表現(xiàn)良好的沒(méi)有，adobe自己的FMS在CDN中都經(jīng)常出問(wèn)題。

Cache麻煩：

流協(xié)議做緩存不方便。譬如點(diǎn)播，若做RTMP流協(xié)議，邊緣緩存RTMP會(huì)很麻煩。如果是HTTP，緩存其實(shí)也很麻煩，但是HTTP服務(wù)器的緩存已經(jīng)做了很久，所以只需要使用就好。這是為何點(diǎn)播都走HTTP的原因。

有累積延遲：

技術(shù)一定要知道弱點(diǎn)，RTMP有個(gè)弱點(diǎn)就是累積誤差，原因是RTMP基于TCP不會(huì)丟包。所以當(dāng)網(wǎng)絡(luò)狀態(tài)差時(shí)，服務(wù)器會(huì)將包緩存起來(lái)，導(dǎo)致累積的延遲；待網(wǎng)絡(luò)狀況好了，就一起發(fā)給客戶端。這個(gè)的對(duì)策就是，當(dāng)客戶端的緩沖區(qū)很大，就斷開重連。

HTTP

HTTP說(shuō)的是HTTP流，譬如各大視頻網(wǎng)站的點(diǎn)播流。本質(zhì)上還是文件分發(fā)

優(yōu)勢(shì)：

性能很高：

HTTP的性能沒(méi)得說(shuō)，協(xié)議簡(jiǎn)單，各種HTTP高性能服務(wù)器也完善。如果分發(fā)的量特別大，譬如點(diǎn)播視頻網(wǎng)站，沒(méi)有直播的實(shí)時(shí)性要求，HTTP協(xié)議是最好選擇。

沒(méi)有碎片：

HTTP比HLS沒(méi)有碎片，HTTP分發(fā)大文件會(huì)比小文件分發(fā)方便很多。特別是存儲(chǔ)，小文件的性能超低，是個(gè)硬傷。

穿墻：

互聯(lián)網(wǎng)不可能不開放HTTP協(xié)議，否則就不叫互聯(lián)網(wǎng)。所以任何端口封掉，也不會(huì)導(dǎo)致HTTP流看不了。（不過(guò)RTMP也能穿墻，用RTMPT協(xié)議）。

劣勢(shì)：

實(shí)時(shí)性差：

基本上沒(méi)有實(shí)時(shí)性這個(gè)說(shuō)法。

原生支持不好：

就PC上flash對(duì)于HTTP流支持還可以，Android/IOS上似乎只能mp4，總之移動(dòng)端對(duì)于HTTP的支持不是很完善。

HLS

HTTP Live Streaming，是Apple的開放標(biāo)準(zhǔn)，基于HTTP流，它最初是蘋果公司針對(duì)iPhone、iPod、iTouch和iPad等移動(dòng)設(shè)備而開發(fā)的流，現(xiàn)在見(jiàn)到在桌面也有很多應(yīng)用了，由于是基于HTTP的，因此很多HTTP的優(yōu)點(diǎn)都得到了繼承。

優(yōu)勢(shì)：

性能高：

和HTTP一樣。

穿墻：

和HTTP一樣。

兼容性高：

IOS、Android、HTML5原生支持。

劣勢(shì)：

實(shí)時(shí)性差：

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

文件碎片：

若分發(fā)HLS，碼流低，切片較小時(shí)，小文件分發(fā)不是很友好。特別是一些對(duì)存儲(chǔ)比較敏感的情況，譬如源站的存儲(chǔ)，嵌入式的SD卡。

總結(jié)

. PC/Phone+直播+實(shí)時(shí)性要求高：使用flash播放RTMP。

. PC/Phone+直播+沒(méi)有實(shí)時(shí)性要求：使用RTMP或者HLS均可。

. PC/Phone+點(diǎn)播：使用HTTP或者HLS。

. Phone+WEB+直播：想啥呢，老老實(shí)實(shí)用HLS吧。