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

針對(duì)實(shí)時(shí)互動(dòng)應(yīng)用對(duì)網(wǎng)絡(luò)傳輸帶來(lái)的新需求和新挑戰(zhàn)，聲網(wǎng)通過(guò)將實(shí)時(shí)互動(dòng)中的應(yīng)用層業(yè)務(wù)需求與傳輸策略的分層和解耦，于 2019 年自研內(nèi)部私有的傳輸層協(xié)議 Agora Universal Transport（AUT），將異構(gòu)網(wǎng)絡(luò)下的各種傳輸控制能力匯聚起來(lái)，并于 2021 ~ 2022 年開(kāi)始逐步大規(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ù)場(chǎng)景下的應(yīng)用。本篇從協(xié)議的演進(jìn)和落地過(guò)程中，抽象地總結(jié) AUT 的經(jīng)驗(yàn)，并對(duì) AUT 以及未來(lái)實(shí)時(shí)互動(dòng)網(wǎng)絡(luò)傳輸進(jìn)行展望。

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

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

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

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

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

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

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

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

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

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

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

例如典型的場(chǎng)景包括：

● 無(wú)線傳輸/有線傳輸；有線傳輸中的網(wǎng)絡(luò)波動(dòng)總體而言較少，那么我們可以簡(jiǎn)化很多傳輸策略、以提高性能；無(wú)線傳輸中多由于信道的競(jìng)爭(zhēng)而表現(xiàn)出網(wǎng)絡(luò)抖動(dòng)較大、變化較為頻繁，這時(shí)候需要根據(jù)具體的無(wú)線傳輸網(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í)傳輸則盡量避免過(guò)于激進(jìn)而對(duì)用戶的整體網(wǎng)絡(luò)使用情況產(chǎn)生較大影響。

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

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

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

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

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

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

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

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

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

傳輸?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)場(chǎng)景進(jìn)行模擬（具備復(fù)雜的弱網(wǎng)模擬能力，同時(shí)從時(shí)間/資源的開(kāi)銷(xiāo)上也更大）；

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

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

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

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

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

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

02 AUT 演進(jìn)的展望

AUT 在各個(gè)場(chǎng)景的落地絕非結(jié)束，而是一個(gè)新的開(kāi)始，后續(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ù)來(lái)改善傳輸中的算法；

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

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

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

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

近年來(lái)機(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)和落地

多路徑傳輸是未來(lái)的大勢(shì)所趨，AUT 內(nèi)部也同步在做相應(yīng)的支持，目前正處在逐步落地的階段。下圖是一個(gè)我們目前在實(shí)驗(yàn)室測(cè)試：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ì)抗模塊從一開(kāi)始就考慮到了通用性，做到足夠模塊化，輸入也與協(xié)議本身完全無(wú)關(guān)，使得這些弱網(wǎng)模塊可以非常容易地移殖到其他協(xié)議。

例如我們現(xiàn)在已經(jīng)在 WebRTC 服務(wù)中使用了 AUT 內(nèi)的擁塞控制模塊，以改進(jìn)原生擁塞控制的很多問(wèn)題；同時(shí) QUIC 在標(biāo)準(zhǔn)化后應(yīng)用場(chǎng)景也越來(lái)越廣泛，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ù)中來(lái)、到應(yīng)用中去的過(guò)程。作為一個(gè)底層的協(xié)議，AUT 從聲網(wǎng)繁雜的業(yè)務(wù)場(chǎng)景中抽象出了共性的網(wǎng)絡(luò)傳輸需求，同時(shí)在工程層面，讓底層算法與上層應(yīng)用的耦合邏輯更具普適性；在模塊化的設(shè)計(jì)理念下，AUT 也更容易整合到廣泛使用的公有協(xié)議中，這也為 AUT 未來(lái)的發(fā)展打開(kāi)了想象之門(mén)。

關(guān)于 Dev for Dev

Dev for Dev 專欄全稱為 Developer for Developer，該專欄是聲網(wǎng)與 RTC 開(kāi)發(fā)者社區(qū)共同發(fā)起的開(kāi)發(fā)者互動(dòng)創(chuàng)新實(shí)踐活動(dòng)。

透過(guò)工程師視角的技術(shù)分享、交流碰撞、項(xiàng)目共建等多種形式，匯聚開(kāi)發(fā)者的力量，挖掘和傳遞最具價(jià)值的技術(shù)內(nèi)容和項(xiàng)目，全面釋放技術(shù)的創(chuàng)造力。

總結(jié)

以上是生活随笔為你收集整理的声网传输层协议 AUT 的总结与展望丨Dev for Dev 专栏的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。