聲網傳輸層協議 AUT 的總結與展望

本文爲_**「Dev for Dev 專欄」**__系列內容，作者爲聲網大後端傳輸協議負責人 夏天。_

** 目錄**

上下滾動查看

 1. AUT 自研經驗總結

    1.1 傳輸控制中的算法設計與迭代思路

    1.2 適配應用才能將傳輸效果做到極致

    1.3 根據場景特點針對性使用傳輸策略

    1.4 做好協議的傳輸質量保證體系

    1.5 技術演進一定與落地應用相結合

 2. AUT 演進的展望

    2.1 全球區域網絡數據收集和分析

    2.2 機器學習在 AUT 中的應用

    2.3 多路徑傳輸的持續演進和落地

    2.4 多路徑傳輸的持續演進和落地

針對實時互動應用對網絡傳輸帶來的新需求和新挑戰，聲網通過將實時互動中的應用層業務需求與傳輸策略的分層和解耦，於 2019 年自研內部私有的傳輸層協議 Agora Universal Transport（AUT），將異構網絡下的各種傳輸控制能力匯聚起來，並於 2021 ~ 2022 年開始逐步大規模落地在各項業務中，用一套傳輸協議 / 框架解決各項業務不同的傳輸需求。

相關內容分爲上下兩篇，在上一篇內容《聲網自研傳輸層協議 AUT 的落地實踐》中，我們介紹聲網 AUT 傳輸協議的誕生和在實時互動業務場景下的應用。本篇從協議的演進和落地過程中，抽象地總結 AUT 的經驗，並對 AUT 以及未來實時互動網絡傳輸進行展望。

AUT 的研發到大規模落地歷時 3 年，傳輸協議的設計與實現兼具工程與算法的雙重挑戰，同時作爲一項底層且抽象出來的技術，在實時互動的各場景落地的過程中又有着方方面面具體的問題，過程不可謂不艱辛。在此爲我們的過往工作做些覆盤和整理，拋磚引玉，爲後續類似工作積累經驗。 

1、傳輸控制中的算法設計與迭代思路

由於實際網絡中的場景紛繁複雜，某個場景中的算法改動可能會導致在其他場景中不適配的問題，同時 AUT 由於服務於多個不同的業務，還需要避免業務之間產生影響。所以在 AUT 的算法設計中，我們的主要思路是對於新發現的問題先明確識別，在識別後再針對性的解決，以避免影響其他場景；通過可配置的方式、用灰度試驗和數據驅動分析實際結果來評估算法設計的優劣。

在算法的設計中，由於 AUT 內的弱網對抗模塊較多，各個模塊如果都獨立維護自己的狀態和邏輯，會產生很多的冗餘代碼。一個典型場景是，某個模塊正在分析的數據也是其他很多模塊需要用到的，但觸發算法決策的時機卻千奇百怪各不相同。經過對該問題的分析後，我們決定將算法模塊拆分爲客觀的數據統計模塊和主觀的**決策處理模塊，**然後以事件驅動來觸發各個不同的決策處理模塊進行算法決策，這樣數據統計能做到最大程度複用，各算法的關注點也變得清晰明確。

2、適配應用才能將傳輸效果做到極致

在沒有 AUT 之前，傳輸和應用層的邏輯是緊密耦合的，緊密耦合雖然可移植性差，但是單從這一項業務的傳輸效果上來說卻能夠做到最好，因爲很多業務信息可以非常方便共享互通。從 AUT 開始實現之初，我們就在思考如何既能夠做到獨立出來傳輸層協議和框架，又能夠與各應用層一起將傳輸效果做到最優。最終，我們探索出來的思路是機制上深度耦合、工程上足夠抽象。

首先從業務出發，從結果上我們仍然要對一個傳輸機制的最優處理方式保持不變，不能因爲分層之後就忽略一些先驗的知識和信息：例如視頻傳輸中一整個幀需要一起處理，假如幀中間少了一塊數據，就不能處理；那麼在獨立出來傳輸層後，也不能丟失這個整塊信息，需要根據這個信息來決策如何傳輸塊中的每一個包。所以從傳輸機制上，仍然要儘可能多的利用應用層提供的信息，以便把最終結果做到極致。

與此同時，工程上獨立出來的傳輸層，不應該去理解視頻中的幀是什麼，這時候就需要抽象的去理解：對應用層是視頻的幀，而對於傳輸層就是一個整塊數據。傳輸層完成的事情就是如何將一整塊數據的傳輸做到最優，那麼由此對於 “塊數據” 的傳輸策略就獨立了出來──它可以被用在很多場景中，視頻只是其中一個，其他例如傳輸加密的證書、圖片、大段的信息，我們都可以使用同樣的策略，這便是工程實現中抽象理解帶來的好處。

3、根據場景特點針對性使用傳輸策略

如何做到在 AUT 落地在公司的各項業務中使用一套框架應對各個需求，是個很大的難題。在解決這個問題上，我們逐步探索出場景化傳輸的思路：首先明確自身的各項能力，然後分析並提取出典型使用場景（網絡場景 + 業務需求）作爲先驗知識，再針對不同使用場景使用針對性能力完成傳輸需求。

例如典型的場景包括：

● 無線傳輸 / 有線傳輸；有線傳輸中的網絡波動總體而言較少，那麼我們可以簡化很多傳輸策略、以提高性能；無線傳輸中多由於信道的競爭而表現出網絡抖動較大、變化較爲頻繁，這時候需要根據具體的無線傳輸網絡做特定的適配，例如根據網絡抖動動態對發送策略進行補償。

● 實時數據傳輸（RTC）/ 非實時數據傳輸（File/Report）；實時傳輸中更強調數據的時效性，對於錯誤恢復要更激進甚至提前避免；非實時傳輸則儘量避免過於激進而對用戶的整體網絡使用情況產生較大影響。

● 單連接大流量傳輸（FPA）/ 多連接稀疏流量傳輸（S2S）；單連接大流量傳輸可以做更多的聚合處理工作，而多鏈接稀疏流量則應避免連接空閒狀態帶來的開銷。

● 長鏈接持續數據傳輸（Proxy）/ 短鏈接請求應答式傳輸（LBS Request）；長鏈接傳輸可以開啓 MTU 探測、附帶發送部分額外信息、使用連接的前後上下文等以減少協議 overhead；而短鏈接請求應答式傳輸則可以對應用數據做更多額外傳輸保證，以避免數據丟失導致連接持續過長。

不同場景中對實時性 / 可靠性 / 弱網對抗能力的要求大不相同，我們的傳輸策略針對場景，而一個場景又能能夠映射到其他多個具有共性的業務中，那麼針對這個場景的傳輸優化就能夠做到複用，而不再是針對一個個具體的業務去做定向優化。

4、做好協議的傳輸質量保證體系

傳輸協議的演進離不開自身的質量保證體系，只有具備穩定有效的質量保證體系，才能讓協議的演進持續保持高效，否則完成技術改進也無法驗證正確性，出現了問題也無從調查。

1. 可視化內部邏輯的影響

傳輸協議的問題調查有其特殊性：傳輸中的包可能會很多，而每個包的發送和接收都可能會影響內部的狀態和邏輯，同時內部模塊和算法模塊較多，邏輯鏈條可能會很長，跨模塊的狀態互相產生的影響光使用斷點很難追蹤長期的影響關係和結果。

這時一個比較好的辦法，就是提供**可視化工具，**通過通用模塊根據 log dump 內部信息，將內部各種狀態做成可視化圖表，能夠極大方便對內部各變量的相互影響關係進行追蹤，很多問題能夠一目瞭然。

2. 重現 / 自測各種網絡場景

傳輸的網絡狀態轉瞬即逝，對於各種網絡狀態的模擬和重現同樣十分重要，我們使用兩個層面的工具對網絡狀態進行重現：

● 使用系統層面相關工具（TC 等），對較爲複雜弱網場景進行模擬（具備複雜的弱網模擬能力，同時從時間 / 資源的開銷上也更大）；

● 使用內部仿真模塊（simulator），從單元測試層面對較爲明確的弱網場景進行仿真（模擬能力較弱，但是開銷較低）；

這兩個層面的工具形成互補，從不同的維度對網絡狀態進行重現，爲 AUT 進行內部調試提供了可靠的依據。

3. 保證代碼的健壯性

由於在公司內廣泛應用，同時暴露在公網上接收各種不可預知的輸入，代碼的健壯性同樣需要有效的保證。

● 使用 fuzz 測試自動化模擬各種配置 / 接口 / 網絡包的正常或異常輸入，確保穩定性。fuzz 測試對於傳輸協議而言是一個非常好的工具，機器的運算力和對代碼路徑的判斷相比人爲思考測試用例在覆蓋面上能夠做到更加全面；

● 極端場景覆蓋，通過長時間和極端異常網絡來進行壓力測試。極端場景往往是最典型的 corner case，很多設計時漏掉的邊界場景，在極端場景測試中都能夠出現，所以永遠不要放過。

5、技術演進一定與落地應用相結合

傳輸控制本身是一項非常底層的技術，可以說是很多上層應用的基石，在底層技術的研發中，由於遇到的問題非常多，時常陷入的一個怪圈就是容易自己給自己找一些問題去思考並花很多時間解決，這其中有些問題是具有前瞻性和實際價值的，但也有很多可能是脫離實際或至少在當前階段是脫離實際的。這導致的一個結果就是技術演技與實際落地完全脫鉤，技術演進的很好，但是在具體業務上很難產生實際價值，甚至可能做了一個完全沒有業務需要的功能，費時費力卻不討好。

在 AUT 的演進過程中我們就有過類似的經歷，後續我們就非常注重其中每項技術在具體業務場景中產生的實際價值，確保做出來的東西一定要放在具體應用場景中落地，這樣有實際的應用場景，就會產生更實際的問題，這些問題的出現反過來又更好地幫助了技術的迭代，這樣既能產生實際價值、又進行了技術演進，避免了閉門造車。

AUT 在各個場景的落地絕非結束，而是一個新的開始，後續對於網絡和傳輸的相關工作仍有很多方向等待我們探索。

1、全球區域網絡數據收集和分析

在各項業務中獨立出傳輸層以後，使得我們獲取了更爲純粹的各地用戶網絡數據，結果收取 / 分析 / 建模之後，網絡數據能夠爲業務上提供很多支持，例如：

● 傳輸控制：使用用戶網絡數據來改善傳輸中的算法；

● 用戶分配：讓用戶接入到最合適的運營商 / 邊緣中；

● 網絡診斷：根據當地 / 當運營商典型的網絡模型，分析用戶網絡問題；

● 實驗仿真：構建更貼近用戶真實網絡的弱網環境。

2、機器學習在 AUT 中的應用

近年來機器學習在實時音視頻傳輸中的應用也是層出不窮──多在擁塞控制算法中有些嘗試。下圖是我們內部的機器學習算法的實驗結果，可以看到相比於 Paper 中的實驗結果，我們內部的算法的帶寬估計結果更加逼近 Optimal：

機器學習的算法非常依賴數據集，在完成更充分的數據收集工作後，我們相信機器學習在網路傳輸中會發揮出更大的價值。

3、多路徑傳輸的持續演進和落地

多路徑傳輸是未來的大勢所趨，AUT 內部也同步在做相應的支持，目前正處在逐步落地的階段。下圖是一個我們目前在實驗室測試：multipath 版本使用 Wi-Fi 和移動數據兩個出口進行傳輸，singlepath 版本僅使用 Wi-Fi，我們僅在 Wi-Fi 鏈路下添加弱網。

結果顯示，multipath 版本的視頻延遲基本不受影響，而 singlepath 版本的延遲則隨着弱網條件跌宕起伏。

4、泛化弱網對抗模塊到公有協議

AUT 中的各個弱網對抗模塊從一開始就考慮到了通用性，做到足夠模塊化，輸入也與協議本身完全無關，使得這些弱網模塊可以非常容易地移殖到其他協議。

例如我們現在已經在 WebRTC 服務中使用了 AUT 內的擁塞控制模塊，以改進原生擁塞控制的很多問題；同時 QUIC 在標準化後應用場景也越來越廣泛，AUT 內的弱網對抗模塊後續也會逐步遷移到公司內部的 QUIC 協議棧中，以增強 QUIC 的網絡分析及弱網對抗能力。

綜上所述，AUT 的誕生和迭代是一個從業務中來、到應用中去的過程。作爲一個底層的協議，AUT 從聲網繁雜的業務場景中抽象出了共性的網絡傳輸需求，同時在工程層面，讓底層算法與上層應用的耦合邏輯更具普適性；在模塊化的設計理念下，AUT 也更容易整合到廣泛使用的公有協議中，這也爲 AUT 未來的發展打開了想象之門。

關於 Dev for Dev

Dev for Dev 專欄全稱爲 Developer for Developer，該專欄是聲網與 RTC 開發者社區共同發起的開發者互動創新實踐活動。

透過工程師視角的技術分享、交流碰撞、項目共建等多種形式，匯聚開發者的力量，挖掘和傳遞最具價值的技術內容和項目，全面釋放技術的創造力。

聲網開發者 與開發者分享實時互動領域的開發實踐、算法研究與前沿技術。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/3O5PnD48BX6roITbiJvpGQ