本文為「Dev for Dev 專欄」系列內容,作者為聲網大後端傳輸協議負責人 夏天。
針對實時互動應用對網路傳輸帶來的新需求和新挑戰,聲網通過將實時互動中的應用層業務需求與傳輸策略的分層和解耦,於 2019 年自研內部私有的傳輸層協議 Agora Universal Transport(AUT),將異構網路下的各種傳輸控制能力匯聚起來,並於 2021 ~ 2022 年開始逐步大規模落地在各項業務中,用一套傳輸協議/框架解決各項業務不同的傳輸需求。
相關內容分為上下兩篇,本文將詳細介紹 AUT 傳輸協議的設計和演進過程。
01 紛繁複雜的傳輸場景
作為一家提供實時互動平臺的公司,傳輸毫無疑問是所有互動的基石,隨著網路的發展,互動的場景也越來越多樣,傳輸的內容也越來越複雜,實時互動下的傳輸主要面臨以下需求和挑戰:
媒體資料傳輸
RTC 聲網最主要的實時互動場景,實時音視訊的傳輸也是和上層業務邏輯耦合最為緊密的傳輸場景,傳輸邏輯需要與媒體層面的信源編碼緊密配合完成低延遲的互動。
● 需要有一個可靠的網路通道,來實現控制訊息的收發。
● 需要有多個可靠的實時通道,來滿足多路資料流(音視訊等)的收發。
● 在頻寬受限時,需要解決上述流的優先順序管理問題(控制通道>音訊>視訊)。
● To B 場景下,要能讓客戶自主靈活地決定流的優先順序和傳輸降級策略。
● 媒體中的相關策略,需要與當前的網路狀況緊密配合。
● 在網內傳輸時,不同地區間和運營商間互通的網路質量迥異,各種網路 buffer、延遲及丟包相差巨大。
通用資料傳輸
聲網推出的 FPA 全鏈路加速產品在全球範圍為各類應用(包括 Web/遊戲/音視訊等)提供端到端的鏈路加速服務。
● 同時支援端到端的可靠傳輸通道和不可靠傳輸通道。
● 作為通用資料加速通道,資料流量變化範圍較大。
● 低延遲。
低延遲可靠訊息傳輸
RTM 是聲網對外提供的穩定可靠、超低延時、高併發的全球信令與訊息雲服務。
● 訊息體積小,訊息頻率較高,整體流量相對較低。
● 低延遲。
低優先順序可靠資料傳輸
Report 是聲網內部的埋點和事件資料上報,對內和對外提供問題排查的資訊。
● 傳輸優先順序和實時性要求低,要避免對其他業務資料產生影響。
● 與後端保持長連線,連線數量巨大,但絕大部分時間空閒。
各項業務網內傳輸
SD-RTN™是聲網內部的全球覆蓋網路,覆蓋200多個國家和地區,承載著不同業務的流量。
● 跨區傳輸中長肥鏈路(亦即長肥網路,頻寬延遲積大、丟包率高)的傳輸,大鏈路延遲下的頻寬爬升/丟包要迅速恢復。
● 不同國家/運營商之間的網路質量難以保證,丟包/抖動十分常見。
● 不同業務/客戶/場景的不同程度 QoS 保證。
02 解決之道--自研傳輸層協議
現有方案的不足
傳輸需求各有不同,我們首先 review 業界的各項產品,以求獲得成熟的解決方案,但儘管調研發現均存在各種不滿足的地方:
方案 | 優點 | 侷限 |
---|---|---|
RTP/RTCP | 可以定製化傳輸策略 | 無優先順序管理;缺少多路複用能力; |
TCP/RTMP | 通用性好 | 容易隊頭阻塞且無法多路複用;不能定製化傳輸策略,優化方案較少; |
SRT | 有部分弱網對抗機制 | 缺少獨立的擁塞控制;缺少多路複用能力; |
QUIC | 具備多路複用、優先順序管理和防排頭阻塞 | 缺少對實時非可靠資料流的傳輸支援;缺少各種弱網對抗和網路適配能力;協議大而全,但相對於內部使用太重; |
我們從業務需求整理發現,各業務之間的傳輸存在共性的同時也存在差異性,單獨為一個業務的傳輸尋求已有的解決方案尚可滿足,但是使用一種傳輸框架兼顧所有的業務場景絕非易事,這需求對各業務需求的深入理解和抽象提煉,業界的各項產品難也實現。
最終,自研傳輸層協議/框架成為了最輕便、適配性最強,但也是最具有挑戰的解決方案。
AUT 的設計目標
我們根據已有業務的傳輸需求和特性,梳理並總結了自研傳輸協議需要實現的幾個目標,如下:
1、提供多路複用的傳輸通道以同時承載不同的資料型別,並對不同型別資料提供有效的描述方案。
2、提供足夠的可擴充套件性,能夠適配各種應用層的傳輸相關的邏輯和輸入,例如整塊資料/分塊資料/零散資料等,實時傳輸往往和應用結合揭祕,對於底層傳輸控制的粒度也會要求更細。
3、對不同資料提供不同級別的傳輸質量保證,例如不同的優先順序/可靠性/冗餘力度。
4、靈活的傳輸控制模組介面,可擴充套件實現不同擁塞控制、丟包檢測、網路檢測等策略。
5、底層網路介面化,能夠支援任何虛擬網路。
6、對上層提供有效的網路質量分析,方便上層針對不同網路質量應用不同業務邏輯。
7、適配不同的網路場景,適應異構網路下的亂序/抖動/長肥/限流等網路狀況。
03 AUT 的演進過程
架構演進過程
● 最開始的原型驗證階段,我們使用最簡模型完成傳輸層的抽象,並僅針對音視訊媒體中的不可靠傳輸場景下應用。
● 在完成原型驗證後,AUT 演進成為 Session 和 Connection 的分層設計:Session 主要負責 Stream 的管理,不同的 Stream 完成不同的業務需求,Connection 負責業務無關的純粹傳輸控制,以此完成傳輸控制和業務需求的解耦;獨立抽象出網路收發相關的介面,使得 AUT 可以 Overlay 在各種網路上;引入加密/認證等安全特性;引入 MTU 探測、Padding 等網路狀態探測能力。
● 完成分層設計後,AUT 的分層進一步細化:在 Stream 中逐步演進出更細粒度的通用模組和專用模組,通過抽象實現 Writer/Reader 、組合流控制器和快取等完成不同的通道編解碼、流控和重傳控制等操作,使得每條流的弱網對抗能力具備差異化以適配不同的業務資料;Connection 統籌管理多個 Path,每個 Path 作為獨立的傳輸控制單元互不影響,從能夠同時支援多調 Path 同時傳輸;在傳輸演算法上,引入了流量模型檢測、丟包型別檢測等更深入的網路狀態檢測模組。
弱網對抗能力
伴隨 AUT 的演進,我們對網路的分析評估的維度也逐步豐富,這些網路分析能力是 AUT 弱網對抗能力的基礎:
● 亂序檢測能力:檢測網路中的亂序程度,並在亂序條件下對傳輸演算法做對應的調整,例如調整丟包檢測演算法和擁塞控制演算法以適配亂序場景;
● 頻寬探測能力:具備多種不同維度的頻寬探測演算法,在不同的探測需求下進行優勢互補:packet train 探測頻寬上限,以極小的流量模糊探測較高的傳輸頻寬;padding 探測實際頻寬,在應用資料不足時,將實際流量填充到網路中,真實地驗證網路的實際容量;
● 流量模型檢測能力:對實際網路流量的模型進行檢測,例如公網中典型的 traffic policing/shaping 等流量限制策略,並針對性的調整傳送控制策略;
● 丟包型別檢測能力:對真實丟包的模式進行分析,輸入當前的丟包模型,例如隨機丟包和擁塞丟包等,並根據丟包型別在其他模組中進行動態補償。
在明確網路的當前狀態後,AUT 內部的各種弱網對抗能力才能“對症下藥”:
● Stream 級別的通用通道編碼能力:Stream 內部實現了通用的分組編解碼框架,針對 FEC 中的分組碼能夠非常容易整合,使得不同的 Stream 在重傳、流控等差別之外,還具備不同編碼力度的保護,對外提供的傳輸伸縮性更廣泛;
● 動態反饋控制能力:AUT 的反饋主要是 Ack 包,有效的 Ack 反饋為內部演算法邏輯的準確性提供保證:動態啟用 AckAck 對抗 Ack 丟包;不同 Ack Delay 適配效能/延遲;Ack 鏈路抖動/突發檢測,補償傳送控制;
● 深度優化的擁塞控制/丟包檢測演算法:內部對典型的擁塞控制/丟包檢測演算法在各種場景下進行深度優化和探索,在保持演算法本身特性的同時,適配實時傳輸中各種傳輸控制的需求。
傳輸效果對比
作為傳輸層協議,我們同樣於其他傳輸層協議對於部分真實業務場景進行了效果的對比,一些結果如下:
可以看到無論在高低頻寬限制(100Mbps 和 4Mbps)、0-50% 的單獨上行和同時上下行的隨機丟包、20ms 和 200ms 的 RTT 場景下,AUT 相比 lsquic 能夠做到更接近實際頻寬的吞吐量。
落地場景綜述
截至目前,AUT 逐步落地在了聲網以下的業務場景:
RTC
AUT 在聲網 RTC 業務中的整體所在位置如下圖所示,可以看到,在使用者接入聲網邊緣節點的 Lastmile,和聲網邊緣節點之間基於 SD-RTNTM 的網內傳輸,都使用 AUT 作為 4 層傳輸協議。
Lastmile 使用 AUT 協議,讓我們整體重構了媒體和傳輸的協作關係,實現了更快的網路狀態跟蹤(位元速率爬升從 20+ 秒提升到 3 秒左右)、更好的音訊優先體驗(無卡頓),並有效降低了卡頓和時延、對硬體編碼的支援更好從而大幅提升了弱網的使用者體驗。
在不同網路條件下,使用 AUT 後視訊的部分指標如下:
FPA
FPA 中 AUT 的所在位置和 RTC 類似,FPA 內的傳輸資料不再侷限於音視訊,但由於複用 AUT,各種場景下的傳輸能力也得到了大幅提升,我們在不同地區測試 FPA 與公網的傳輸速率,相關資料如下:
RTM
在接入 RTM 的邊緣節點中,RTM 使用 AUT 替換 TCP,使用 AUT 接入 RTM 在各種弱網下的到達率和時延大幅度領先於 TCP 接入。通過傳送1000個訊息資料並記錄其到達時間,對比測試 AUT 和由 TCP 代表的公共網際網路傳輸協議在三種情況下的測試效果顯示,使用 AUT 相比 TCP 在限速 100Kbps 條件下平均訊息到達延遲下降 53%,丟包 20% 的條件下平均訊息到達延遲下降 67%,限速+丟包條件下平均訊息到達延遲下降 55%。
Report
我們在連線 Report 和 RTC 邊緣同時使用 AUT,並在 Report 的 AUT 連線中使用 LEDBAT 演算法,假如此時各連線存在共享的瓶頸頻寬時,Report 連線能夠以極地競爭性參與傳輸,保證對其他業務資料產生最小的影響。
SD-RTN™
在聲網 SD-RTN™ 網內使用 AUT 協議,使得網內傳輸具備提供不同 QOS 的能力,進一步提高了業務資料的傳輸效率,在長肥網路下使用 FEC 減少重傳次數,進一步降低弱網下的網內延遲,對公網的中的 Traffic Policing/Traffic Shaping 能明確檢測並適配,避免超發導致的丟包,網路質量評估更明確、實現了更好的網內路徑規劃,Metadata 機制極大簡化了業務的控制面邏輯。
針對 RTC 網內傳輸結果,我們抽取了 40 個機房進行對比,結果如下:
方案 | AUT使用前 | AUT使用後 |
---|---|---|
到達率不達標時間 | 00.00709% | 00.00489% |
抖動率不達標時間 | 00.00577% | 00.00564% |
由於之前的 RTC 網內傳輸質量已經十分優秀,在到達率和抖動相關指標都已經做到 4 個 9 的達標前提下,引入 AUT 後進一步降低不達標時間,使得 SD-RTN™ 的質量向專線進一步看齊。
關於 Dev for Dev
Dev for Dev 專欄全稱為 Developer for Developer,該專欄是聲網與 RTC 開發者社群共同發起的開發者互動創新實踐活動。
透過工程師視角的技術分享、交流碰撞、專案共建等多種形式,匯聚開發者的力量,挖掘和傳遞最具價值的技術內容和專案,全面釋放技術的創造力。