RTMP （Real Time Messaging Protocol）基于 TCP 的流媒體傳輸協(xié)議，最大的特點(diǎn)是與 CDN 的強(qiáng)綁定，需要借助 CDN 的負(fù)載均衡系統(tǒng)將內(nèi)容推送到接近用戶的邊緣節(jié)點(diǎn)，使用戶就近取得所需內(nèi)容，提高用戶訪問(wèn)的響應(yīng)速度和成功率，解決因分布、帶寬、服務(wù)器性能帶來(lái)的訪問(wèn)延遲問(wèn)題。更多適用于站點(diǎn)加速、點(diǎn)播、短視頻等場(chǎng)景。

　　對(duì)于初次通過(guò) CDN 服務(wù)來(lái)實(shí)現(xiàn)音視頻通信的開(kāi)發(fā)者來(lái)說(shuō)，技術(shù)指標(biāo)應(yīng)主要關(guān)注延時(shí)、卡頓率、下載速度、打開(kāi)速度、回源率、寬帶冗余提升率等幾個(gè)維度。

　　有研究表明，在 0.1s 以下的延遲，用戶幾乎是無(wú)感知的；1s 左右的延遲，用戶會(huì)明顯注意到延時(shí)的發(fā)生，但在該時(shí)間內(nèi)思維依然是連貫的；超過(guò) 10s 的延時(shí)，用戶會(huì)失去等待的耐心。在所有關(guān)鍵技術(shù)指標(biāo)中，控制延時(shí)是 CDN 最需要提升的。

　　以直播場(chǎng)景為例，延時(shí)主要看 2 個(gè)核心指標(biāo)：首播時(shí)間和再緩存時(shí)間。首播時(shí)間即從打開(kāi)到看到視頻畫(huà)面的時(shí)間，會(huì)受域名解析、連接、第一包時(shí)間的影響，首播時(shí)間控制在 1 秒內(nèi)算是不錯(cuò)的效果。其次是再緩沖時(shí)間，是用戶觀看視頻時(shí)的卡頓時(shí)間。由于實(shí)際服務(wù)中視頻長(zhǎng)度不一，一般會(huì)做播放的體驗(yàn)統(tǒng)計(jì)，主要監(jiān)測(cè)的是卡頓率。行業(yè)內(nèi)而言，直播首播時(shí)間 300ms，卡頓率在 15% 以下算是優(yōu)質(zhì)的通信服務(wù)。

　　目前的 CDN，通常有 3-5 秒的延遲，在瀏覽圖片、短視頻等內(nèi)容時(shí)用戶感知不明顯，對(duì)于不需要實(shí)時(shí)強(qiáng)互動(dòng)的直播，比如體育賽事網(wǎng)絡(luò)直播、演唱會(huì)網(wǎng)絡(luò)直播、新聞現(xiàn)場(chǎng)直播，延遲是可以接受的，并不會(huì)影響用戶體驗(yàn)。

　　而在線視頻會(huì)議、在線教育、電商直播、遠(yuǎn)程醫(yī)療會(huì)診這些對(duì)互動(dòng)有非常高要求的場(chǎng)景，RTMP+CDN 的模式與這些場(chǎng)景對(duì)于低延時(shí)、無(wú)卡頓的要求有一定差距。這時(shí)，選擇 RTC 技術(shù)才能更好地滿足開(kāi)發(fā)者的需求。

　　說(shuō)到 RTC（Real Time Communication）實(shí)時(shí)音視頻通信，它最大的特點(diǎn)就是低延時(shí)和無(wú)卡頓。從功能流程上說(shuō)，它包含了采集、編碼、前后處理、傳輸、解碼、緩沖、渲染等諸多環(huán)節(jié)，RTC 不是靠“優(yōu)化”各環(huán)節(jié)去實(shí)現(xiàn)的實(shí)時(shí)互動(dòng)，而是依靠推流端實(shí)時(shí)的傳輸機(jī)制。

　　很多實(shí)時(shí)音視頻服務(wù)專業(yè)廠商使用的就是 WebRTC 標(biāo)準(zhǔn)，這是一種基于瀏覽器的實(shí)時(shí)通信的開(kāi)源解決方案，使用 UDP 私有協(xié)議來(lái)進(jìn)行媒體推流，而不需要?jiǎng)?chuàng)建離散的媒體段；并且它是面向無(wú)連接的，沒(méi)有 TCP 連接斷開(kāi)時(shí)的揮手確認(rèn)連接關(guān)閉的機(jī)制，基于這兩點(diǎn)，WebRTC 能夠做到毫秒級(jí)的低延遲，遠(yuǎn)遠(yuǎn)低于基于 RTMP 協(xié)議的 CDN 分發(fā)的延遲。而且，它直接通過(guò)瀏覽器就可以完成推流和播放，對(duì)于開(kāi)發(fā)者接入來(lái)說(shuō)實(shí)在太方便。

　　因此，WebRTC 標(biāo)準(zhǔn)針對(duì)有高互動(dòng)性要求的直播場(chǎng)景尤為適宜。以直播連麥為例，主播端把通信直播流發(fā)到觀眾端，同時(shí)也可以把觀眾端拉上麥，實(shí)現(xiàn)主播和觀眾的互動(dòng)。使用 WebRTC，內(nèi)容實(shí)時(shí)傳輸，主播和觀眾可以進(jìn)行音視頻連麥互動(dòng)，實(shí)時(shí)溝通，延時(shí)一般低至 400ms 以內(nèi)。

　　通信云服務(wù)商融云相關(guān)解決方案

　　基于 WebRTC 標(biāo)準(zhǔn)的融云實(shí)時(shí)音視頻服務(wù)，擁有超低延遲的優(yōu)勢(shì)，同時(shí)也支持將 RTC 音視頻流合流（MCU）轉(zhuǎn)碼為 RTMP，并推流到第三方 CDN 上，保留了標(biāo)準(zhǔn)協(xié)議普遍被 CDN 網(wǎng)絡(luò)支持的好處。目前，融云音視頻通話，可做到全球端到端延時(shí)小于 400ms，最低延時(shí) 66ms；低延時(shí)互動(dòng)直播的直播推流可以做到主播觀眾間延遲在 300ms 左右，保障端到端之間延遲無(wú)感知的實(shí)時(shí)互動(dòng)。

　　一套實(shí)時(shí)音視頻通信能力的搭建，除了要根據(jù)場(chǎng)景選擇適合的技術(shù)外，還要看價(jià)格、服務(wù)的綜合性價(jià)比。通常來(lái)說(shuō)，使用 RTC 技術(shù)的成本比 RTMP+CDN 高。因?yàn)�，從�?shí)踐來(lái)看，UDP 傳輸比 TCP 傳輸對(duì)資源消耗要多，而且重傳、封包、FEC 冗余計(jì)算等都會(huì)額外增加計(jì)算量，在多進(jìn)程模式下可能還會(huì)遇到內(nèi)存資源的過(guò)多消耗，這些都導(dǎo)致開(kāi)發(fā)及使用成本的增加。

　　開(kāi)發(fā)者選型中，性價(jià)比需綜合技術(shù)特點(diǎn)、適用場(chǎng)景、價(jià)格和服務(wù)四個(gè)方面的全面考量。服務(wù)在產(chǎn)品上線前后的開(kāi)發(fā)階段和運(yùn)營(yíng)階段，都要發(fā)揮重要作用。目前，開(kāi)發(fā)者服務(wù)做得比較好的廠商比如融云，會(huì)與開(kāi)發(fā)者共建開(kāi)發(fā)文檔，技術(shù)手冊(cè)短視頻化，提供場(chǎng)景化的 Demo，以及在官網(wǎng)搭建開(kāi)發(fā)者專區(qū)，幫助開(kāi)發(fā)者更便捷、更快速的理解 SDK。

　　融云全新升級(jí)的實(shí)時(shí)音視頻服務(wù)，提出“以一套 SDK 解決所有通信場(chǎng)景”，使用融云 RTC 的開(kāi)發(fā)者，同時(shí)可以用融云 IM 作為信令通道，而不用自己重新搭建或選擇第三方信令通道，這樣可以大大提升開(kāi)發(fā)效率，減少 SDK 文檔學(xué)習(xí)時(shí)間。

　　總體而言，RTC 低延遲直播是未來(lái)發(fā)展的趨勢(shì)，而 RTMP 在當(dāng)前依然擁有價(jià)格上的優(yōu)勢(shì)，而兩者作為音視頻領(lǐng)域的實(shí)用技術(shù)，無(wú)論是適用場(chǎng)景、還是貼近開(kāi)發(fā)的服務(wù)都越來(lái)越多樣化，開(kāi)發(fā)者未來(lái)選型之路也將更順暢。