點(diǎn)擊上方“LiveVideoStack”關(guān)注我們

作者 | 袁榮喜

技術(shù)審校 | 吳鵬強(qiáng)

內(nèi)容編輯?|?Alex

RTC架構(gòu)演化史

? 視 野

#008#

隨著移動(dòng)互聯(lián)網(wǎng)普及和疫情疊加，實(shí)時(shí)通信技術(shù)（RTC）一時(shí)間成為炙手可熱的技術(shù)方向，RTC從1996年開始到如今已經(jīng)發(fā)展成為一個(gè)非常復(fù)雜的技術(shù)領(lǐng)域，其包含了網(wǎng)絡(luò)傳輸、全局調(diào)度、媒體處理算法、媒體編解碼、信令協(xié)議、輸入輸出設(shè)備、Web、操作系統(tǒng)等相關(guān)的技術(shù)，至今為止發(fā)展了25年。這期間伴隨互聯(lián)網(wǎng)發(fā)展經(jīng)歷了多次技術(shù)迭代，從網(wǎng)絡(luò)通信架構(gòu)演化過程來看可把它分為5個(gè)階段（這里稱為5代），每個(gè)階段RTC從終端技術(shù)到通信架構(gòu)都有大的技術(shù)變化。

第1代：MCU階段（1996~2004年）

第2代：P2P階段（2001~2007年）

第3代：單SFU階段（2003~2012年）

第4代：云SFU階段（2010~2017年）

第5代：全球?qū)崟r(shí)云通信階段（2016至今）

可以說每一代都是風(fēng)起云涌的時(shí)代，每一代又都是“卷王“的時(shí)代。這里我不去“卷”RTC某一領(lǐng)域的技術(shù)細(xì)節(jié)和應(yīng)用，而是通過分析這5個(gè)階段的大環(huán)境背景和用戶側(cè)場(chǎng)景訴求是如何推動(dòng)RTC技術(shù)演化變遷的，來幫助大家更好地理解RTC這個(gè)技術(shù)領(lǐng)域，也是對(duì)自己音視頻從業(yè)以來的一個(gè)總結(jié)。

MCU階段

上個(gè)世紀(jì)90年代中期，隨著WWW互聯(lián)網(wǎng)的崛起，大量的終端用戶通過電話線撥號(hào)涌入互聯(lián)網(wǎng)，當(dāng)時(shí)上網(wǎng)的終端網(wǎng)速只有56kbps（俗稱56K貓），看網(wǎng)頁、下載圖片有時(shí)候需要數(shù)十秒鐘。網(wǎng)速慢且流量昂貴，但企業(yè)和個(gè)人都有通過PC聯(lián)網(wǎng)的強(qiáng)烈需求。

• 企業(yè)場(chǎng)景：通過PC互聯(lián)實(shí)現(xiàn)內(nèi)部線上會(huì)議替代傳統(tǒng)的電話會(huì)議，企業(yè)信息融合通信。

• 個(gè)人場(chǎng)景：通過PC互聯(lián)實(shí)現(xiàn)點(diǎn)對(duì)點(diǎn)實(shí)時(shí)語音溝通。

H.323

在這種大背景下，ITU（國(guó)際電信聯(lián)盟）基于傳統(tǒng)PSTN架構(gòu)在1996年率先推出H.323/RTP的IP網(wǎng)絡(luò)多媒體標(biāo)準(zhǔn)，并在H.323協(xié)議中提出了MCU和網(wǎng)關(guān)的概念，與此同時(shí)IETF組織也在1996年發(fā)布了RTP規(guī)范（RTC1989），并在后續(xù)規(guī)范中進(jìn)一步完善了RTP/RTCP體系（RFC3550/3551），ITU后來將這幾個(gè)規(guī)范合并到H.323標(biāo)準(zhǔn)當(dāng)中。H.323架構(gòu)如下：

圖-1:H.323架構(gòu)

H.323標(biāo)準(zhǔn)不僅指定了傳輸協(xié)議RTP，它還制定了媒體編碼規(guī)范（G.7xx/H.261/H.263）、媒體協(xié)商協(xié)議（H.245）、信令協(xié)議（RAS/H.225）、網(wǎng)絡(luò)安全協(xié)議(H.235)等。其中媒體編碼影響深遠(yuǎn)，幾乎現(xiàn)在實(shí)時(shí)音視頻編碼算法都是從這里演化而來。H.323標(biāo)準(zhǔn)定義了點(diǎn)對(duì)點(diǎn)通信和多人會(huì)議通信，點(diǎn)對(duì)點(diǎn)通信和多人會(huì)議通信的差別是點(diǎn)對(duì)點(diǎn)通信的媒體是終端直接通信，而多人會(huì)議媒體需要經(jīng)過MCU，MCU按需重編碼合流后進(jìn)行媒體數(shù)下發(fā)。這里不得不提一句，H.323的ASN.1協(xié)議編碼技術(shù)確實(shí)精妙，但也沒逃過被淘汰的命運(yùn)。

架構(gòu)小結(jié)

H.323架構(gòu)后續(xù)在互聯(lián)網(wǎng)應(yīng)用中受限于網(wǎng)絡(luò)NAT和終端帶寬問題，從而迅速演化成單中心MCU服務(wù)模式，MCU既負(fù)責(zé)網(wǎng)絡(luò)媒體合流也負(fù)責(zé)信令接入，即第一代MCU架構(gòu)：

圖-2: MCU架構(gòu)

優(yōu)點(diǎn)：增強(qiáng)了Client的聯(lián)通性，合流讓終端的下行帶寬縮小，讓Client在當(dāng)時(shí)帶寬下可以獲得可通話的質(zhì)量。

缺點(diǎn)：MCU的計(jì)算量大，中心合流帶來的擴(kuò)展性比較差，容易引來系統(tǒng)瓶頸。

MCU架構(gòu)是在互聯(lián)網(wǎng)初期終端帶寬稀缺且昂貴的條件下產(chǎn)生的架構(gòu)，終端的形態(tài)也各式各樣，PC、IP話機(jī)、PBX網(wǎng)關(guān)等。隨著PC互聯(lián)網(wǎng)的到來，這一切迅速發(fā)生了改變。

?P2P階段

PC互聯(lián)網(wǎng)的發(fā)展促使了PC終端網(wǎng)絡(luò)的快速迭代。1999年，ITU批準(zhǔn)了ADSL技術(shù)成為寬帶標(biāo)準(zhǔn)，下載速度可達(dá)8Mbps，上行可以到1Mbps，ADSL利用原有電信線路搭建起來的終端接入方式迅速鋪開。ADSL解決了終端帶寬瓶頸問題，一時(shí)間IM社交（OICQ/MSN）和P2P下載服務(wù)（KaZaA/BT/eMule/迅雷）成為PC互聯(lián)網(wǎng)的主宰。同時(shí)摩爾定律繼續(xù)發(fā)揮效應(yīng)，終端PC的計(jì)算能力進(jìn)一步加強(qiáng)，已經(jīng)出現(xiàn)雙核CPU。終端設(shè)備的升級(jí)使得個(gè)人用戶的互聯(lián)網(wǎng)通信成為主流并形成了新的實(shí)時(shí)通信需求，同時(shí)也給RTC通信帶來新的變革和機(jī)會(huì)，其主要場(chǎng)景包括：

企業(yè)場(chǎng)景：基于VPN-Lan的VoIP通信，企業(yè)希望通過互聯(lián)網(wǎng)接入能力構(gòu)建自己內(nèi)部的IP語音通信網(wǎng)絡(luò)。

個(gè)人場(chǎng)景：社交IM場(chǎng)景下的1V1實(shí)時(shí)音視頻通信，免費(fèi)的IP語音服務(wù)替代傳統(tǒng)的PTSN收費(fèi)服務(wù)，同時(shí)社交類的視頻需求變得強(qiáng)烈。

RTC技術(shù)黃金期

正是終端計(jì)算能力和帶寬能力大幅提升，RTC技術(shù)形成了黃金發(fā)展時(shí)期，出現(xiàn)了眾多影響至今的技術(shù)和模型。

• SIP/SDP協(xié)議

IETF針對(duì)互聯(lián)網(wǎng)實(shí)時(shí)通信提出自己的信令標(biāo)準(zhǔn)SIP和媒體協(xié)商協(xié)議SDP，SIP協(xié)議采用UDP+HTTP文本方式實(shí)現(xiàn)協(xié)議編碼，連接過程原語遵循了電話呼叫的流程。其簡(jiǎn)單直接的方式一經(jīng)推出后就獲得了很多廠商的支持，這時(shí)就面臨與原來H.323協(xié)議交換互通的問題。在此情況下，各大廠商雄心壯志地試圖借鑒傳統(tǒng)交換機(jī)模型移到IP軟件交換上來統(tǒng)一各端設(shè)備通信，形成了當(dāng)時(shí)流行的軟交換系統(tǒng)。

值得思考的是，為什么當(dāng)時(shí)簡(jiǎn)潔的SIP協(xié)議在VoIP上迅速替代了成熟的H.323技術(shù)體系？

• P2P實(shí)時(shí)通信

終端帶寬能力的增強(qiáng)和P2P文件下載技術(shù)的大規(guī)模應(yīng)用，促使實(shí)時(shí)音視頻通信可以完全基于終端之間完成，企業(yè)的VoIP在這個(gè)時(shí)候得到了大量的落地（圖-3），這種模式更加經(jīng)濟(jì)和高效。

圖-3:基于SIP的VoIP架構(gòu)

除了通信關(guān)系上的變化外，在P2P系統(tǒng)中發(fā)展出來了很多新的網(wǎng)絡(luò)傳輸技術(shù)，例如：STUN/TURN穿越技術(shù)、ICE技術(shù)、RUDP技術(shù)、數(shù)據(jù)切片組幀技術(shù)等等。在此之前并沒有這些技術(shù)標(biāo)準(zhǔn)，這些技術(shù)是在當(dāng)時(shí)遇到實(shí)際問題時(shí)創(chuàng)造出來的。

• GIPS?封神

由于終端大量使用PC，早期的PC系統(tǒng)上并沒有對(duì)聲音的DSP處理，這導(dǎo)致使用PC進(jìn)行實(shí)時(shí)語音通信的時(shí)候會(huì)出現(xiàn)大量的回聲、噪聲、聲音抖動(dòng)、丟包顫音等問題。當(dāng)時(shí)優(yōu)秀的聲音處理算法都是以DSP捆綁硬件的方式提供，PC獲得和傳統(tǒng)電話一樣的通話質(zhì)量成為最迫切的需求。

瑞典GIPS公司創(chuàng)造性地將DSP的聲音算法移植到PC系統(tǒng)上，充分利用PC強(qiáng)大的計(jì)算能力對(duì)聲音算法進(jìn)行大膽創(chuàng)新，并開發(fā)出了獨(dú)特的3A算法（AEC/AGC/ANS）、網(wǎng)絡(luò)抗抖算法（NetEQ）、高質(zhì)量語音編碼器（iSAC）。當(dāng)時(shí)大部分互聯(lián)網(wǎng)巨頭都使用了GIPS，QQ2018PC版本里還有GIPS的版權(quán)說明呢。后來GIPS被Google收購(gòu)，它與GTalk的libjingle合并成為早期WebRTC的一部分，這是后話了。

• 視頻編碼王者H.264

個(gè)人社交服務(wù)的興起，在需求側(cè)實(shí)時(shí)視頻通信已經(jīng)迫在眉睫，當(dāng)時(shí)實(shí)時(shí)視頻編碼分布在兩個(gè)陣營(yíng)：ITU的H.263和ISO的MPEG4，H.264是ITU-T以H.26x系列為名稱命名的視頻編解碼技術(shù)標(biāo)準(zhǔn)之一，該標(biāo)準(zhǔn)結(jié)合了 H.323協(xié)議中的H.263協(xié)議和MPEG-4協(xié)議，解決了目前基于軟件視頻會(huì)議MPEG-4標(biāo)準(zhǔn)沒有辦法與H.323協(xié)議的終端兼容問題，使其成為目前最好的視頻壓縮協(xié)議。H.264在計(jì)算功耗和壓縮率之間有非常好的平衡，是RTC視頻通信的基石，縱橫視頻編碼二十載，如今依然是編碼器中的王者。

值得思考的是，為什么后來的視頻編碼器沒有替代掉H.264？僅僅是專利問題么？

• 第一個(gè)全球?qū)崟r(shí)通信網(wǎng)絡(luò)——Skype

當(dāng)時(shí)個(gè)人用戶的社交需求使得各大IM廠商都實(shí)現(xiàn)了自己內(nèi)部的實(shí)時(shí)音視頻通信功能，不過很不幸的是，當(dāng)時(shí)IM廠商主要還是集中在文字消息上，很多軟件音視頻功能的連通率不到30%，網(wǎng)絡(luò)一旦波動(dòng)，通話質(zhì)量無法保證，甚至?xí)霈F(xiàn)斷線情況。P2P音樂下載軟件KaZaA的作者用獨(dú)特的FastTrack協(xié)議構(gòu)建了第一個(gè)全球覆蓋的實(shí)時(shí)通信網(wǎng)絡(luò)，結(jié)合GIPS語音引擎在這個(gè)實(shí)時(shí)網(wǎng)絡(luò)上進(jìn)行語音通信，這就是當(dāng)時(shí)著名的Skype。Skype解決了當(dāng)時(shí)社交產(chǎn)品上的幾個(gè)問題：

1）語音連通性和NAT穿越問題，將連通性提高到95%以上。

2）結(jié)合GIPS解決了PC端上通話音質(zhì)問題。

3）利用P2P的全局索引與UDP overlay技術(shù)解決了全球覆蓋問題。

4）利用P2P的超級(jí)節(jié)點(diǎn)技術(shù)優(yōu)化通信路徑延遲和跨國(guó)跨運(yùn)營(yíng)商網(wǎng)絡(luò)問題，全球通話延遲在500ms以下。

5）利用數(shù)字加密技術(shù)解決端到端媒體數(shù)據(jù)安全問題。

圖-4:Skype網(wǎng)絡(luò)架構(gòu)示意圖

Skype開創(chuàng)了非常多的新技術(shù)，主要包括以下幾方面：

1）全局索引調(diào)度技術(shù)，可以通過P2P算法在網(wǎng)絡(luò)中找到并調(diào)度所需要的通話資源節(jié)點(diǎn)。

2）Lastmile就近super node接入，而不是單純的點(diǎn)對(duì)點(diǎn)直連。

3）路由實(shí)時(shí)計(jì)算，通信時(shí)實(shí)時(shí)計(jì)算和調(diào)整傳輸路徑。

4）STUN/TURN/ICE技術(shù)，Skype首次提出并使用ICE技術(shù)。

5）端到端媒體數(shù)據(jù)加密技術(shù)，Skype首次大規(guī)模使用數(shù)字簽名和媒體加密（RSA/AES/rc4）保證通話安全。

6）UDP Overlay實(shí)時(shí)通信覆蓋網(wǎng)絡(luò)。

?架構(gòu)小結(jié)

由于PC終端能力增強(qiáng)，RTC的架構(gòu)從MCU架構(gòu)演化成了基于每個(gè)流的P2P Mesh架構(gòu)（圖-5），這種架構(gòu)脫離中心服務(wù)的束縛，轉(zhuǎn)變成去中心化的服務(wù)模型。最先把這個(gè)模型用到極致的是Skype，它的語音服務(wù)質(zhì)量和穩(wěn)定性堪比PSTN。

2005年，Skype被eBay以26億美金收購(gòu)。后面諸多社交IM服務(wù)產(chǎn)品跟進(jìn)形成內(nèi)卷的局面，就連技術(shù)宗神Google當(dāng)時(shí)也山寨了一個(gè)GTalk。

圖-5:RTC?P2P架構(gòu)示意圖

優(yōu)點(diǎn)：后臺(tái)服務(wù)輕量，架構(gòu)擴(kuò)展性強(qiáng)，開發(fā)編程簡(jiǎn)單，只需要名字定位和信令協(xié)商等。通信由Endpoint之間自己完成，適合1V1方式通信。

缺點(diǎn)：服務(wù)質(zhì)量完全依賴于各個(gè)終端的網(wǎng)絡(luò)環(huán)境和穩(wěn)定性，連通性差，各端能力差異會(huì)引來通信差異。對(duì)于跨國(guó)跨運(yùn)營(yíng)商的通信無法保證通話QoS，去中心化后對(duì)于敏感通話信息無法進(jìn)行中心管理監(jiān)控，有政治安全風(fēng)險(xiǎn)。

?SFU階段

網(wǎng)絡(luò)MMO RPG游戲的興起使得游戲社區(qū)開始萌芽，游戲領(lǐng)域的實(shí)時(shí)溝通成了一個(gè)強(qiáng)需求，國(guó)外首先誕生了基于speex語音引擎的TS軟件。在國(guó)內(nèi)，由于傳奇和魔獸世界的流行，國(guó)內(nèi)模仿TS軟件誕生了iSpeaker和YY。游戲內(nèi)部實(shí)時(shí)協(xié)作不僅對(duì)通信質(zhì)量和穩(wěn)定性要求很高，也同時(shí)要求減少PC的資源占用。由于大量用戶使用類直播的多人溝通方式，在游戲語音軟件首先出現(xiàn)了Web 2.0模式，用戶自發(fā)組織成了一個(gè)個(gè)內(nèi)容社區(qū)（家族和頻道），頻道內(nèi)部除了游戲溝通外，平時(shí)也會(huì)出現(xiàn)直播類娛樂節(jié)目。

非典時(shí)期，新浪UC在IM競(jìng)爭(zhēng)中敗北，轉(zhuǎn)而研發(fā)出基于多視頻互動(dòng)的直播聊天室大放異彩，后續(xù)從中又演化出9158、六間房等產(chǎn)品。2011年底，YY在其大頻道加入單視頻直播模式，直播方式在這個(gè)階段成了主要流量。由于直播表演可以更好地展現(xiàn)主播形象，出現(xiàn)了專業(yè)聲卡硬件設(shè)備、美顏攝像頭設(shè)備、虛擬直播伴侶軟件。

這個(gè)階段企業(yè)應(yīng)用發(fā)展相對(duì)緩慢，但值得一提的是，視頻會(huì)議軟件逐步開始代替企業(yè)VoIP信息融合通信。這個(gè)時(shí)期出現(xiàn)了WebEx、Ploycom等視頻會(huì)議廠商，視頻會(huì)議軟件采用簡(jiǎn)單、容易部署的架構(gòu)（類似現(xiàn)在的SaaS 服務(wù)）。

值得思考的是，為什么單純的視頻會(huì)議會(huì)替代掉融合PSTN的VoIP？

社區(qū)模式下的RTC技術(shù)

社區(qū)模式使得RTC重新回到了傳輸?shù)腃lient/Server模式，Client負(fù)責(zé)個(gè)人媒體數(shù)據(jù)收發(fā)和錄制播放，Server負(fù)責(zé)控制和傳輸轉(zhuǎn)發(fā)，前后端側(cè)重的技術(shù)點(diǎn)不一樣，給社區(qū)場(chǎng)景帶來了后面的技術(shù)轉(zhuǎn)變。

• 基于媒體流的SFU

頻道對(duì)象的實(shí)時(shí)通話不可能基于MCU去混流轉(zhuǎn)發(fā)，為了滿足客戶端按需拉流的需求，發(fā)展出了基于Publish/Subscribe的流訂閱技術(shù)。這個(gè)技術(shù)在游戲語音場(chǎng)景首先實(shí)現(xiàn)，后被延展到秀場(chǎng)直播和視頻會(huì)議場(chǎng)景。

• 萬路語音頻道

為了滿足頻道多人互動(dòng)需求，YY在2008年左右開發(fā)出萬人語音頻道，很快iSpeaker和其他的游戲語音廠商也開始跟進(jìn)。萬人語音頻道還是有很大的技術(shù)挑戰(zhàn)，當(dāng)時(shí)大部分廠商采用的是單物理機(jī)的SFU模式，相當(dāng)于單個(gè)機(jī)器并發(fā)UDP包事件在20萬/秒左右。在2012年的ChinaJoy上，YY利用自己的分布式UDP Overlay架構(gòu)成功支持了單頻道120萬人線上觀看直播，這是RTC技術(shù)上的里程碑。后來直播逐步Web化，媒體分發(fā)開始大量使用CDN，催生了CDN與直播的發(fā)展，這是另外的話題。

• Proxy接入技術(shù)

基于流的SFU模型雖然利用了Server強(qiáng)大的控制轉(zhuǎn)發(fā)能力，減輕了終端上傳壓力，但不能解決用戶接入的網(wǎng)絡(luò)分區(qū)和長(zhǎng)距離傳輸問題，在SFU架構(gòu)基礎(chǔ)上，有些廠商開始引入Proxy接入技術(shù)來解決客戶端接入分區(qū)問題（見圖-6）。

圖-6：SFU與Proxy示意圖

Proxy可以很好地解決Client就近接入的問題，Proxy利用機(jī)房間的穩(wěn)定的傳輸網(wǎng)絡(luò)或者專線能力，可以提供比較穩(wěn)定的傳輸質(zhì)量。Proxy具有數(shù)據(jù)同機(jī)交換轉(zhuǎn)發(fā)能力，但轉(zhuǎn)發(fā)關(guān)系還需要中央的SFU來進(jìn)行控制決策。后面的云SFU架構(gòu)是在Proxy基礎(chǔ)上演化而來的。

• 前端媒體處理

這個(gè)階段出現(xiàn)了頻道直播場(chǎng)景，表演性質(zhì)決定了主播需要展示更好的一面。在這種強(qiáng)需求推動(dòng)下，首先出現(xiàn)了媒體前處理的硬件設(shè)備，而后又出現(xiàn)了帶有濾鏡、特效、簡(jiǎn)單美顏的PC直播伴侶軟件，其中最具有代表性的是MVBox和六間房直播伴侶。

• Web化與開源

PC互聯(lián)網(wǎng)的后期，用戶增長(zhǎng)出現(xiàn)了瓶頸，為了降低用戶使用門檻和增加留存，市面上產(chǎn)品都開始Web化，當(dāng)時(shí)最具代表性的是Web桌面應(yīng)用。RTC技術(shù)領(lǐng)域也不例外，在Skype早期就使用了瀏覽器激活協(xié)議在Web上激活native軟件并進(jìn)行呼叫，這個(gè)方式被WebEx和Zoom一直沿用到現(xiàn)在，如今所有視頻會(huì)議產(chǎn)品都有Web入會(huì)的功能。

2010年，Google收購(gòu)GIPS引擎和ON2，將GIPS、ON2（VP8前身）?和GTalk通信庫(kù)合并；2011年，Google將庫(kù)納入Chrome體系并開源，并命名為WebRTC。第一版本的WebRTC只提供native庫(kù)，2012年它獲得各大瀏覽器廠商支持并納入W3C標(biāo)準(zhǔn)，自此才基本能支持Web形式的實(shí)時(shí)音視頻通信。WebRTC的開源是RTC技術(shù)領(lǐng)域的里程碑事件，大大降低了RTC開發(fā)的門檻，催生了后來移動(dòng)互聯(lián)網(wǎng)RTC應(yīng)用的大時(shí)代。

值得思考的是，實(shí)時(shí)音視頻一直游離在Web領(lǐng)域的邊緣，為什么一直沒有出現(xiàn)主流的實(shí)時(shí)音視頻產(chǎn)品？截止如今native依然是RTC領(lǐng)域的主流，假如WebRTC早5年出現(xiàn)或許會(huì)成為RTMP這樣的CDN分發(fā)技術(shù)。

?架構(gòu)小結(jié)

這個(gè)階段RTC出現(xiàn)了大規(guī)模直播表演類的應(yīng)用，使得SFU架構(gòu)迅速成型并大規(guī)模應(yīng)用，SFU架構(gòu)很好地分離了客戶端和服務(wù)端功能，SFU專注于控制與傳輸轉(zhuǎn)發(fā)。由于應(yīng)用場(chǎng)景變化和終端計(jì)算能力進(jìn)一步增強(qiáng)，終端出現(xiàn)了圖像聲音相關(guān)的前處理應(yīng)用。SFU架構(gòu)簡(jiǎn)潔（見圖-7），適合大規(guī)模和超大規(guī)模實(shí)時(shí)音視頻互動(dòng)場(chǎng)景。

圖-7:SFU架構(gòu)示意圖

優(yōu)點(diǎn)：基于流Publish/Subscribe模式靈活，可以非常簡(jiǎn)單地實(shí)現(xiàn)各種多人互動(dòng)場(chǎng)景，也可以節(jié)省Client端的帶寬和上行能力，比較容易實(shí)現(xiàn)旁路監(jiān)控和風(fēng)險(xiǎn)管控。

缺點(diǎn)：單SFU應(yīng)對(duì)網(wǎng)絡(luò)傳輸?shù)姆謪^(qū)性差，就近接入需要引入Proxy。單SFU服務(wù)可用性差。對(duì)于跨地區(qū)長(zhǎng)距離很難保證實(shí)時(shí)通信質(zhì)量，分發(fā)效率和質(zhì)量并與后來的CDN有差距。

云SFU階段

智能手機(jī)的誕生讓互聯(lián)網(wǎng)從PC時(shí)代邁向了移動(dòng)時(shí)代，終端由計(jì)算能力強(qiáng)的PC開始向計(jì)算能力弱的手機(jī)轉(zhuǎn)移，終端的網(wǎng)絡(luò)瞬間由原來的有線接入轉(zhuǎn)向了WiFi和3G/4G。由于終端的變遷和用戶的激增，為了解決服務(wù)后端擴(kuò)展性、穩(wěn)定性和運(yùn)維效率問題，在原來分布式系統(tǒng)基礎(chǔ)上衍生出來了云計(jì)算。為了消除終端與服務(wù)的連通性問題，機(jī)房服務(wù)端的網(wǎng)絡(luò)開始大量部署B(yǎng)GP。這個(gè)巨大的改變使RTC應(yīng)用場(chǎng)景發(fā)生了轉(zhuǎn)變。這個(gè)階段有三個(gè)特點(diǎn)：

1)終端計(jì)算能力削弱，網(wǎng)絡(luò)接入向不穩(wěn)定的無線（WiFi/3G/4G）接入遷移。

2)后端計(jì)算能力增強(qiáng)，網(wǎng)絡(luò)消除了分區(qū)連通問題。

3)聯(lián)網(wǎng)用戶激增，RTC原來的社交、游戲、娛樂直播等領(lǐng)域進(jìn)一步滲透，RTC擴(kuò)展到教育、電商和金融。

云時(shí)代方向

正因如此，RTC在2014年出現(xiàn)了對(duì)外提供RTC云計(jì)算PaaS服務(wù)商網(wǎng)易云信和聲網(wǎng)，而后toB的PaaS服務(wù)商如雨后春筍，RTC領(lǐng)域正式進(jìn)入指標(biāo)內(nèi)卷時(shí)代。RTC PaaS開始階段是部署在云IaaS上的SFU，直接利用了IaaS基礎(chǔ)設(shè)施能力，簡(jiǎn)化了SFU架構(gòu)，這個(gè)架構(gòu)簡(jiǎn)稱為云SFU。

在線教育開始萌芽，RTC除了音視頻通信以外還產(chǎn)生了富媒體的實(shí)時(shí)通信需求：課件同步與書寫同步。富媒體同步需求讓RTC產(chǎn)生了實(shí)時(shí)可靠傳輸數(shù)據(jù)能力，在此基礎(chǔ)上演化出來實(shí)時(shí)互動(dòng)白板。

娛樂直播領(lǐng)域視頻分辨率整體提高，甚至出現(xiàn)720P/1080P的實(shí)時(shí)視頻直播，此時(shí)CDN接管了音視頻分發(fā)，RTC主要應(yīng)用在直播連麥和推流測(cè)，在這個(gè)場(chǎng)景當(dāng)中RTC產(chǎn)生了諸多新技術(shù)。

企業(yè)辦公移動(dòng)化，視頻會(huì)議產(chǎn)品開始移動(dòng)化，標(biāo)志性產(chǎn)品Zoom。

除了以上幾個(gè)典型RTC方向外，還有更多其他領(lǐng)域的應(yīng)用方向，這里也就不細(xì)說了。總之云時(shí)代旺盛需求讓RTC迎來了一次巨大的技術(shù)迭代。

云時(shí)代的RTC技術(shù)

• 終端傳輸算法的升級(jí)

視頻的分辨率和碼率爆炸性的增加，而終端接入從原來的有線接入轉(zhuǎn)變?yōu)闊o線接入方式，網(wǎng)絡(luò)質(zhì)量受周圍環(huán)境的影響加大，而且時(shí)刻處于高度變化當(dāng)中，那么在一個(gè)高度變化的網(wǎng)絡(luò)上提供穩(wěn)定的實(shí)時(shí)通信的需求就變得異常強(qiáng)烈。在這個(gè)階段，各大RTC PaaS使出渾身解數(shù)，各展絕技，不斷提高技術(shù)指標(biāo)和效果，toC產(chǎn)品的技術(shù)部門緊跟其后，所以我們?cè)贚iveVideoStackCon技術(shù)大會(huì)上總能聽到這方面的議題。這些傳輸算法主要包括以下幾個(gè)方面：

1.擁塞控制

WebRTC在2015年左右引入基于卡爾曼濾波的GCC擁塞控制算法，經(jīng)過不斷的試驗(yàn)調(diào)整，在2018年左右改為發(fā)送端計(jì)算的TCC。而后WebRTC又引入了Google的BBR和PCC，后續(xù)的測(cè)試當(dāng)中BBR在視頻傳輸不理想又刪除了，PCC還在測(cè)試當(dāng)中。國(guó)內(nèi)的廠商后續(xù)跟進(jìn)，都在擁塞控制方面做了很多的微創(chuàng)新。

2.FEC、ARQ與NACK

FEC：WebRTC在第一次推出時(shí)帶有最簡(jiǎn)單的Xor的FEC，后續(xù)加入了ulpFEC和FlexFEC。國(guó)內(nèi)云廠商創(chuàng)造性地用RS糾刪碼實(shí)現(xiàn)了新的FEC算法，實(shí)驗(yàn)室環(huán)境抗丟包可以達(dá)到80%，真實(shí)環(huán)境效果有多少就不得而知了。

ARQ/NACK重傳：重傳邏輯在早期的WebRTC版本中沒有實(shí)現(xiàn)，2015年后開始加入其中，NACK會(huì)拉大通信的延遲，所以在鏈路RTT延遲較小時(shí)效果比較明顯。

3.Simulcast與SVC

由于終端網(wǎng)絡(luò)高度動(dòng)態(tài)變化，各個(gè)端的網(wǎng)絡(luò)能力可能有差異，RTC廠商把視頻會(huì)議中的Simulcast大小流技術(shù)引入到RTC作為標(biāo)準(zhǔn)能力，解決SFU到終端之間網(wǎng)絡(luò)狀態(tài)適配問題。但Simulcast會(huì)增加上傳的帶寬和視頻編碼壓力。除了Simulcast，有些廠商也引入SVC來解決此類問題。

4.語音帶內(nèi)冗余編碼技術(shù)

聲音在移動(dòng)弱網(wǎng)下比視頻敏感，有些業(yè)務(wù)聲音傳輸質(zhì)量要求高于視頻，例如在線教育。這就帶來了一個(gè)媒體優(yōu)先保證的需求，所以帶內(nèi)語音編碼技術(shù)成為RTC PaaS廠商的標(biāo)配。

5.QUIC與RUDP

RUDP在2005年左右就有相對(duì)應(yīng)的開源項(xiàng)目，因?yàn)镹AT穿越的關(guān)系，當(dāng)時(shí)最主要的應(yīng)用是用來做點(diǎn)對(duì)點(diǎn)文件傳輸。2013年，Google開始研發(fā)可靠UDP技術(shù)，并將這個(gè)項(xiàng)目命名為QUIC, 旨在應(yīng)用于HTTP/2.0的多路復(fù)用優(yōu)化上。QUIC從提出到成為標(biāo)準(zhǔn)道阻且長(zhǎng)。不過QUIC率先在直播推流端解決推流延遲和抗弱網(wǎng)，因?yàn)楸葌鹘y(tǒng)TCP效果好，一時(shí)間QUIC在推流端大量應(yīng)用。

由于實(shí)時(shí)富媒體通信的場(chǎng)景需求，RTC在原有的實(shí)時(shí)通信鏈路上實(shí)現(xiàn)了一個(gè)基于可靠UDP的數(shù)據(jù)傳輸通道來解決實(shí)時(shí)富媒體交互問題，這類技術(shù)和QUIC不謀而合，大有合并之勢(shì)。

• 媒體處理AI化

由于直播時(shí)代大發(fā)展和深度學(xué)習(xí)技術(shù)突破，前期簡(jiǎn)單的濾鏡美顏功能已經(jīng)不能滿足需求了，各大廠商從美圖秀秀這類照片應(yīng)用中獲得靈感，將其算法應(yīng)用到實(shí)時(shí)視頻當(dāng)中，開啟了全民美顏直播模式。

除了美顏濾鏡AI化外，媒體算法還有：超分顯、AI編碼、虛擬渲染、頭像替換、背景摳圖、變聲、AI回聲消除、AI降噪等等，一大票優(yōu)秀的算法正在路上。

• SFU?Fullmesh

單SFU架構(gòu)有用戶接入和可用性方面的問題，云SFU用BGP接入解決用戶接入問題。將SFU做了平行擴(kuò)展（見圖-8），同一個(gè)頻道用戶可以接入到多個(gè)對(duì)等的SFU進(jìn)行實(shí)時(shí)音視頻通信，很好地消除了服務(wù)異常造成不可用的缺陷，這種架構(gòu)還能跨IDC部署，實(shí)現(xiàn)7x24小時(shí)的云服務(wù)。

圖-8：SFU fullmesh示意圖

• 旁路服務(wù)

由于直播、教育等業(yè)務(wù)都是需要審核監(jiān)控和錄制相關(guān)的需求，RTC后端除了SFU Fullmesh變化外，還引入了旁路網(wǎng)關(guān)單元，旁路網(wǎng)關(guān)功能繁多，包括：實(shí)時(shí)錄制、AI內(nèi)容審核、合流CDN推流、其他協(xié)議接入（小程序網(wǎng)關(guān)/PSTN）等。

• RTC?QoE

RTC PaaS廠商為了數(shù)值化媒體通信質(zhì)量和體驗(yàn)，提出了基于用戶體驗(yàn)的QoE指標(biāo)，將音視頻的卡頓次數(shù)和時(shí)長(zhǎng)、連接時(shí)長(zhǎng)和成功率、碼率波動(dòng)、首屏?xí)r間、鏈路異常恢復(fù)時(shí)長(zhǎng)等數(shù)據(jù)QoE化，用QoE來保證RTC技術(shù)迭代的質(zhì)量。

?架構(gòu)小結(jié)

在移動(dòng)互聯(lián)網(wǎng)大發(fā)展時(shí)期，終端設(shè)備和接入網(wǎng)絡(luò)發(fā)生了很大變化，這迫使RTC在終端傳輸技術(shù)和媒體處理算法上做了大的革新，并催生了云計(jì)算的大規(guī)模落地。云計(jì)算大規(guī)模部署B(yǎng)GP網(wǎng)絡(luò)，提供便捷的IaaS能力，促使了RTC PaaS廠商的興起，云SFU Fullmesh架構(gòu)與直播CDN、AI等技術(shù)融合，如下圖：

圖-9:RTC云SFU示意圖

優(yōu)點(diǎn)：充分利用了云計(jì)算基礎(chǔ)設(shè)施的穩(wěn)定來解決網(wǎng)絡(luò)接入異構(gòu)性問題，提高運(yùn)維效率，優(yōu)化客戶端的傳輸算法來提高通信的穩(wěn)定性和質(zhì)量，保證7x24服務(wù)。

缺點(diǎn)：在大規(guī)模RTC領(lǐng)域BGP帶寬成本過高，無法像CDN利用邊緣節(jié)點(diǎn)帶寬來提升傳輸效率和降低成本；在跨國(guó)超長(zhǎng)距離RTC通信當(dāng)中雖然可以利用分布式SFU架構(gòu)解決就近接入，但很難降低SFU之間的傳輸延遲，而且架構(gòu)過分依賴公有云導(dǎo)致可擴(kuò)展性和靈活性不夠。

全球?qū)崟r(shí)云通信階段

教育大規(guī)模線上化和中國(guó)音視頻產(chǎn)品出海預(yù)示著全球?qū)崟r(shí)通信階段的到來，2020年開始全球疫情加速了RTC音視頻通信在各行業(yè)的落地，一方面在線課堂、在線辦公、企業(yè)協(xié)同、直播帶貨等出現(xiàn)了大量RTC應(yīng)用場(chǎng)景，另外一方面RTC流量成本居高不下，場(chǎng)景流量暴增和成本居高不下之間的矛盾日益嚴(yán)峻，催生了新一代RTC架構(gòu)迭代。這個(gè)階段主要是兩個(gè)問題：

1.如何將RTC流量成本降下來？

2.如何保證下沉用戶和跨國(guó)長(zhǎng)距離通信的質(zhì)量？

為了解決上面的問題，聲網(wǎng)2016年首先研發(fā)出基于SDN架構(gòu)的SD-RTN技術(shù)來構(gòu)建全球?qū)崟r(shí)通信網(wǎng)絡(luò)（圖-10），利用廉價(jià)的邊緣節(jié)點(diǎn)和獨(dú)特的智能路由加速技術(shù)讓全球端到端延遲控制在400ms以內(nèi)。

圖-10:?全球RTN示意圖

從架構(gòu)上來看，SD-RTN借鑒了早期Skype的P2P覆蓋網(wǎng)架構(gòu)，并開創(chuàng)性地與SDN架構(gòu)相結(jié)合來定義全新的RTN網(wǎng)絡(luò)，用邊緣計(jì)算節(jié)點(diǎn)代替P2P super node，增強(qiáng)了穩(wěn)定性，而采用中心計(jì)算全局的路由又充分地利用了云計(jì)算特點(diǎn)來控制邊緣計(jì)算節(jié)點(diǎn)的傳輸行為，不僅增加了傳輸網(wǎng)絡(luò)的可控性，也保證了分布式節(jié)點(diǎn)之間的數(shù)據(jù)安全。

RTN設(shè)計(jì)目標(biāo)是通過橫向分層架構(gòu)來降低系統(tǒng)的耦合度，讓音視頻RTC系統(tǒng)專注業(yè)務(wù)邏輯，讓網(wǎng)絡(luò)算法和網(wǎng)絡(luò)架構(gòu)工程師發(fā)揮自己的長(zhǎng)處來滿足通信QoS的需要。RTC相關(guān)的服務(wù)之間相當(dāng)于內(nèi)網(wǎng)通信，讓服務(wù)不需要關(guān)心機(jī)房和物理位置的限制，整體像是在同一個(gè)IDC機(jī)房當(dāng)中，簡(jiǎn)化開發(fā)和部署。

RTN的出現(xiàn)直接導(dǎo)致了終端到Server 、Server到Server之間通信的解耦，RTN專注于Server之間的加速，終端與Server之間慢慢演變成了類QUIC的半可靠RUDP協(xié)議通信（如圖11）。正因?yàn)镽TN架構(gòu)能有效解決以上兩方面的問題，又符合未來邊緣計(jì)算趨勢(shì)，所以各大RTC廠商都紛紛跟進(jìn)研發(fā)自己的RTN組網(wǎng)技術(shù)，所以最近幾年各種名字的RTN網(wǎng)絡(luò)都出來了。

????????

圖-11：Client/Server與RTN關(guān)系圖

?關(guān)鍵技術(shù)

• 邊緣計(jì)算容器

RTN要實(shí)現(xiàn)簡(jiǎn)化部署和充分利用邊緣節(jié)點(diǎn)的能力，那么必不可少地需要引入邊緣容器技術(shù)，通過Docker和K8s實(shí)現(xiàn)計(jì)算資源的統(tǒng)一管理和調(diào)度。

• 智能調(diào)度

智能調(diào)度有兩個(gè)方面：終端Lastmile接入調(diào)度與系統(tǒng)帶寬流量調(diào)度。終端Lastmile是調(diào)度系統(tǒng)精確將終端調(diào)度到最近的邊緣RTN節(jié)點(diǎn)上進(jìn)行業(yè)務(wù)接入，流量調(diào)度是根據(jù)業(yè)務(wù)的特點(diǎn)進(jìn)行資源預(yù)留和削峰填谷，讓通信成本和質(zhì)量控制在一個(gè)平衡點(diǎn)上。

• 智能路由與多鏈路備份

RTN網(wǎng)絡(luò)的邊緣節(jié)點(diǎn)會(huì)實(shí)時(shí)向中心控制器匯報(bào)自己的通信狀態(tài)，中心控制器收到這些通信狀態(tài)后會(huì)對(duì)正常和異常的數(shù)據(jù)進(jìn)行處理，并作為計(jì)算路由的數(shù)據(jù)依據(jù)。中心控制器得到各個(gè)節(jié)點(diǎn)數(shù)據(jù)會(huì)通過實(shí)時(shí)智能最短路徑等算法進(jìn)行路由計(jì)算。對(duì)于優(yōu)先級(jí)比較高的業(yè)務(wù)會(huì)采用多路徑備份策略來保證通信的穩(wěn)定和質(zhì)量。

• 虛擬組網(wǎng)技術(shù)

RTN邊緣計(jì)算節(jié)點(diǎn)分布在不同的機(jī)房，甚至有些橫跨洲洋上萬公里，這就需要實(shí)現(xiàn)一套VPN網(wǎng)絡(luò)來進(jìn)行服務(wù)之間尋址，簡(jiǎn)化通信架構(gòu)復(fù)雜度。虛擬組網(wǎng)技術(shù)是邊緣計(jì)算和RTN的關(guān)鍵技術(shù)之一。

• 終端接入?yún)f(xié)議

終端接入?yún)f(xié)議有類QUIC統(tǒng)一的趨勢(shì)，目前不管是直播推流還是RTC通信，都在朝著統(tǒng)一化走，快手2017年率先研發(fā)出基于可靠UDP的KTP協(xié)議來優(yōu)化客戶端接入問題，聲網(wǎng)AUT最近也從RTC中獨(dú)立出來作為單獨(dú)模塊應(yīng)用在它的FPA產(chǎn)品當(dāng)中。傳統(tǒng)的RTP/RTCP擴(kuò)展已經(jīng)不堪重負(fù)（見WebRTC源碼），類QUIC模型減輕了RTP/RTCP負(fù)擔(dān)，讓網(wǎng)絡(luò)算法工程師擺脫協(xié)議束縛專注于傳輸優(yōu)化，將會(huì)成為未來的趨勢(shì)。

• 分層解耦

RTN是一個(gè)路由網(wǎng)絡(luò)，從RTC中分離出來。RTC專注于通信業(yè)務(wù)，RTN專注于通信路由的計(jì)算和鏈路異常failback，那么RTC與RTN需要有一套通用的分層接口來實(shí)現(xiàn)分層解耦。

架構(gòu)小結(jié)

RTN是RTC超大規(guī)模業(yè)務(wù)場(chǎng)景的底層支撐系統(tǒng)，RTN從架構(gòu)層利用下沉的邊緣計(jì)算節(jié)點(diǎn)解決路由鏈路和通信帶寬成本問題，讓網(wǎng)絡(luò)算法、RTC、傳輸路由三者之間解耦。它是當(dāng)前RTC系統(tǒng)最為負(fù)載的系統(tǒng)。

目前RTN還沒有統(tǒng)一的標(biāo)準(zhǔn)和做法，各家廠商都是根據(jù)自身的業(yè)務(wù)特點(diǎn)構(gòu)建自己的RTN系統(tǒng)。在這里我把RTC+RTN分層架構(gòu)定義為第六代RTC架構(gòu)。RTN需要龐大的邊緣計(jì)算節(jié)點(diǎn)資源，能進(jìn)行RTN部署的都是互聯(lián)網(wǎng)大企業(yè)和有一定規(guī)模的RTC PaaS廠商。目前看來，RTN可能會(huì)讓整個(gè)RTC行業(yè)呈現(xiàn)馬太效應(yīng)。

?一些總結(jié)

綜上看來，每一次大的技術(shù)浪潮并不是由技術(shù)本身推動(dòng)的，而推動(dòng)技術(shù)浪潮要有兩個(gè)變化：終端計(jì)算帶寬能力升級(jí)（1、2、4代）和實(shí)時(shí)通信場(chǎng)景的遷徙（3、5代），這兩個(gè)變化都會(huì)帶來旺盛的用戶需求。整個(gè)RTC技術(shù)發(fā)展過程中出現(xiàn)過很多技術(shù)和架構(gòu)，大部分技術(shù)沿用至今，依然保持生命力，所以說RTC音視頻領(lǐng)域技術(shù)迭代并不是很快，但每一個(gè)技術(shù)背后的門檻卻很高，技術(shù)人員成型時(shí)間較長(zhǎng)，所以一般RTC音視頻領(lǐng)域沒有35歲問題。

RTC技術(shù)領(lǐng)域有其自身的特點(diǎn)，關(guān)注用戶側(cè)感受和訴求是從事這方面技術(shù)人員很容易忽視的。例如：流媒體在用戶側(cè)的感受并不敏感，技術(shù)上HEVC/AV1比AVC提高多少倍壓縮效率，用戶側(cè)感受到的可能是手機(jī)燙不燙手，耗不耗電。宣傳固然重要，但技術(shù)不應(yīng)該忽略用戶感受去談先進(jìn)性。

技術(shù)迭代不是一個(gè)數(shù)字比武過程，不是誰的數(shù)字指標(biāo)高就會(huì)成為主流技術(shù)的，技術(shù)迭代過程是一個(gè)趨同效應(yīng)，能契合某一類大規(guī)模應(yīng)用場(chǎng)景往往會(huì)成為主流或者標(biāo)準(zhǔn)，作為從業(yè)人員不應(yīng)該死盯技術(shù)指標(biāo)上，用更高的技術(shù)指標(biāo)去打敗行業(yè)先行者是非常困難的，所以在固有領(lǐng)域里面盲目的技術(shù)精進(jìn)也是一種故步自封，后來者應(yīng)該盡力找到技術(shù)更廣闊的應(yīng)用場(chǎng)景形成新趨勢(shì)。

后疫情時(shí)代RTC成為內(nèi)卷嚴(yán)重的領(lǐng)域，一方面終端能力沒有升級(jí)，另一方面疫情期間帶來的應(yīng)用場(chǎng)景流量出現(xiàn)了消退的跡象，巨頭橫行，而新場(chǎng)景還沒有出現(xiàn)。但高分辨率、實(shí)時(shí)虛擬現(xiàn)實(shí)等高碼率應(yīng)用剛剛萌芽，超大碼率會(huì)讓UDP協(xié)議給kernel帶來的負(fù)擔(dān)越來越大，高帶寬與低延遲、大并發(fā)的矛盾將會(huì)在新的場(chǎng)景更加尖銳，新一代的RTC架構(gòu)有可能會(huì)出現(xiàn)TCP/UDP孿生模式。作為技術(shù)人的我依然對(duì)未來抱有希望，現(xiàn)在最期待的是第六代RTC架構(gòu)什么時(shí)候到來，想必那時(shí)定是一個(gè)更加波瀾壯闊的時(shí)代。

---

掃描圖中二維碼或點(diǎn)擊閱讀原文

了解大會(huì)更多信息

喜歡我們的內(nèi)容就點(diǎn)個(gè)“在看”吧！

總結(jié)

以上是生活随笔為你收集整理的历经5代跨越25年的RTC架构演化史的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。