上半部分內容：海量併發低延時 RTC-CDN 系統架構設計（上）
低延時 RTC-CDN 系統的架構
傳統 CDN 直播發展多年，為了最佳化延時，業界基本上朝兩大最佳化方向：最佳化傳輸層協議和在傳輸層協議的基礎上最佳化應用層協議。
RTMP 和 HTTP with FLV 以及 HLS 底層均使用 TCP 作為傳輸層協議。針對 TCP 協議的最佳化在一定程度上可以達到降低延時的效果，比如使用全鏈路 TCP 加速方案以及替換使用 BBR 在內的更好的擁塞控制演算法。
蘋果在 2019 年推出了 LL-HLS（Low-Latency HLS），採用 chunk 編碼傳輸模式，將延遲降低到 3 秒左右。目前基於 TCP 方案的 LL-HLS 和 LL-DASH 方案的極限延遲在 2-3 秒左右。
為了最佳化 TCP 協議，業界在可靠 UDP 協議上做了很多探索。隨著大家對 Google QUIC 協議研究的深入，有不少專案和開發者，開始用 RTMP over QUIC 替代傳統的 RTMP over TCP。QUIC 是一個非常優秀的協議，現在它已經成為 HTTP3 的標準協議。但 QUIC 作為一種通用協議，它對音影片媒體不友好，也就是它沒辦法理解音影片媒體資料的具體含義，它以一視同仁的角度來對待這些媒體資料，這也是它不能徹底解決流媒體傳輸難題的根本原因。
這幾年 SRT 也得到了廣泛的應用， SRT 底層使用 UDT 協議，UDT 協議也是一個老牌的基於 UDP 的可靠傳輸協議，當然原生的 UDT 傳輸延遲是比較高的，SRT 在此基礎上做了不少的擁塞控制策略的相關最佳化以降低傳輸延時。
近兩年隨著 WebRTC 成功推廣，利用 RTC 技術實現的低延時直播技術越來越成熟，我們來看看雲信 RTC 低延時核心技術要點。
網易雲信 RTC 低延時核心技術
• 首先是抗弱網，為了對抗極限場景下 80% 的丟包，像業界常用的 FEC RED 以及 HARQ 技術大家都很熟悉，雲信除此之外還利用基於機器學習的 PLC 算來進一步提高音訊丟包後處理，並使用長參考幀 LTR 技術進一步降低影片的單幀丟失後連續參考導致的卡頓。
• 在去抖動部分，利用 Jitterbuffer和NetEQ 技術也是非常成熟的方案，我們花了很多的精力在做 Jitterbuffer 和 ARQ 以及音畫同步模組的配合策略，在抗住 2000ms 的抖動情況下，還需要保證音畫通話還是有不少工程方面的挑戰。
• 在智慧流控部分，首先一定要有優秀的頻寬估計和擁塞判斷演算法，雲信這幾年對 GCC、BBR 和 PCC 等演算法深入研究，融合各演算法的優勢，自研了一套穩定可靠的擁塞控制演算法，可以保證頻寬利用率在限制網路下達到 90%+；同時流控要做好必須做好全鏈路的反饋和源側的響應，雲信利用多層 Simulcast 和 SVC 技術增加了增加了調控的維度，同時利用全鏈路 VQC 技術保證影片全鏈路的效果。
• 除了端側的 QoS，雲信這幾年在服務端全鏈路分段 QoS 部分也做了很多實踐。所謂分段 QoS，其實總結來說就是上行和下行的抗丟包要分段，頻寬估計要分段，只要這樣才能在服務端上針對每個使用者的下行網路做最優的適配。
• 另外，第一公里加速是做好上行 QoS 的重點，包括根據地理位置的就近接入、動態排程以及 MultiPath 的多路徑都是很關鍵的技術。
• 要做好 QoS 一套完善的雲端下發與自適應引數配置服務是必不可少的，除了適配數千款各機型的引數，還需要做差異化場景的自動適配，各個客戶端的差異化能力需要做好能力協商和能力降級，保證各個客戶端都能有一個最優體驗。
如何構建低延時 RTC-CDN 分發網路
在前面介紹雲信的流媒體伺服器架構時，已經提到了雲信媒體伺服器使用的無向圖的拓撲結構，同時為了提升使用者就近接入的效果，雲信在全球各地部署了大量的邊緣節點，邊緣節點之間利用 WE-CAN 大網的路由節點來保證節點之間的網路傳輸效果。
常規的 RTC 房間，為了儘量減少端到端的延時，基本上採用的是 Full Mesh 的網狀拓撲結構，儘量讓使用者就近接入。但是在房間人數不斷上漲，到達萬人乃至十萬人大房間以後，網狀拓撲的分發壓力和級聯成本都會大大上漲，在這種場景下網狀拓撲已經無法滿足業務的需求。為了解決這種問題，就需要採用類 CDN 的樹狀拓撲結構，針對一路上行流使用一棵樹來做訂閱者的分發。在雲信實現的方案中，利用 WE-CAN 大網的路由節點和邊緣伺服器節點，可以自動適配網狀和樹狀結構，透過流級別的排程策略自動調整每條流的分發拓撲。該方案在低延時直播場景下特別適用，低延時直播將延時控制在 1 秒左右，也為了控制成本採用多層的樹狀結構，並做一定的邊緣聚合，在犧牲一定“最優接入“的情況下，做到了成本和延遲的平衡，同時也滿足了低延時直播超大頻道的需求做到了無限擴充套件的能力。因為大網路由節點和媒體邊緣節點原來的拓撲組織形態就是無向圖，所以天然能夠相容網狀和樹狀拓撲，而且可以複用所有的邊緣節點和路由節點，做到最佳的資源利用率，去平衡體驗和成本。
低成本
大家或多或少都能感受到 2022 年的網際網路多少有點“寒冬將至“的氛圍，所以大家對於成本越來越敏感，在我看來低成本主要有兩個維度：接入低成本和價格低成本。價格低成本很好理解，而接入成本降低可以節省人力成本，因此這兩個維度總結起來都和”錢“相關。對於雲服務提供商來說只有做到了低成本也才能讓我們的產品競爭力提高，讓使用者更愛用。
接入低成本
直播 CDN 的接入特別簡單，究其原因主要有兩方面：一個是直播使用的協議非常標準，比如 RTMP、HTTP with FLV 和 HLS 都是非常標準且通用的協議，各個 CDN 產商都支援；第二是有大量優秀的開源軟體在支援直播，比如大家熟知的 OBS、FFmpeg 和 IjkPlayer 等等。標準的協議和優秀的開源軟體，都大大降低了 CDN 接入的難度。因此我們認為低成本 RTC 也需要努力探索這兩個方向。
雲信目前在低延時直播場景進行相關方向的探索和落地，在這裡先簡單介紹一下雲信的低延時直播能力，在推流側支援第三個推流工具和雲信推流工具，將流用 RTMP 或者 WebRTC 協議推到邊緣加速伺服器，再根據配置如果是開通了低延時能力的就透過 WE-CAN 進行分發，否則就透過融合 CDN 分發。相比於 CDN 直播動輒 4s 以上的延遲，低延時直播延遲更低，最低可以達到 600ms，同時基於自研的 WE-CAN 全球智慧路由網路，可支援千萬級高併發拉流，並且首幀和抗弱網表現優勢明顯，讓使用者用接近 CDN 的價格體驗到 RTC 的效果。
說回接入低成本，從開源和標準協議的角度，雲信都做了探索，首先我們來看看雲信已經開源的基於 WebRTC 的開源低延時直播播放器，大家可以在 github 上搜尋 LLS-Player（https://github.com/GrowthEase...），找到這個專案。
上圖是雲信開源的低延時播放器的框架。雲信低延時播放器是一個傳輸層的 SDK，最底層是 WebRTC。因為我們旨在打造一個通用版的 SDK，所以我們將 WebRTC 全量包入，透過 PeerConnection 層接入，裡面是一些主要模組，例如 JitterBuffer、NetEQ、RTP/RTCP、Transport 等。中間是 RtdEngine 層，主要作用是對 WebRTC 進行封裝，包含 API、引擎建立、信令建連、 媒體資料的接收回撥等。最上層是 FFMPEG 外掛。直播已經發展了數些年，各廠商都有一些存量的播放器，市面上大多數播放器都是基於 FFMPEG 開發，為了降低使用者 SDK 接入門檻，雲信將 API 封裝成 FFMPEG 外掛，這樣只需要在原來的播放器裡面就可以實現低延時直播的拉流。
除了開源的低延時直播播放器，雲信還支援使用由 Millicast 開放的標準信令 WHIP 進行 SDP 協商後向雲信音影片服務推拉流。同時，未來雲信還有計劃開源包括低延時推流外掛在內的其它 RTC-CDN 產品。
價格低成本
這個章節是各個產商的核心，如何最佳化成本，我這裡提供幾個思路，供大家參考。
• 提高資源利用率——CPU 算力錯峰利用率，邊緣接入節點複用率，大網內部使用組播來提高頻寬複用率。
• 降低頻寬開銷——各業務頻寬錯峰（頻寬規劃），聚合排程，95 峰值成本排程，透過節點的賽馬機制去尋找更多優質的低成本邊緣節點。
低延時 RTC-CDN 場景化技術實戰
• 低延時直播線上教育大班課
大班課大多都是透過傳統的直播解決方案實現的，主要會面臨兩個問題：白板與直播畫面的同步以及答題系統與直播畫面的同步，傳統直播由於底層傳輸層協議的固有問題，所以是很難攻堅的；而 RTC 方案雖能解決上述問題，但其高昂的成本讓人“又愛又恨”。因此低成本的 RTC-CDN 架構在這個場景下就演化出了低延時直播的解決方案，去平衡效果（也就是清晰度、端到端延時、流暢度）與成本。上文已經分享了低延時直播就是利用了 RTC-CDN 的 QoS 機制、低延時樹狀分發網路以及低成本方案等，各類技術保障，就是讓使用者用 CDN 的價格體驗到了 RTC 的效果。
• 雲遊戲
與之類似的低延時直播場景還有“雲遊戲“，也是要將實時操作與畫面做到極致的同步，特別是在雲遊戲直播的場景下，低延時直播可以大大提高觀眾側的體驗，當然雲遊戲除了延時要求以外，還對影片的清晰度和幀率提出了很高的要求，需要在編碼策略和 QoS 機制上做更多的適配。
• 直播
除了“雲遊戲“以外，近兩年彈幕遊戲直播也作為一種新型的直播形態在不少平臺取得成功，彈幕遊戲直播天然是與低延時直播場景匹配的，因為所有觀眾發的彈幕都希望儘快在直播畫面上看到彈幕的結果，需要做到秒級延時的體驗。
• IoT 機器人
低延時 RTC-CDN 除了在教育、遊戲、娛樂社交等場景得到落地以外，雲信這兩年還將它應用在了遠端操控與 IoT 機器人的場景，所謂遠端操控其實就是利用低延時流媒體技術實現對裝置的遠距離操控。
雲信和網易伏羲機器人團隊的合作的遠端挖掘機就是其中一個落地實踐的方向，為了實現遠端開挖掘機，我們需要有一套超低延時的控制信令系統和超低延時的實時音影片系統，再配合雲端的 VR 渲染。這些超低延時的傳輸能力，不僅要考慮戶外網路較差訊號較差的情況，還要面臨超大流量的上行流量傳輸，因為同時傳輸很多個攝像頭的資料，很多傳統 RTC 的場景下的 QoS 機制還是需要針對性做較多的最佳化以適配這樣的場景。
• 元宇宙
除了挖掘機以外，雲信還在近兩年特別熱門的元宇宙場景進行通用傳輸能力的探索。元宇宙如今已成為全球科技業的下一個風口。在元宇宙琳琅滿目的各種應用場景中，無論是如電影《頭號玩家》中的那種體感互動裝置，還是醫生利用 VR 醫療，遠端做手術，元宇宙強互動的基礎是資料的低延遲傳輸和同步。
雲信與網易瑤臺合作研發的瑤臺是國內首批元宇宙落地產品，區別於傳統視訊會議的呈現方式，瑤臺更具虛擬的沉浸感。去年網易曾將全球投資者大會的舉辦地搬到了瑤臺虛擬世界，來自全球幾十個國家的 200 多位投資者，透過自己的虛擬形象，交流網易業務的最新動態。整個互動場景便是基於網易雲信的低延時 RTC-CDN 能力打造。
• MPS 雲端實時轉碼
除了通用傳輸技術，雲信也在探索通用的遠端媒體處理技術，使用雲信自研的 MPS 高效能媒體處理伺服器，雲信能夠在雲端實現虛擬人、轉碼、超分、場景渲染等能力，來滿足不同客戶和場景的實際需求，我們認為雲端的媒體處理構建，也是音影片在元宇宙時代的一個非常重要的組成部分。
總結和展望
總結
• 我們探討了全球分散式多單元流媒體伺服器架構，利用分層架構和統一排程來支援了海量併發以及流量蜂擁。
• 我們基於多單元流媒體伺服器架構，並深度打磨低延時技術，打造了 RTC-CDN 系統，針對 RTC-CDN 系統探索了低成本服務架構，同時擁抱了標準化和開源。
• 我們利用 RTC-CDN 最佳化了低延時直播、元宇宙的傳輸、雲渲染以及遠端機器人控制等場景。
• 這裡我們對 RTC-CDN 這個新詞做一個總結：什麼是 RTC-CDN 系統？就是在一套系統裡同時具備 RTC 和 CDN 的能力，並讓 RTC 的接入與使用如 CDN 一樣低成本。
展望
• 系統架構的融合和多樣性是未來，而全面的 RTC-CDN 時代，應該會在未來幾年內到來。
• 未來的音影片編解碼還是會不斷的迭代創新，比如 8K 的新一代影片編碼器 AVS3 和 VVC 和谷歌基於 AI 的音訊編碼器 SoundStream。
• 傳輸技術會繼續迭代，不僅是已經得到廣泛應用的 QUIC 和 HTTP3，5G 和 6G 這些底層通訊技術也會不斷演進，這些都會推進 RTC 技術不斷迭代。
• AI 與大資料探勘，會不斷在 RTC 領域中發揮重要作用。
技術是永無止境的，我堅信技術是可以改變世界，音影片領域未來有無限可能。