作者 | 袁榮喜
技術審校 | 吳鵬強
內容編輯 | Alex
RTC架構演化史視 野
#008#
隨著移動網際網路普及和疫情疊加，實時通信技術（RTC）一時間成為炙手可熱的技術方向，RTC從1996年開始到如今已經發展成為一個非常複雜的技術領域，其包含了網絡傳輸、全局調度、媒體處理算法、媒體編解碼、信令協議、輸入輸出設備、Web、作業系統等相關的技術，至今為止發展了25年。這期間伴隨網際網路發展經歷了多次技術疊代，從網絡通信架構演化過程來看可把它分為5個階段（這裡稱為5代），每個階段RTC從終端技術到通信架構都有大的技術變化。
第1代：MCU階段（1996~2004年）
第2代：P2P階段（2001~2007年）
第3代：單SFU階段（2003~2012年）
第4代：雲SFU階段（2010~2017年）
第5代：全球實時雲通信階段（2016至今）
可以說每一代都是風起雲湧的時代，每一代又都是「卷王「的時代。這裡我不去「卷」RTC某一領域的技術細節和應用，而是通過分析這5個階段的大環境背景和用戶側場景訴求是如何推動RTC技術演化變遷的，來幫助大家更好地理解RTC這個技術領域，也是對自己音視頻從業以來的一個總結。
MCU階段
上個世紀90年代中期，隨著WWW網際網路的崛起，大量的終端用戶通過電話線撥號湧入網際網路，當時上網的終端網速只有56kbps（俗稱56K貓），看網頁、下載圖片有時候需要數十秒鐘。網速慢且流量昂貴，但企業和個人都有通過PC聯網的強烈需求。
- 企業場景：通過PC互聯實現內部線上會議替代傳統的電話會議，企業信息融合通信。
- 個人場景：通過PC互聯實現點對點實時語音溝通。
H.323
在這種大背景下，ITU（國際電信聯盟）基於傳統PSTN架構在1996年率先推出H.323/RTP的IP網絡多媒體標準，並在H.323協議中提出了MCU和網關的概念，與此同時IETF組織也在1996年發布了RTP規範（RTC1989），並在後續規範中進一步完善了RTP/RTCP體系（RFC3550/3551），ITU後來將這幾個規範合併到H.323標準當中。H.323架構如下：
圖-1:H.323架構
H.323標準不僅指定了傳輸協議RTP，它還制定了媒體編碼規範（G.7xx/H.261/H.263）、媒體協商協議（H.245）、信令協議（RAS/H.225）、網絡安全協議(H.235)等。其中媒體編碼影響深遠，幾乎現在實時音視頻編碼算法都是從這裡演化而來。H.323標準定義了點對點通信和多人會議通信，點對點通信和多人會議通信的差別是點對點通信的媒體是終端直接通信，而多人會議媒體需要經過MCU，MCU按需重編碼合流後進行媒體數下發。這裡不得不提一句，H.323的ASN.1協議編碼技術確實精妙，但也沒逃過被淘汰的命運。
架構小結
H.323架構後續在網際網路應用中受限於網絡NAT和終端帶寬問題，從而迅速演化成單中心MCU服務模式，MCU既負責網絡媒體合流也負責信令接入，即第一代MCU架構：
圖-2: MCU架構
優點：增強了Client的聯通性，合流讓終端的下行帶寬縮小，讓Client在當時帶寬下可以獲得可通話的質量。
缺點：MCU的計算量大，中心合流帶來的擴展性比較差，容易引來系統瓶頸。
MCU架構是在網際網路初期終端帶寬稀缺且昂貴的條件下產生的架構，終端的形態也各式各樣，PC、IP話機、PBX網關等。隨著PC網際網路的到來，這一切迅速發生了改變。
P2P階段
PC網際網路的發展促使了PC終端網絡的快速疊代。1999年，ITU批准了ADSL技術成為寬帶標準，下載速度可達8Mbps，上行可以到1Mbps，ADSL利用原有電信線路搭建起來的終端接入方式迅速鋪開。ADSL解決了終端帶寬瓶頸問題，一時間IM社交（OICQ/MSN）和P2P下載服務（KaZaA/BT/eMule/迅雷）成為PC網際網路的主宰。同時摩爾定律繼續發揮效應，終端PC的計算能力進一步加強，已經出現雙核CPU。終端設備的升級使得個人用戶的網際網路通信成為主流並形成了新的實時通信需求，同時也給RTC通信帶來新的變革和機會，其主要場景包括：
企業場景：基於VPN-Lan的VoIP通信，企業希望通過網際網路接入能力構建自己內部的IP語音通信網絡。
個人場景：社交IM場景下的1V1實時音視頻通信，免費的IP語音服務替代傳統的PTSN收費服務，同時社交類的視頻需求變得強烈。
RTC技術黃金期
正是終端計算能力和帶寬能力大幅提升，RTC技術形成了黃金髮展時期，出現了眾多影響至今的技術和模型。
- SIP/SDP協議
IETF針對網際網路實時通信提出自己的信令標準SIP和媒體協商協議SDP，SIP協議採用UDP+HTTP文本方式實現協議編碼，連接過程原語遵循了電話呼叫的流程。其簡單直接的方式一經推出後就獲得了很多廠商的支持，這時就面臨與原來H.323協議交換互通的問題。在此情況下，各大廠商雄心壯志地試圖借鑑傳統交換機模型移到IP軟體交換上來統一各端設備通信，形成了當時流行的軟交換系統。
值得思考的是，為什麼當時簡潔的SIP協議在VoIP上迅速替代了成熟的H.323技術體系？
- P2P實時通信
終端帶寬能力的增強和P2P文件下載技術的大規模應用，促使實時音視頻通信可以完全基於終端之間完成，企業的VoIP在這個時候得到了大量的落地（圖-3），這種模式更加經濟和高效。
圖-3:基於SIP的VoIP架構
除了通信關係上的變化外，在P2P系統中發展出來了很多新的網絡傳輸技術，例如：STUN/TURN穿越技術、ICE技術、RUDP技術、數據切片組幀技術等等。在此之前並沒有這些技術標準，這些技術是在當時遇到實際問題時創造出來的。
- GIPS 封神
由於終端大量使用PC，早期的PC系統上並沒有對聲音的DSP處理，這導致使用PC進行實時語音通信的時候會出現大量的回聲、噪聲、聲音抖動、丟包顫音等問題。當時優秀的聲音處理算法都是以DSP捆綁硬體的方式提供，PC獲得和傳統電話一樣的通話質量成為最迫切的需求。
瑞典GIPS公司創造性地將DSP的聲音算法移植到PC系統上，充分利用PC強大的計算能力對聲音算法進行大膽創新，並開發出了獨特的3A算法（AEC/AGC/ANS）、網絡抗抖算法（NetEQ）、高質量語音編碼器（iSAC）。當時大部分網際網路巨頭都使用了GIPS，QQ2018PC版本裡還有GIPS的版權說明呢。後來GIPS被Google收購，它與GTalk的libjingle合併成為早期WebRTC的一部分，這是後話了。
- 視頻編碼王者H.264
個人社交服務的興起，在需求側實時視頻通信已經迫在眉睫，當時實時視頻編碼分布在兩個陣營：ITU的H.263和ISO的MPEG4，H.264是ITU-T以H.26x系列為名稱命名的視頻編解碼技術標準之一，該標準結合了 H.323協議中的H.263協議和MPEG-4協議，解決了目前基於軟體視頻會議MPEG-4標準沒有辦法與H.323協議的終端兼容問題，使其成為目前最好的視頻壓縮協議。H.264在計算功耗和壓縮率之間有非常好的平衡，是RTC視頻通信的基石，縱橫視頻編碼二十載，如今依然是編碼器中的王者。
值得思考的是，為什麼後來的視頻編碼器沒有替代掉H.264？僅僅是專利問題麼？
- 第一個全球實時通信網絡——Skype
當時個人用戶的社交需求使得各大IM廠商都實現了自己內部的實時音視頻通信功能，不過很不幸的是，當時IM廠商主要還是集中在文字消息上，很多軟體音視頻功能的連通率不到30%，網絡一旦波動，通話質量無法保證，甚至會出現斷線情況。P2P音樂下載軟體KaZaA的作者用獨特的FastTrack協議構建了第一個全球覆蓋的實時通信網絡，結合GIPS語音引擎在這個實時網絡上進行語音通信，這就是當時著名的Skype。Skype解決了當時社交產品上的幾個問題：
1）語音連通性和NAT穿越問題，將連通性提高到95%以上。
2）結合GIPS解決了PC端上通話音質問題。
3）利用P2P的全局索引與UDP overlay技術解決了全球覆蓋問題。
4）利用P2P的超級節點技術優化通信路徑延遲和跨國跨運營商網絡問題，全球通話延遲在500ms以下。
5）利用數字加密技術解決端到端媒體數據安全問題。
圖-4:Skype網絡架構示意圖
Skype開創了非常多的新技術，主要包括以下幾方面：
1）全局索引調度技術，可以通過P2P算法在網絡中找到並調度所需要的通話資源節點。
2）Lastmile就近super node接入，而不是單純的點對點直連。
3）路由實時計算，通信時實時計算和調整傳輸路徑。
4）STUN/TURN/ICE技術，Skype首次提出並使用ICE技術。
5）端到端媒體數據加密技術，Skype首次大規模使用數字簽名和媒體加密（RSA/AES/rc4）保證通話安全。
6）UDP Overlay實時通信覆蓋網絡。
架構小結
由於PC終端能力增強，RTC的架構從MCU架構演化成了基於每個流的P2P Mesh架構（圖-5），這種架構脫離中心服務的束縛，轉變成去中心化的服務模型。最先把這個模型用到極致的是Skype，它的語音服務質量和穩定性堪比PSTN。
2005年，Skype被eBay以26億美金收購。後面諸多社交IM服務產品跟進形成內卷的局面，就連技術宗神Google當時也山寨了一個GTalk。
圖-5:RTC P2P架構示意圖
優點：後台服務輕量，架構擴展性強，開發編程簡單，只需要名字定位和信令協商等。通信由Endpoint之間自己完成，適合1V1方式通信。
缺點：服務質量完全依賴於各個終端的網絡環境和穩定性，連通性差，各端能力差異會引來通信差異。對於跨國跨運營商的通信無法保證通話QoS，去中心化後對於敏感通話信息無法進行中心管理監控，有政治安全風險。
SFU階段
網絡MMO RPG遊戲的興起使得遊戲社區開始萌芽，遊戲領域的實時溝通成了一個強需求，國外首先誕生了基於speex語音引擎的TS軟體。在國內，由於傳奇和魔獸世界的流行，國內模仿TS軟體誕生了iSpeaker和YY。遊戲內部實時協作不僅對通信質量和穩定性要求很高，也同時要求減少PC的資源占用。由於大量用戶使用類直播的多人溝通方式，在遊戲語音軟體首先出現了Web 2.0模式，用戶自發組織成了一個個內容社區（家族和頻道），頻道內部除了遊戲溝通外，平時也會出現直播類娛樂節目。
非典時期，新浪UC在IM競爭中敗北，轉而研發出基於多視頻互動的直播聊天室大放異彩，後續從中又演化出9158、六間房等產品。2011年底，YY在其大頻道加入單視頻直播模式，直播方式在這個階段成了主要流量。由於直播表演可以更好地展現主播形象，出現了專業音效卡硬體設備、美顏攝像頭設備、虛擬直播伴侶軟體。
這個階段企業應用發展相對緩慢，但值得一提的是，視頻會議軟體逐步開始代替企業VoIP信息融合通信。這個時期出現了WebEx、Ploycom等視頻會議廠商，視頻會議軟體採用簡單、容易部署的架構（類似現在的SaaS 服務）。
值得思考的是，為什麼單純的視頻會議會替代掉融合PSTN的VoIP？
社區模式下的RTC技術
社區模式使得RTC重新回到了傳輸的Client/Server模式，Client負責個人媒體數據收發和錄製播放，Server負責控制和傳輸轉發，前後端側重的技術點不一樣，給社區場景帶來了後面的技術轉變。
- 基於媒體流的SFU
頻道對象的實時通話不可能基於MCU去混流轉發，為了滿足客戶端按需拉流的需求，發展出了基於Publish/Subscribe的流訂閱技術。這個技術在遊戲語音場景首先實現，後被延展到秀場直播和視頻會議場景。
- 萬路語音頻道
為了滿足頻道多人互動需求，YY在2008年左右開發出萬人語音頻道，很快iSpeaker和其他的遊戲語音廠商也開始跟進。萬人語音頻道還是有很大的技術挑戰，當時大部分廠商採用的是單物理機的SFU模式，相當於單個機器並發UDP包事件在20萬/秒左右。在2012年的ChinaJoy上，YY利用自己的分布式UDP Overlay架構成功支持了單頻道120萬人線上觀看直播，這是RTC技術上的里程碑。後來直播逐步Web化，媒體分發開始大量使用CDN，催生了CDN與直播的發展，這是另外的話題。
- Proxy接入技術
基於流的SFU模型雖然利用了Server強大的控制轉發能力，減輕了終端上傳壓力，但不能解決用戶接入的網絡分區和長距離傳輸問題，在SFU架構基礎上，有些廠商開始引入Proxy接入技術來解決客戶端接入分區問題（見圖-6）。
圖-6：SFU與Proxy示意圖
Proxy可以很好地解決Client就近接入的問題，Proxy利用機房間的穩定的傳輸網絡或者專線能力，可以提供比較穩定的傳輸質量。Proxy具有數據同機交換轉發能力，但轉發關係還需要中央的SFU來進行控制決策。後面的雲SFU架構是在Proxy基礎上演化而來的。
- 前端媒體處理
這個階段出現了頻道直播場景，表演性質決定了主播需要展示更好的一面。在這種強需求推動下，首先出現了媒體前處理的硬體設備，而後又出現了帶有濾鏡、特效、簡單美顏的PC直播伴侶軟體，其中最具有代表性的是MVBox和六間房直播伴侶。
- Web化與開源
PC網際網路的後期，用戶增長出現了瓶頸，為了降低用戶使用門檻和增加留存，市面上產品都開始Web化，當時最具代表性的是Web桌面應用。RTC技術領域也不例外，在Skype早期就使用了瀏覽器激活協議在Web上激活native軟體並進行呼叫，這個方式被WebEx和Zoom一直沿用到現在，如今所有視頻會議產品都有Web入會的功能。
2010年，Google收購GIPS引擎和ON2，將GIPS、ON2（VP8前身） 和GTalk通信庫合併；2011年，Google將庫納入Chrome體系並開源，並命名為WebRTC。第一版本的WebRTC只提供native庫，2012年它獲得各大瀏覽器廠商支持並納入W3C標準，自此才基本能支持Web形式的實時音視頻通信。WebRTC的開源是RTC技術領域的里程碑事件，大大降低了RTC開發的門檻，催生了後來移動網際網路RTC應用的大時代。
值得思考的是，實時音視頻一直游離在Web領域的邊緣，為什麼一直沒有出現主流的實時音視頻產品？截止如今native依然是RTC領域的主流，假如WebRTC早5年出現或許會成為RTMP這樣的CDN分發技術。
架構小結
這個階段RTC出現了大規模直播表演類的應用，使得SFU架構迅速成型並大規模應用，SFU架構很好地分離了客戶端和服務端功能，SFU專注於控制與傳輸轉發。由於應用場景變化和終端計算能力進一步增強，終端出現了圖像聲音相關的前處理應用。SFU架構簡潔（見圖-7），適合大規模和超大規模實時音視頻互動場景。
圖-7:SFU架構示意圖
優點：基於流Publish/Subscribe模式靈活，可以非常簡單地實現各種多人互動場景，也可以節省Client端的帶寬和上行能力，比較容易實現旁路監控和風險管控。
缺點：單SFU應對網絡傳輸的分區性差，就近接入需要引入Proxy。單SFU服務可用性差。對於跨地區長距離很難保證實時通信質量，分發效率和質量並與後來的CDN有差距。
雲SFU階段
智慧型手機的誕生讓網際網路從PC時代邁向了移動時代，終端由計算能力強的PC開始向計算能力弱的手機轉移，終端的網絡瞬間由原來的有線接入轉向了WiFi和3G/4G。由於終端的變遷和用戶的激增，為了解決服務後端擴展性、穩定性和運維效率問題，在原來分布式系統基礎上衍生出來了雲計算。為了消除終端與服務的連通性問題，機房服務端的網絡開始大量部署BGP。這個巨大的改變使RTC應用場景發生了轉變。這個階段有三個特點：
1)終端計算能力削弱，網絡接入向不穩定的無線（WiFi/3G/4G）接入遷移。
2)後端計算能力增強，網絡消除了分區連通問題。
3)聯網用戶激增，RTC原來的社交、遊戲、娛樂直播等領域進一步滲透，RTC擴展到教育、電商和金融。
雲時代方向
正因如此，RTC在2014年出現了對外提供RTC雲計算PaaS服務商網易雲信和聲網，而後toB的PaaS服務商如雨後春筍，RTC領域正式進入指標內卷時代。RTC PaaS開始階段是部署在雲IaaS上的SFU，直接利用了IaaS基礎設施能力，簡化了SFU架構，這個架構簡稱為雲SFU。
在線教育開始萌芽，RTC除了音視頻通信以外還產生了富媒體的實時通信需求：課件同步與書寫同步。富媒體同步需求讓RTC產生了實時可靠傳輸數據能力，在此基礎上演化出來實時互動白板。
娛樂直播領域視頻解析度整體提高，甚至出現720P/1080P的實時視頻直播，此時CDN接管了音視頻分發，RTC主要應用在直播連麥和推流測，在這個場景當中RTC產生了諸多新技術。
企業辦公移動化，視頻會議產品開始移動化，標誌性產品Zoom。
除了以上幾個典型RTC方向外，還有更多其他領域的應用方向，這裡也就不細說了。總之雲時代旺盛需求讓RTC迎來了一次巨大的技術疊代。
雲時代的RTC技術
- 終端傳輸算法的升級
視頻的解析度和碼率爆炸性的增加，而終端接入從原來的有線接入轉變為無線接入方式，網絡質量受周圍環境的影響加大，而且時刻處於高度變化當中，那麼在一個高度變化的網絡上提供穩定的實時通信的需求就變得異常強烈。在這個階段，各大RTC PaaS使出渾身解數，各展絕技，不斷提高技術指標和效果，toC產品的技術部門緊跟其後，所以我們在LiveVideoStackCon技術大會上總能聽到這方面的議題。這些傳輸算法主要包括以下幾個方面：
1.擁塞控制
WebRTC在2015年左右引入基於卡爾曼濾波的GCC擁塞控制算法，經過不斷的試驗調整，在2018年左右改為發送端計算的TCC。而後WebRTC又引入了Google的BBR和PCC，後續的測試當中BBR在視頻傳輸不理想又刪除了，PCC還在測試當中。國內的廠商後續跟進，都在擁塞控制方面做了很多的微創新。
2.FEC、ARQ與NACK
FEC：WebRTC在第一次推出時帶有最簡單的Xor的FEC，後續加入了ulpFEC和FlexFEC。國內雲廠商創造性地用RS糾刪碼實現了新的FEC算法，實驗室環境抗丟包可以達到80%，真實環境效果有多少就不得而知了。
ARQ/NACK重傳：重傳邏輯在早期的WebRTC版本中沒有實現，2015年後開始加入其中，NACK會拉大通信的延遲，所以在鏈路RTT延遲較小時效果比較明顯。
3.Simulcast與SVC
由於終端網絡高度動態變化，各個端的網絡能力可能有差異，RTC廠商把視頻會議中的Simulcast大小流技術引入到RTC作為標準能力，解決SFU到終端之間網絡狀態適配問題。但Simulcast會增加上傳的帶寬和視頻編碼壓力。除了Simulcast，有些廠商也引入SVC來解決此類問題。
4.語音帶內冗餘編碼技術
聲音在移動弱網下比視頻敏感，有些業務聲音傳輸質量要求高於視頻，例如在線教育。這就帶來了一個媒體優先保證的需求，所以帶內語音編碼技術成為RTC PaaS廠商的標配。
5.QUIC與RUDP
RUDP在2005年左右就有相對應的開源項目，因為NAT穿越的關係，當時最主要的應用是用來做點對點文件傳輸。2013年，Google開始研發可靠UDP技術，並將這個項目命名為QUIC, 旨在應用於HTTP/2.0的多路復用優化上。QUIC從提出到成為標準道阻且長。不過QUIC率先在直播推流端解決推流延遲和抗弱網，因為比傳統TCP效果好，一時間QUIC在推流端大量應用。
由於實時富媒體通信的場景需求，RTC在原有的實時通信鏈路上實現了一個基於可靠UDP的數據傳輸通道來解決實時富媒體交互問題，這類技術和QUIC不謀而合，大有合併之勢。
- 媒體處理AI化
由於直播時代大發展和深度學習技術突破，前期簡單的濾鏡美顏功能已經不能滿足需求了，各大廠商從美圖秀秀這類照片應用中獲得靈感，將其算法應用到實時視頻當中，開啟了全民美顏直播模式。
除了美顏濾鏡AI化外，媒體算法還有：超分顯、AI編碼、虛擬渲染、頭像替換、背景摳圖、變聲、AI回聲消除、AI降噪等等，一大票優秀的算法正在路上。
- SFU Fullmesh
單SFU架構有用戶接入和可用性方面的問題，雲SFU用BGP接入解決用戶接入問題。將SFU做了平行擴展（見圖-8），同一個頻道用戶可以接入到多個對等的SFU進行實時音視頻通信，很好地消除了服務異常造成不可用的缺陷，這種架構還能跨IDC部署，實現7x24小時的雲服務。
圖-8：SFU fullmesh示意圖
- 旁路服務
由於直播、教育等業務都是需要審核監控和錄製相關的需求，RTC後端除了SFU Fullmesh變化外，還引入了旁路網關單元，旁路網關功能繁多，包括：實時錄製、AI內容審核、合流CDN推流、其他協議接入（小程序網關/PSTN）等。
- RTC QoE
RTC PaaS廠商為了數值化媒體通信質量和體驗，提出了基於用戶體驗的QoE指標，將音視頻的卡頓次數和時長、連接時長和成功率、碼率波動、首屏時間、鏈路異常恢復時長等數據QoE化，用QoE來保證RTC技術疊代的質量。
架構小結
在移動網際網路大發展時期，終端設備和接入網絡發生了很大變化，這迫使RTC在終端傳輸技術和媒體處理算法上做了大的革新，並催生了雲計算的大規模落地。雲計算大規模部署BGP網絡，提供便捷的IaaS能力，促使了RTC PaaS廠商的興起，雲SFU Fullmesh架構與直播CDN、AI等技術融合，如下圖：
圖-9:RTC雲SFU示意圖
優點：充分利用了雲計算基礎設施的穩定來解決網絡接入異構性問題，提高運維效率，優化客戶端的傳輸算法來提高通信的穩定性和質量，保證7x24服務。
缺點：在大規模RTC領域BGP帶寬成本過高，無法像CDN利用邊緣節點帶寬來提升傳輸效率和降低成本；在跨國超長距離RTC通信當中雖然可以利用分布式SFU架構解決就近接入，但很難降低SFU之間的傳輸延遲，而且架構過分依賴公有雲導致可擴展性和靈活性不夠。
全球實時雲通信階段
教育大規模線上化和中國音視頻產品出海預示著全球實時通信階段的到來，2020年開始全球疫情加速了RTC音視頻通信在各行業的落地，一方面在線課堂、在線辦公、企業協同、直播帶貨等出現了大量RTC應用場景，另外一方面RTC流量成本居高不下，場景流量暴增和成本居高不下之間的矛盾日益嚴峻，催生了新一代RTC架構疊代。這個階段主要是兩個問題：
1.如何將RTC流量成本降下來？
2.如何保證下沉用戶和跨國長距離通信的質量？
為了解決上面的問題，聲網2016年首先研發出基於SDN架構的SD-RTN技術來構建全球實時通信網絡（圖-10），利用廉價的邊緣節點和獨特的智能路由加速技術讓全球端到端延遲控制在400ms以內。
圖-10: 全球RTN示意圖
從架構上來看，SD-RTN借鑑了早期Skype的P2P覆蓋網架構，並開創性地與SDN架構相結合來定義全新的RTN網絡，用邊緣計算節點代替P2P super node，增強了穩定性，而採用中心計算全局的路由又充分地利用了雲計算特點來控制邊緣計算節點的傳輸行為，不僅增加了傳輸網絡的可控性，也保證了分布式節點之間的數據安全。
RTN設計目標是通過橫向分層架構來降低系統的耦合度，讓音視頻RTC系統專注業務邏輯，讓網絡算法和網絡架構工程師發揮自己的長處來滿足通信QoS的需要。RTC相關的服務之間相當於內網通信，讓服務不需要關心機房和物理位置的限制，整體像是在同一個IDC機房當中，簡化開發和部署。
RTN的出現直接導致了終端到Server 、Server到Server之間通信的解耦，RTN專注於Server之間的加速，終端與Server之間慢慢演變成了類QUIC的半可靠RUDP協議通信（如圖11）。正因為RTN架構能有效解決以上兩方面的問題，又符合未來邊緣計算趨勢，所以各大RTC廠商都紛紛跟進研發自己的RTN組網技術，所以最近幾年各種名字的RTN網絡都出來了。
圖-11：Client/Server與RTN關係圖
關鍵技術
- 邊緣計算容器
RTN要實現簡化部署和充分利用邊緣節點的能力，那麼必不可少地需要引入邊緣容器技術，通過Docker和K8s實現計算資源的統一管理和調度。
- 智能調度
智能調度有兩個方面：終端Lastmile接入調度與系統帶寬流量調度。終端Lastmile是調度系統精確將終端調度到最近的邊緣RTN節點上進行業務接入，流量調度是根據業務的特點進行資源預留和削峰填谷，讓通信成本和質量控制在一個平衡點上。
- 智能路由與多鏈路備份
RTN網絡的邊緣節點會實時向中心控制器匯報自己的通信狀態，中心控制器收到這些通信狀態後會對正常和異常的數據進行處理，並作為計算路由的數據依據。中心控制器得到各個節點數據會通過實時智能最短路徑等算法進行路由計算。對於優先級比較高的業務會採用多路徑備份策略來保證通信的穩定和質量。
- 虛擬組網技術
RTN邊緣計算節點分布在不同的機房，甚至有些橫跨洲洋上萬公里，這就需要實現一套VPN網絡來進行服務之間尋址，簡化通信架構複雜度。虛擬組網技術是邊緣計算和RTN的關鍵技術之一。
- 終端接入協議
終端接入協議有類QUIC統一的趨勢，目前不管是直播推流還是RTC通信，都在朝著統一化走，快手2017年率先研發出基於可靠UDP的KTP協議來優化客戶端接入問題，聲網AUT最近也從RTC中獨立出來作為單獨模塊應用在它的FPA產品當中。傳統的RTP/RTCP擴展已經不堪重負（見WebRTC源碼），類QUIC模型減輕了RTP/RTCP負擔，讓網絡算法工程師擺脫協議束縛專注於傳輸優化，將會成為未來的趨勢。
- 分層解耦
RTN是一個路由網絡，從RTC中分離出來。RTC專注於通信業務，RTN專注於通信路由的計算和鏈路異常failback，那麼RTC與RTN需要有一套通用的分層接口來實現分層解耦。
架構小結
RTN是RTC超大規模業務場景的底層支撐系統，RTN從架構層利用下沉的邊緣計算節點解決路由鏈路和通信帶寬成本問題，讓網絡算法、RTC、傳輸路由三者之間解耦。它是當前RTC系統最為負載的系統。
目前RTN還沒有統一的標準和做法，各家廠商都是根據自身的業務特點構建自己的RTN系統。在這裡我把RTC+RTN分層架構定義為第六代RTC架構。RTN需要龐大的邊緣計算節點資源，能進行RTN部署的都是網際網路大企業和有一定規模的RTC PaaS廠商。目前看來，RTN可能會讓整個RTC行業呈現馬太效應。
一些總結
綜上看來，每一次大的技術浪潮並不是由技術本身推動的，而推動技術浪潮要有兩個變化：終端計算帶寬能力升級（1、2、4代）和實時通信場景的遷徙（3、5代），這兩個變化都會帶來旺盛的用戶需求。整個RTC技術發展過程中出現過很多技術和架構，大部分技術沿用至今，依然保持生命力，所以說RTC音視頻領域技術疊代並不是很快，但每一個技術背後的門檻卻很高，技術人員成型時間較長，所以一般RTC音視頻領域沒有35歲問題。
RTC技術領域有其自身的特點，關注用戶側感受和訴求是從事這方面技術人員很容易忽視的。例如：流媒體在用戶側的感受並不敏感，技術上HEVC/AV1比AVC提高多少倍壓縮效率，用戶側感受到的可能是手機燙不燙手，耗不耗電。宣傳固然重要，但技術不應該忽略用戶感受去談先進性。
技術疊代不是一個數字比武過程，不是誰的數字指標高就會成為主流技術的，技術疊代過程是一個趨同效應，能契合某一類大規模應用場景往往會成為主流或者標準，作為從業人員不應該死盯技術指標上，用更高的技術指標去打敗行業先行者是非常困難的，所以在固有領域裡面盲目的技術精進也是一種故步自封，後來者應該盡力找到技術更廣闊的應用場景形成新趨勢。
後疫情時代RTC成為內卷嚴重的領域，一方面終端能力沒有升級，另一方面疫情期間帶來的應用場景流量出現了消退的跡象，巨頭橫行，而新場景還沒有出現。但高解析度、實時虛擬實境等高碼率應用剛剛萌芽，超大碼率會讓UDP協議給kernel帶來的負擔越來越大，高帶寬與低延遲、大並發的矛盾將會在新的場景更加尖銳，新一代的RTC架構有可能會出現TCP/UDP孿生模式。作為技術人的我依然對未來抱有希望，現在最期待的是第六代RTC架構什麼時候到來，想必那時定是一個更加波瀾壯闊的時代。