原創(chuàng)?夏天?聲網(wǎng)開發(fā)者?

本文為「Dev for Dev 專欄」系列內(nèi)容，作者為聲網(wǎng)大后端傳輸協(xié)議負(fù)責(zé)人?夏天。

?目錄?

?1.?AUT 自研經(jīng)驗(yàn)總結(jié)

? ? 1.1?傳輸控制中的算法設(shè)計(jì)與迭代思路?

? ??1.2?適配應(yīng)用才能將傳輸效果做到極致? ??

? ? 1.3?根據(jù)場景特點(diǎn)針對(duì)性使用傳輸策略? ??

? ? 1.4?做好協(xié)議的傳輸質(zhì)量保證體系? ??

? ? 1.5?技術(shù)演進(jìn)一定與落地應(yīng)用相結(jié)合?

2.?AUT 演進(jìn)的展望????

? ? 2.1?全球區(qū)域網(wǎng)絡(luò)數(shù)據(jù)收集和分析? ??

? ? 2.2?機(jī)器學(xué)習(xí)在 AUT 中的應(yīng)用? ??

? ? 2.3?多路徑傳輸?shù)某掷m(xù)演進(jìn)和落地? ??

? ? 2.4?多路徑傳輸?shù)某掷m(xù)演進(jìn)和落地

針對(duì)實(shí)時(shí)互動(dòng)應(yīng)用對(duì)網(wǎng)絡(luò)傳輸帶來的新需求和新挑戰(zhàn)，聲網(wǎng)通過將實(shí)時(shí)互動(dòng)中的應(yīng)用層業(yè)務(wù)需求與傳輸策略的分層和解耦，于 2019 年自研內(nèi)部私有的傳輸層協(xié)議 Agora Universal Transport（AUT），將異構(gòu)網(wǎng)絡(luò)下的各種傳輸控制能力匯聚起來，并于 2021 ~ 2022 年開始逐步大規(guī)模落地在各項(xiàng)業(yè)務(wù)中，用一套傳輸協(xié)議/框架解決各項(xiàng)業(yè)務(wù)不同的傳輸需求。

相關(guān)內(nèi)容分為上下兩篇，在上一篇內(nèi)容《聲網(wǎng)自研傳輸層協(xié)議 AUT 的落地實(shí)踐》中，我們介紹聲網(wǎng) AUT 傳輸協(xié)議的誕生和在實(shí)時(shí)互動(dòng)業(yè)務(wù)場景下的應(yīng)用。本篇從協(xié)議的演進(jìn)和落地過程中，抽象地總結(jié) AUT 的經(jīng)驗(yàn)，并對(duì) AUT 以及未來實(shí)時(shí)互動(dòng)網(wǎng)絡(luò)傳輸進(jìn)行展望。

AUT 的研發(fā)到大規(guī)模落地歷時(shí) 3 年，傳輸協(xié)議的設(shè)計(jì)與實(shí)現(xiàn)兼具工程與算法的雙重挑戰(zhàn)，同時(shí)作為一項(xiàng)底層且抽象出來的技術(shù)，在實(shí)時(shí)互動(dòng)的各場景落地的過程中又有著方方面面具體的問題，過程不可謂不艱辛。在此為我們的過往工作做些復(fù)盤和整理，拋磚引玉，為后續(xù)類似工作積累經(jīng)驗(yàn)。?

1、傳輸控制中的算法設(shè)計(jì)與迭代思路

由于實(shí)際網(wǎng)絡(luò)中的場景紛繁復(fù)雜，某個(gè)場景中的算法改動(dòng)可能會(huì)導(dǎo)致在其他場景中不適配的問題，同時(shí) AUT 由于服務(wù)于多個(gè)不同的業(yè)務(wù)，還需要避免業(yè)務(wù)之間產(chǎn)生影響。所以在 AUT 的算法設(shè)計(jì)中，我們的主要思路是對(duì)于新發(fā)現(xiàn)的問題先明確識(shí)別，在識(shí)別后再針對(duì)性的解決，以避免影響其他場景；通過可配置的方式、用灰度試驗(yàn)和數(shù)據(jù)驅(qū)動(dòng)分析實(shí)際結(jié)果來評(píng)估算法設(shè)計(jì)的優(yōu)劣。

在算法的設(shè)計(jì)中，由于 AUT 內(nèi)的弱網(wǎng)對(duì)抗模塊較多，各個(gè)模塊如果都獨(dú)立維護(hù)自己的狀態(tài)和邏輯，會(huì)產(chǎn)生很多的冗余代碼。一個(gè)典型場景是，某個(gè)模塊正在分析的數(shù)據(jù)也是其他很多模塊需要用到的，但觸發(fā)算法決策的時(shí)機(jī)卻千奇百怪各不相同。經(jīng)過對(duì)該問題的分析后，我們決定將算法模塊拆分為客觀的數(shù)據(jù)統(tǒng)計(jì)模塊和主觀的決策處理模塊，然后以事件驅(qū)動(dòng)來觸發(fā)各個(gè)不同的決策處理模塊進(jìn)行算法決策，這樣數(shù)據(jù)統(tǒng)計(jì)能做到最大程度復(fù)用，各算法的關(guān)注點(diǎn)也變得清晰明確。

2、適配應(yīng)用才能將傳輸效果做到極致

在沒有 AUT 之前，傳輸和應(yīng)用層的邏輯是緊密耦合的，緊密耦合雖然可移植性差，但是單從這一項(xiàng)業(yè)務(wù)的傳輸效果上來說卻能夠做到最好，因?yàn)楹芏鄻I(yè)務(wù)信息可以非常方便共享互通。從 AUT 開始實(shí)現(xiàn)之初，我們就在思考如何既能夠做到獨(dú)立出來傳輸層協(xié)議和框架，又能夠與各應(yīng)用層一起將傳輸效果做到最優(yōu)。最終，我們探索出來的思路是機(jī)制上深度耦合、工程上足夠抽象。

首先從業(yè)務(wù)出發(fā)，從結(jié)果上我們?nèi)匀灰獙?duì)一個(gè)傳輸機(jī)制的最優(yōu)處理方式保持不變，不能因?yàn)榉謱又缶秃雎砸恍┫闰?yàn)的知識(shí)和信息：例如視頻傳輸中一整個(gè)幀需要一起處理，假如幀中間少了一塊數(shù)據(jù)，就不能處理；那么在獨(dú)立出來傳輸層后，也不能丟失這個(gè)整塊信息，需要根據(jù)這個(gè)信息來決策如何傳輸塊中的每一個(gè)包。所以從傳輸機(jī)制上，仍然要盡可能多的利用應(yīng)用層提供的信息，以便把最終結(jié)果做到極致。

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

3、根據(jù)場景特點(diǎn)針對(duì)性使用傳輸策略

如何做到在 AUT 落地在公司的各項(xiàng)業(yè)務(wù)中使用一套框架應(yīng)對(duì)各個(gè)需求，是個(gè)很大的難題。在解決這個(gè)問題上，我們逐步探索出場景化傳輸?shù)乃悸罚菏紫让鞔_自身的各項(xiàng)能力，然后分析并提取出典型使用場景（網(wǎng)絡(luò)場景 + 業(yè)務(wù)需求）作為先驗(yàn)知識(shí)，再針對(duì)不同使用場景使用針對(duì)性能力完成傳輸需求。

例如典型的場景包括：

●?無線傳輸/有線傳輸；有線傳輸中的網(wǎng)絡(luò)波動(dòng)總體而言較少，那么我們可以簡化很多傳輸策略、以提高性能；無線傳輸中多由于信道的競爭而表現(xiàn)出網(wǎng)絡(luò)抖動(dòng)較大、變化較為頻繁，這時(shí)候需要根據(jù)具體的無線傳輸網(wǎng)絡(luò)做特定的適配，例如根據(jù)網(wǎng)絡(luò)抖動(dòng)動(dòng)態(tài)對(duì)發(fā)送策略進(jìn)行補(bǔ)償。

●?實(shí)時(shí)數(shù)據(jù)傳輸（RTC）/非實(shí)時(shí)數(shù)據(jù)傳輸（File/Report）；實(shí)時(shí)傳輸中更強(qiáng)調(diào)數(shù)據(jù)的時(shí)效性，對(duì)于錯(cuò)誤恢復(fù)要更激進(jìn)甚至提前避免；非實(shí)時(shí)傳輸則盡量避免過于激進(jìn)而對(duì)用戶的整體網(wǎng)絡(luò)使用情況產(chǎn)生較大影響。

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

●?長鏈接持續(xù)數(shù)據(jù)傳輸（Proxy）/短鏈接請求應(yīng)答式傳輸（LBS Request）；長鏈接傳輸可以開啟 MTU 探測、附帶發(fā)送部分額外信息、使用連接的前后上下文等以減少協(xié)議 overhead；而短鏈接請求應(yīng)答式傳輸則可以對(duì)應(yīng)用數(shù)據(jù)做更多額外傳輸保證，以避免數(shù)據(jù)丟失導(dǎo)致連接持續(xù)過長。

不同場景中對(duì)實(shí)時(shí)性/可靠性/弱網(wǎng)對(duì)抗能力的要求大不相同，我們的傳輸策略針對(duì)場景，而一個(gè)場景又能能夠映射到其他多個(gè)具有共性的業(yè)務(wù)中，那么針對(duì)這個(gè)場景的傳輸優(yōu)化就能夠做到復(fù)用，而不再是針對(duì)一個(gè)個(gè)具體的業(yè)務(wù)去做定向優(yōu)化。

4、做好協(xié)議的傳輸質(zhì)量保證體系

傳輸協(xié)議的演進(jìn)離不開自身的質(zhì)量保證體系，只有具備穩(wěn)定有效的質(zhì)量保證體系，才能讓協(xié)議的演進(jìn)持續(xù)保持高效，否則完成技術(shù)改進(jìn)也無法驗(yàn)證正確性，出現(xiàn)了問題也無從調(diào)查。

1.可視化內(nèi)部邏輯的影響

傳輸協(xié)議的問題調(diào)查有其特殊性：傳輸中的包可能會(huì)很多，而每個(gè)包的發(fā)送和接收都可能會(huì)影響內(nèi)部的狀態(tài)和邏輯，同時(shí)內(nèi)部模塊和算法模塊較多，邏輯鏈條可能會(huì)很長，跨模塊的狀態(tài)互相產(chǎn)生的影響光使用斷點(diǎn)很難追蹤長期的影響關(guān)系和結(jié)果。

這時(shí)一個(gè)比較好的辦法，就是提供可視化工具，通過通用模塊根據(jù) log dump 內(nèi)部信息，將內(nèi)部各種狀態(tài)做成可視化圖表，能夠極大方便對(duì)內(nèi)部各變量的相互影響關(guān)系進(jìn)行追蹤，很多問題能夠一目了然。

2.重現(xiàn)/自測各種網(wǎng)絡(luò)場景

傳輸?shù)木W(wǎng)絡(luò)狀態(tài)轉(zhuǎn)瞬即逝，對(duì)于各種網(wǎng)絡(luò)狀態(tài)的模擬和重現(xiàn)同樣十分重要，我們使用兩個(gè)層面的工具對(duì)網(wǎng)絡(luò)狀態(tài)進(jìn)行重現(xiàn)：

●?使用系統(tǒng)層面相關(guān)工具（TC等），對(duì)較為復(fù)雜弱網(wǎng)場景進(jìn)行模擬（具備復(fù)雜的弱網(wǎng)模擬能力，同時(shí)從時(shí)間/資源的開銷上也更大）；

●?使用內(nèi)部仿真模塊（simulator），從單元測試層面對(duì)較為明確的弱網(wǎng)場景進(jìn)行仿真（模擬能力較弱，但是開銷較低）；

這兩個(gè)層面的工具形成互補(bǔ)，從不同的維度對(duì)網(wǎng)絡(luò)狀態(tài)進(jìn)行重現(xiàn)，為 AUT 進(jìn)行內(nèi)部調(diào)試提供了可靠的依據(jù)。

3.保證代碼的健壯性

由于在公司內(nèi)廣泛應(yīng)用，同時(shí)暴露在公網(wǎng)上接收各種不可預(yù)知的輸入，代碼的健壯性同樣需要有效的保證。

●?使用 fuzz 測試自動(dòng)化模擬各種配置/接口/網(wǎng)絡(luò)包的正常或異常輸入，確保穩(wěn)定性。fuzz 測試對(duì)于傳輸協(xié)議而言是一個(gè)非常好的工具，機(jī)器的運(yùn)算力和對(duì)代碼路徑的判斷相比人為思考測試用例在覆蓋面上能夠做到更加全面；

●?極端場景覆蓋，通過長時(shí)間和極端異常網(wǎng)絡(luò)來進(jìn)行壓力測試。極端場景往往是最典型的 corner case，很多設(shè)計(jì)時(shí)漏掉的邊界場景，在極端場景測試中都能夠出現(xiàn)，所以永遠(yuǎn)不要放過。

5、技術(shù)演進(jìn)一定與落地應(yīng)用相結(jié)合

傳輸控制本身是一項(xiàng)非常底層的技術(shù)，可以說是很多上層應(yīng)用的基石，在底層技術(shù)的研發(fā)中，由于遇到的問題非常多，時(shí)常陷入的一個(gè)怪圈就是容易自己給自己找一些問題去思考并花很多時(shí)間解決，這其中有些問題是具有前瞻性和實(shí)際價(jià)值的，但也有很多可能是脫離實(shí)際或至少在當(dāng)前階段是脫離實(shí)際的。這導(dǎo)致的一個(gè)結(jié)果就是技術(shù)演技與實(shí)際落地完全脫鉤，技術(shù)演進(jìn)的很好，但是在具體業(yè)務(wù)上很難產(chǎn)生實(shí)際價(jià)值，甚至可能做了一個(gè)完全沒有業(yè)務(wù)需要的功能，費(fèi)時(shí)費(fèi)力卻不討好。

在 AUT 的演進(jìn)過程中我們就有過類似的經(jīng)歷，后續(xù)我們就非常注重其中每項(xiàng)技術(shù)在具體業(yè)務(wù)場景中產(chǎn)生的實(shí)際價(jià)值，確保做出來的東西一定要放在具體應(yīng)用場景中落地，這樣有實(shí)際的應(yīng)用場景，就會(huì)產(chǎn)生更實(shí)際的問題，這些問題的出現(xiàn)反過來又更好地幫助了技術(shù)的迭代，這樣既能產(chǎn)生實(shí)際價(jià)值、又進(jìn)行了技術(shù)演進(jìn)，避免了閉門造車。

AUT 在各個(gè)場景的落地絕非結(jié)束，而是一個(gè)新的開始，后續(xù)對(duì)于網(wǎng)絡(luò)和傳輸?shù)南嚓P(guān)工作仍有很多方向等待我們探索。

1、全球區(qū)域網(wǎng)絡(luò)數(shù)據(jù)收集和分析

在各項(xiàng)業(yè)務(wù)中獨(dú)立出傳輸層以后，使得我們獲取了更為純粹的各地用戶網(wǎng)絡(luò)數(shù)據(jù)，結(jié)果收取/分析/建模之后，網(wǎng)絡(luò)數(shù)據(jù)能夠?yàn)闃I(yè)務(wù)上提供很多支持，例如：

●?傳輸控制：使用用戶網(wǎng)絡(luò)數(shù)據(jù)來改善傳輸中的算法；

●?用戶分配：讓用戶接入到最合適的運(yùn)營商/邊緣中；

●?網(wǎng)絡(luò)診斷：根據(jù)當(dāng)?shù)?當(dāng)運(yùn)營商典型的網(wǎng)絡(luò)模型，分析用戶網(wǎng)絡(luò)問題；

●?實(shí)驗(yàn)仿真：構(gòu)建更貼近用戶真實(shí)網(wǎng)絡(luò)的弱網(wǎng)環(huán)境。

2、機(jī)器學(xué)習(xí)在 AUT 中的應(yīng)用

近年來機(jī)器學(xué)習(xí)在實(shí)時(shí)音視頻傳輸中的應(yīng)用也是層出不窮──多在擁塞控制算法中有些嘗試。下圖是我們內(nèi)部的機(jī)器學(xué)習(xí)算法的實(shí)驗(yàn)結(jié)果，可以看到相比于 Paper 中的實(shí)驗(yàn)結(jié)果，我們內(nèi)部的算法的帶寬估計(jì)結(jié)果更加逼近 Optimal：

機(jī)器學(xué)習(xí)的算法非常依賴數(shù)據(jù)集，在完成更充分的數(shù)據(jù)收集工作后，我們相信機(jī)器學(xué)習(xí)在網(wǎng)路傳輸中會(huì)發(fā)揮出更大的價(jià)值。

3、多路徑傳輸?shù)某掷m(xù)演進(jìn)和落地

多路徑傳輸是未來的大勢所趨，AUT 內(nèi)部也同步在做相應(yīng)的支持，目前正處在逐步落地的階段。下圖是一個(gè)我們目前在實(shí)驗(yàn)室測試：multipath 版本使用 Wi-Fi 和移動(dòng)數(shù)據(jù)兩個(gè)出口進(jìn)行傳輸，singlepath 版本僅使用 Wi-Fi，我們僅在 Wi-Fi 鏈路下添加弱網(wǎng)。

結(jié)果顯示，multipath 版本的視頻延遲基本不受影響，而 singlepath 版本的延遲則隨著弱網(wǎng)條件跌宕起伏。

4、泛化弱網(wǎng)對(duì)抗模塊到公有協(xié)議

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

例如我們現(xiàn)在已經(jīng)在 WebRTC 服務(wù)中使用了 AUT 內(nèi)的擁塞控制模塊，以改進(jìn)原生擁塞控制的很多問題；同時(shí) QUIC 在標(biāo)準(zhǔn)化后應(yīng)用場景也越來越廣泛，AUT 內(nèi)的弱網(wǎng)對(duì)抗模塊后續(xù)也會(huì)逐步遷移到公司內(nèi)部的 QUIC 協(xié)議棧中，以增強(qiáng) QUIC 的網(wǎng)絡(luò)分析及弱網(wǎng)對(duì)抗能力。

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