域名預(yù)訂/競(jìng)價(jià)，好“米”不錯(cuò)過

隨著在線教育、電商直播、泛娛樂社交等 App 的普及，實(shí)時(shí)音視頻技術(shù)的應(yīng)用需求也越來越多元化。目前，市場(chǎng)中能夠支持音視頻通信的主流技術(shù)有“RTMP+CDN”和“RTC”兩大陣營(yíng)。選型時(shí)，開發(fā)者如何根據(jù)場(chǎng)景選擇更適合自己的通信技術(shù)?這就要從兩者的技術(shù)特點(diǎn)、價(jià)格、廠商服務(wù)綜合考慮。

RTMP+CDN 技術(shù)特點(diǎn)與適用場(chǎng)景

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)播、短視頻等場(chǎng)景。

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

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

以直播場(chǎng)景為例，延時(shí)主要看 2 個(gè)核心指標(biāo)：首播時(shí)間和再緩存時(shí)間。首播時(shí)間即從打開到看到視頻畫面的時(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í)、無卡頓的要求有一定差距。這時(shí)，選擇 RTC 技術(shù)才能更好地滿足開發(fā)者的需求。

RTC 技術(shù)特點(diǎn)與適用場(chǎng)景

說到 RTC(Real Time Communication)實(shí)時(shí)音視頻通信，它最大的特點(diǎn)就是低延時(shí)和無卡頓。從功能流程上說，它包含了采集、編碼、前后處理、傳輸、解碼、緩沖、渲染等諸多環(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í)通信的開源解決方案，使用 UDP 私有協(xié)議來進(jìn)行媒體推流，而不需要?jiǎng)?chuàng)建離散的媒體段;并且它是面向無連接的，沒有 TCP 連接斷開時(shí)的揮手確認(rèn)連接關(guān)閉的機(jī)制，基于這兩點(diǎn)，WebRTC 能夠做到毫秒級(jí)的低延遲，遠(yuǎn)遠(yuǎn)低于基于 RTMP 協(xié)議的 CDN 分發(fā)的延遲。而且，它直接通過瀏覽器就可以完成推流和播放，對(duì)于開發(fā)者接入來說實(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 左右，保障端到端之間延遲無感知的實(shí)時(shí)互動(dòng)。

CDN vs RTC 選型還需看價(jià)格服務(wù)綜合比

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

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

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

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

申請(qǐng)創(chuàng)業(yè)報(bào)道，分享創(chuàng)業(yè)好點(diǎn)子。點(diǎn)擊此處，共同探討創(chuàng)業(yè)新機(jī)遇！