RTMP+CDN 技術(shù)特點(diǎn)與適用場(chǎng)景
RTMP （Real Time Messaging Protocol）基于 TCP 的流媒體傳輸協(xié)議，最大的特點(diǎn)是與 CDN 的強綁定，需要借助 CDN 的負載均衡系統將內容推送到接近用戶(hù)的邊緣節點(diǎn)，使用戶(hù)就近取得所需內容，提高用戶(hù)訪(fǎng)問(wèn)的響應速度和成功率，解決因分布、帶寬、服務(wù)器性能帶來(lái)的訪(fǎng)問(wèn)延遲問(wèn)題。更多適用于站點(diǎn)加速、點(diǎn)播、短視頻等場(chǎng)景。
對于初次通過(guò) CDN 服務(wù)來(lái)實(shí)現音視頻通信的開(kāi)發(fā)者來(lái)說(shuō)，技術(shù)指標應主要關(guān)注延時(shí)、卡頓率、下載速度、打開(kāi)速度、回源率、寬帶冗余提升率等幾個(gè)維度。
有研究表明，在 0.1s 以下的延遲，用戶(hù)幾乎是無(wú)感知的；1s 左右的延遲，用戶(hù)會(huì )明顯注意到延時(shí)的發(fā)生，但在該時(shí)間內思維依然是連貫的；超過(guò) 10s 的延時(shí)，用戶(hù)會(huì )失去等待的耐心。在所有關(guān)鍵技術(shù)指標中，控制延時(shí)是 CDN 最需要提升的。
以直播場(chǎng)景為例，延時(shí)主要看 2 個(gè)核心指標：首播時(shí)間和再緩存時(shí)間。首播時(shí)間即從打開(kāi)到看到視頻畫(huà)面的時(shí)間，會(huì )受域名解析、連接、第一包時(shí)間的影響，首播時(shí)間控制在 1 秒內算是不錯的效果。其次是再緩沖時(shí)間，是用戶(hù)觀(guān)看視頻時(shí)的卡頓時(shí)間。由于實(shí)際服務(wù)中視頻長(cháng)度不一，一般會(huì )做播放的體驗統計，主要監測的是卡頓率。行業(yè)內而言，直播首播時(shí)間 300ms，卡頓率在 15% 以下算是優(yōu)質(zhì)的通信服務(wù)。
目前的 CDN，通常有 3-5 秒的延遲，在瀏覽圖片、短視頻等內容時(shí)用戶(hù)感知不明顯，對于不需要實(shí)時(shí)強互動(dòng)的直播，比如體育賽事網(wǎng)絡(luò )直播、演唱會(huì )網(wǎng)絡(luò )直播、新聞現場(chǎng)直播，延遲是可以接受的，并不會(huì )影響用戶(hù)體驗。
而在線(xiàn)視頻會(huì )議、在線(xiàn)教育、電商直播、遠程醫療會(huì )診這些對互動(dòng)有非常高要求的場(chǎng)景，RTMP+CDN 的模式與這些場(chǎng)景對于低延時(shí)、無(wú)卡頓的要求有一定差距。這時(shí)，選擇 RTC 技術(shù)才能更好地滿(mǎn)足開(kāi)發(fā)者的需求。
RTC 技術(shù)特點(diǎn)與適用場(chǎng)景
說(shuō)到 RTC（Real Time Communication）實(shí)時(shí)音視頻通信，它最大的特點(diǎn)就是低延時(shí)和無(wú)卡頓。從功能流程上說(shuō)，它包含了采集、編碼、前后處理、傳輸、解碼、緩沖、渲染等諸多環(huán)節，RTC 不是靠“優(yōu)化”各環(huán)節去實(shí)現的實(shí)時(shí)互動(dòng)，而是依靠推流端實(shí)時(shí)的傳輸機制。
很多實(shí)時(shí)音視頻服務(wù)專(zhuān)業(yè)廠(chǎng)商使用的就是 WebRTC 標準，這是一種基于瀏覽器的實(shí)時(shí)通信的開(kāi)源解決方案，使用 UDP 私有協(xié)議來(lái)進(jìn)行媒體推流，而不需要創(chuàng )建離散的媒體段；并且它是面向無(wú)連接的，沒(méi)有 TCP 連接斷開(kāi)時(shí)的揮手確認連接關(guān)閉的機制，基于這兩點(diǎn)，WebRTC 能夠做到毫秒級的低延遲，遠遠低于基于 RTMP 協(xié)議的 CDN 分發(fā)的延遲。而且，它直接通過(guò)瀏覽器就可以完成推流和播放，對于開(kāi)發(fā)者接入來(lái)說(shuō)實(shí)在太方便。
因此，WebRTC 標準針對有高互動(dòng)性要求的直播場(chǎng)景尤為適宜。以直播連麥為例，主播端把通信直播流發(fā)到觀(guān)眾端，同時(shí)也可以把觀(guān)眾端拉上麥，實(shí)現主播和觀(guān)眾的互動(dòng)。使用 WebRTC，內容實(shí)時(shí)傳輸，主播和觀(guān)眾可以進(jìn)行音視頻連麥互動(dòng)，實(shí)時(shí)溝通，延時(shí)一般低至 400ms 以?xún)取?/div>
通信云服務(wù)商融云相關(guān)解決方案
基于 WebRTC 標準的融云實(shí)時(shí)音視頻服務(wù)，擁有超低延遲的優(yōu)勢，同時(shí)也支持將 RTC 音視頻流合流（MCU）轉碼為 RTMP，并推流到第三方 CDN 上，保留了標準協(xié)議普遍被 CDN 網(wǎng)絡(luò )支持的好處。目前，融云音視頻通話(huà)，可做到全球端到端延時(shí)小于 400ms，最低延時(shí) 66ms；低延時(shí)互動(dòng)直播的直播推流可以做到主播觀(guān)眾間延遲在 300ms 左右，保障端到端之間延遲無(wú)感知的實(shí)時(shí)互動(dòng)。
CDN vs RTC 選型還需看價(jià)格服務(wù)綜合比
一套實(shí)時(shí)音視頻通信能力的搭建，除了要根據場(chǎng)景選擇適合的技術(shù)外，還要看價(jià)格、服務(wù)的綜合性?xún)r(jià)比。通常來(lái)說(shuō)，使用 RTC 技術(shù)的成本比 RTMP+CDN 高。因為，從實(shí)踐來(lái)看，UDP 傳輸比 TCP 傳輸對資源消耗要多，而且重傳、封包、FEC 冗余計算等都會(huì )額外增加計算量，在多進(jìn)程模式下可能還會(huì )遇到內存資源的過(guò)多消耗，這些都導致開(kāi)發(fā)及使用成本的增加。
開(kāi)發(fā)者選型中，性?xún)r(jià)比需綜合技術(shù)特點(diǎn)、適用場(chǎng)景、價(jià)格和服務(wù)四個(gè)方面的全面考量。服務(wù)在產(chǎn)品上線(xiàn)前后的開(kāi)發(fā)階段和運營(yíng)階段，都要發(fā)揮重要作用。目前，開(kāi)發(fā)者服務(wù)做得比較好的廠(chǎng)商比如融云，會(huì )與開(kāi)發(fā)者共建開(kāi)發(fā)文檔，技術(shù)手冊短視頻化，提供場(chǎng)景化的 Demo，以及在官網(wǎng)搭建開(kāi)發(fā)者專(zhuān)區，幫助開(kāi)發(fā)者更便捷、更快速的理解 SDK。
融云全新升級的實(shí)時(shí)音視頻服務(wù)，提出“以一套 SDK 解決所有通信場(chǎng)景”，使用融云 RTC 的開(kāi)發(fā)者，同時(shí)可以用融云 IM 作為信令通道，而不用自己重新搭建或選擇第三方信令通道，這樣可以大大提升開(kāi)發(fā)效率，減少 SDK 文檔學(xué)習時(shí)間。
總體而言，RTC 低延遲直播是未來(lái)發(fā)展的趨勢，而 RTMP 在當前依然擁有價(jià)格上的優(yōu)勢，而兩者作為音視頻領(lǐng)域的實(shí)用技術(shù)，無(wú)論是適用場(chǎng)景、還是貼近開(kāi)發(fā)的服務(wù)都越來(lái)越多樣化，開(kāi)發(fā)者未來(lái)選型之路也將更順暢。
【免責聲明】本文僅代表作者本人觀(guān)點(diǎn)，與CTI論壇無(wú)關(guān)。CTI論壇對文中陳述、觀(guān)點(diǎn)判斷保持中立，不對所包含內容的準確性、可靠性或完整性提供任何明示或暗示的保證。請讀者僅作參考，并請自行承擔全部責任。
相關(guān)閱讀：
- ·百融云創(chuàng )定制語(yǔ)音機器人 迎接金融智能客服時(shí)代2021-01-29 09:50:56
- ·融云音視頻審核 高效靈活保障業(yè)務(wù)安全2021-01-27 15:22:31
- ·融云賦能金鵬信息情指行督一體化平臺 助公安通信實(shí)戰顯身手2021-01-11 14:22:17
- ·艾瑞報告：融云以通信云全能力布局三大市場(chǎng)2020-12-30 16:08:11
- ·將中國的通信能力帶到全球，融云的“經(jīng)緯術(shù)”2020-12-24 17:11:44
- ·搶占5G“黃金賽道” 融云如何成為通信云新勢力2020-12-21 14:35:23
- ·通信云江湖里的融云野望2020-12-15 13:35:28
- ·IM與RTC發(fā)揮協(xié)同效應 融云一體化服務(wù)構成競爭壁壘2020-12-11 14:24:19
- ·艾瑞2020全球互聯(lián)網(wǎng)通信云報告 融云再次領(lǐng)跑IM市場(chǎng)2020-12-03 10:03:00
- ·30萬(wàn)款App背后的支持 融云的全球化通信之旅2020-11-20 14:53:26
