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

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

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

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

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

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

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

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

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

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

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

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

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

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

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