引言
從網際網路誕生開始，網路吞吐量的限制、資料分組的丟失、資料傳輸的延遲和延遲抖動等人為或意外的狀況就緊緊的伴隨著網際網路的發展。而當今的網際網路更是一個擁擠、繁忙和複雜的龐大系統，不同的網路服務和應用以競爭的方式共享相同的網路基礎設施收發流量。對於那些傳統應用場景，比如 Web 瀏覽、檔案傳輸或音視訊點播等服務，因為這些場景下使用者對於延遲的容忍均在秒級甚至更大，而對網路抖動甚至無感知，所以使用傳統的基於 cubic 或 reno 的 TCP 協議就能夠較好的完成任務，這些擁塞控制演算法傾向於塞滿網路直到丟包發生然後極速退避，這就導致網路的擁堵程度總是處在劇烈的變化之中。
而以實時音視訊傳輸需求為代表的實時網路場景更關注的是在可接受的音視訊質量下更低的延遲，這就要求擁塞控制演算法不能總將網路塞滿而是要調整編碼策略、傳送在較低延時下可獲得更佳主觀體驗所需位元速率的實時音視訊資料，對於這點傳統的 TCP 無法滿足需求，雖然有基於 BBR 的 TCP 擁塞控制演算法，但如果需要定製場景並與媒體層聯動的時候就面臨修改協議棧程式碼的問題，這對於新功能的釋出和版本的快速迭代並不友好，因此目前在實時網路行業深耕的各家廠商基本都會使用到 UDP 協議 + 自研弱網對抗演算法的搭配。實時網路產品依靠準確的頻寬估計、高效的丟包對抗、合理的前向糾錯等能力提高階到端通訊質量、降低端到端通訊延遲。而擁有可靠且高效的評價產品對於提升弱網對抗能力就變的至關重要。
實際網路的複雜性
實際網路的複雜性遠超如下所列的範圍：
- 多資料流量頻寬競爭
- 不同的收發裝置型別（效能），不同的網路卡硬體和驅動程式
- 不同的路由路徑
- 不同的路徑由不同節點序列構成
- 不同節點的硬體效能和軟體演算法差異
- 地理隔離的物理距離
- 如果資料經過無線或行動網路，那射頻訊號的影響就開始顯著
- 訊號強度、訊雜比、物理遮擋
- 無線協議型別，底層協議的 FEC 或重傳機制
- 多裝置的競爭、同頻干擾和隱藏節點
網路損傷工具的功能和侷限
實際可能的網路鏈路，資料流經歷了各種網路節點和不同型別的裝置和協議，不同裝置的轉發能力、轉發延遲都不盡相同：
為了構建和建模實際網路，我們從實際網路中抽象出了一組引數，用以描述實際網路的損傷程度。被抽象為黑盒的網路鏈路：
用網路損傷儀提供穩定可控的弱網環境：
對網損工具的期望
從對實際網路的探測和抽象來看，我們期望網損工具有以下功能：
- 頻寬限制能力
- 佇列深度
- 突發流量
- 丟包能力
- 豐富的丟包模型
- 固定延遲能力
- 堆積突發能力
- 堆積速率和突發速率的控制
- 高頻高精度的模擬引數修改響應能力
從使用的便利性來看，期望網損工具有以下特性：
- 良好的擴充套件性
- 良好的可程式設計能力
- 良好的互動體驗
網損工具解決的問題
對於設定指定的網路損傷的引數，網損儀能夠實現不同網路引數的準確模擬，能夠在網路鏈路中新增定時定量的可靠網路損傷，能夠提高網路狀態的可控性和可復現能力。
網損工具的侷限性
對於設定什麼樣的網路損傷，使用什麼樣的引數，網損儀本身並不會給出答案。由於網路本身的複雜性，真實網路僅對觀測者提供有限的可見性，而目前整個行業對網路損傷的探測方法和結果並不完備，所以目前市面上不同的網損工具支援的損傷功能和提供的損傷模型不盡相同，也不盡準確。
幾款使用過的網路損傷工具
硬體產品
- S**
這是一款商業網路損傷儀器，支援模組化構建網路拓撲，可以分別設定每個模組的損傷引數，軟體內建常見的通訊裝置模擬元件。
該裝置的特點是模擬引數精度高，拓撲構建靈活。同時也要求使用者對需要模擬的網路拓撲和其中的網路節點有比較清晰的認知，相當於去模擬一個接近白盒的網路鏈路。
自動化方面支援 Restful API 介面呼叫。
- H**
這也是一款商業網路損傷儀，它將網路抽象為兩個方向的鏈路分別新增指定損傷，可以通過 filter 將指定流量匯入不通的鏈路中進行損傷，相比之下這種實現方式更加接近網際網路的思維方式。
在試用這款裝置的時候該款產品仍處在開發和高速迭代中，新增了不少對網際網路行業更友好的特性，比如：更多丟包模型的支援，更多種類的 jitter 分佈支援，Python 呼叫介面的開發等。
使用下來這款產品在 UI 互動和系統穩定性方面還有較大的提升空間。
軟體產品
- QNET - 專案地址
這是騰訊 WeTest 開發的一款網路損傷工具，目前支援 iOS 和 Android 平臺。該工具通過 VPN 的方法代理本機流量實現網路損傷的注入，更適合 Web 或普通型別 APP 開發的弱網測試需求，對於實時音視訊這種流量較大的場景通過 VPN 代理的方式會導致明顯的系統效能問題，使得模擬準確性下降。
該產品的特點是內建了不少弱網場景的模型，比如：電梯、高鐵、地鐵場站場景等，也會更新基於騰訊伺服器探測到的實時延遲和 Jitter 作為模擬資料來源。
自動化方面 Andoid 平臺支援 adb 方式的介面呼叫，iOS 平臺目前還沒有使用過。
- Clumsy - 專案地址
這是一款小團隊的開源軟體，目前僅支援 Windows 平臺使用。
這款軟體的功能相對比較簡單，甚至沒有找到 Jitter 的設定方法。自動化呼叫方面也沒有對應的介面支援。
但對於低成本的 Windows 單機弱網除錯也算是填補了一個空白。
- Apple Network Link Conditioner - 專案地址
這款軟體是作為 Apple 開發者工具存在的，分別支援 MacOS 和 iOS 裝置。
功能方面也比較簡單，除了頻寬限制、丟包和延遲外也沒有看到 Jitter 相關的設定，不過該工具支援一些簡單的網路型別的預置，但實現比較簡單。
該功能模組在不同版本的 Apple 系統中維護的較好，可用性和穩定性都比較有保證，UI 也比較簡潔明瞭。
自動化方面可以通過 applescript 指令碼控制，但控制精度較低，不適合高頻呼叫。
- Linux Traffic Control - 相關文件
大名鼎鼎的 TC 模組作為 Linux 核心的一部分存在，沒有官方的 UI 介面適配。但江湖上流傳著各種各樣的 Wrapper 和第三方 UI。
因為 Linux 核心開源的特性使得 TC 擁有無盡的可能性，但缺點就是學習曲線比較陡峭，並且在不同核心版本中的功能實現有不小的差異，比如：pfifo 雖然文件中都宣告支援，但大多數版本並不支援；甚至有些版本的 jitter 分佈不符合預期。
當 TC 結合 iptables 之後，能實現絕大多數網損儀擁有的靜態損傷功能；而對於動態的損傷受限於 Linux 命令執行的實效性呼叫的精度並不高。如果要提高執行精度就需要去直接調動 C 介面或直接進行程式設計實現。
需要解決的問題
實際工作中網路損傷環境的需求主要來自有兩個方面：
- 探測和確認產品的弱網對抗能力邊界
- 提高產品在實際網路中的弱網對抗能力
對於第一點需求，行業中一般的作法是將某一網路指標或幾個網路指標的組合引數拉滿，直到產品卡死或無法正常使用為止。例如可能的測試方法包括：頻寬限制從 1000Kbps 逐步降低到 100Kbps 或 50Kbps；丟包率從 5% 上升到 70% 或 80%；延遲（或延遲抖動）從 10ms 上升到 2000ms。這種測試方法確實是有意義的，不過從對多種網路損傷裝置的使用經驗來看，不同裝置的頻寬限制功能預設配置的佇列深度和允許的 Burst 資料量是不盡相同的，延遲抖動的預設分佈和是否允許亂序的具體實現也有區別，所以即使是相同的頻寬限制或相同的延遲抖動，用不同的網損工具很能可能會測試出不同的結果；而對於丟包率和固定延遲的指標來說各個工具的預設實現基本上是一致的，分別對應隨機丟包和單位為毫秒的固定延遲。
對於第二點需求，問題的難點是如何描述和建模真實網路，可以看到一部分近期湧現的網路損傷軟體比如 QNET 已經注意到這方面的功能了，開始整合一些對真實網路的探測資料和模型，但受限於產品本身的形態和平臺限制在進行大規模部署和使用時還是有不少障礙。
針對以上提到的兩個問題，聲網分別開展了網路損傷特徵的研究和實際網路探測和建模的持續推進，從目前網路探測的資料來看，實際網路的損傷有以下特徵是傳統弱網測試用例無法覆蓋到的：
- 網路頻寬的時變頻率遠高於直觀，並且需要配合佇列深度和突發流量的支援。
- 長時間持續的高隨機丟包並不常見，大多數丟包與網路的擁堵狀況具有很強的相關性且並不隨機。
- 不存在持續的較低頻寬限制，除非運營商或共享網路的人為設定。
- 基本不存在亂序或重複包的場景，除非在小區或 AP 切換的時候。
在對比了各種網路損傷工具的優劣勢之後，聲網最終選擇了 Linux Traffic Control 的自研方案，目前來看這種方案的開放性和可能性是最高的，TC 命令 + iptables + 自研開發的組合完全能夠覆蓋從弱網對抗邊界測試到實際網路模擬的各種應用場景，為聲網產品在更真實的網路下驗證弱網對抗演算法提供有力的保障。
結語
對於網際網路公司，特別是有模擬 Lastmile 網路需求的公司來說，目前市場上的硬體網損儀適配的還不是太友好，傳統的硬體網損儀從適配運營商和通訊裝置廠商的需求發展起來，更偏重於保障測試的吞吐量和模擬的精度，對於網路型別和網路場景的多樣性缺乏探索，當前市場上也出現了一些軟體的網損解決方案，有些模擬軟體的開發過程中會利用網路探測結果內建一些網路場景和網路型別的模版，更貼合網際網路公司的使用場景。對於弱網對抗要求不高的產品來說，選擇這些軟體模擬弱網是高效且低成本的方案，而對弱網對抗有較高要求的實時網路產品，在有能力做網路探測和訂製網路損傷場景的前提下，使用開源的 Linux Traffic Control 是一種更加自主和具備更多可能性的選擇。
附表：網路損傷工具功能對比
<點選圖片檢視大圖>
Dev for Dev專欄介紹
Dev for Dev（Developer for Developer）是聲網Agora 與 RTC 開發者社群共同發起的開發者互動創新實踐活動。透過工程師視角的技術分享、交流碰撞、專案共建等多種形式，匯聚開發者的力量，挖掘和傳遞最具價值的技術內容和專案，全面釋放技術的創造力。