作為一個使用 WebRTC 獨立開發者或團隊，怎樣才能知道自己 App 的通話質量已經“達標”了呢？如何進行合理的弱網模擬測試？介紹給開發者們三個開源工具的部署、使用方法，及其各自優缺點。
如果你是長期關注 WebRTC 的資深開發者或技術愛好者，你可能留意到了，近期圈子裡出了一個不大不小的話題，引得一些知名 WebRTC 技術博主紛紛發聲，表明觀點。
事情是這樣的。
前不久，Jitsi 在其官方部落格[1]上釋出了一個 WebRTC 與 Zoom Web 客戶端的視訊通話對比測試。測試結果顯示，WebRTC 的視訊通話質量比 Zoom 還要好。一石激起千層浪，不少博主發表了自己的看法。
看似是在挑事，但 Jitsi 出此一舉完全事出有因。
Jitsi 是一個開源專案，可幫開發者在 Web 、Windows、Linux、Mac OS X、Android 平臺上實現實時的語音、視訊通話應用。有很多獨立開發者在基於這套程式碼開發自己的視訊通話應用。這一切，都是建立於 WebRTC 的基礎之上實現的。然而， Jitsi 卻看到作為視訊會議服務提供商的 Zoom 不但從 2015 年開始就在一些地方一再聲稱自己並沒有使用 WebRTC，甚至不斷表示“WebRTC 是一種能力非常有限的解決方案”： 
Jitsi 如何測試 WebRTC 弱網傳輸呢？
他們在同一個 Wi-Fi 環境下，用同樣的一臺 Mac ，做了兩次測試，分別用 WebRTC 和 Zoom 進行一對一視訊通話。在兩組通話的最初 10 秒，只是進行正常通話，在 10 秒之後，開始增加網損，同時限制上行與下行頻寬至 500kbps。這時測量兩個方案各自需要多長時間來調整，使正在進行的視訊通話穩定適應目前網路頻寬的變化。如下圖所示，博主 Tsahi Levent-Levi 在其博文[2]中，用一張比較形象圖描繪了測試過程中的位元速率變化。
結果是在頻寬受到人為限制後，WebRTC 的視訊通話用了 20 秒完全調整到了合適的位元速率，而 Zoom 則用了 156 秒。
相對於與這個對比結果，我們更關心的是，這個方法對 WebRTC 開發者有多大參考意義呢？WebRTC 開發者參照這個方法，是否能準確地測試出自己與他人應用之間的差距呢？
答案是“否”，這個方法並不嚴謹。
以聲網的經驗來講，上下行同時限制相同頻寬門限的測試，並非常用的質量測試方式。通常會單向限制上行，或者限制下行。但是從測試本身來說，是公平的。相信 Jitsi 並不會專門針對這個場景進行除錯後給出這樣的對比結果，應該是 Zoom 在這個場景下有弱點被抓住了。
從通訊架構角度來看，Zoom 採用的是 MCU/SFU 的伺服器接入通訊方式，使用分段式的頻寬自適應策略。而 Jitsi 的 1 對 1 通訊，相信是沿用了 WebRTC 的端到端反饋。所以，兩者是不同的。全鏈路反饋在這個場景中有一定優勢，鏈路上的瓶頸可以快速反應到傳送端，從而快速自適應。而分段式策略，就要分別估算上行和下行頻寬，依賴於伺服器的投遞決策機制，策略配置是一個 QoE 的難點。
Tsahi Levent-Levi 也在部落格中表示，通過人為工具干預網路傳輸的方式並不夠完全復現真實的使用者場景。但我們可以通過工具來儘可能的接近使用者的真實場景。
真實使用者場景與弱網環境
什麼是真實的使用者場景呢？一個人晚上在家通過 Wi-Fi 上網，線上電影播放基本流暢，可一旦在晚間用網高峰期打視訊電話就畫面糊，這時不僅可能頻寬受限了，還可能有較高的丟包率。
與有線網路通訊相比，無線網路通訊受環境影響會更大，比如高層建築、使用者的移動、環境噪音、封閉的環境等，網路服務質量相對不穩定，導致使用者經常在弱網環境下通訊。例如，在車庫的視訊通話通常都不如在室外的質量。
除了受環境影響外，網路覆蓋、過載控制、鄰區漏配等，也會造成呼叫失敗、服務質量下降。這些真實的使用者場景。
Jitsi 所做的就是模擬弱網環境的測試。一般這種測試是靠修改頻寬、丟包、抖動引數來進行模擬。從資料角度講，不同的應用對弱網的定義是不同的，要對各網路型別最低速率、業務場景做綜合考慮。以移動場景為例，一般 2G，速率較低的 3G，弱訊號的 Wi-Fi 都算是弱網，需要被納入到弱網測試場景中。
弱網模擬測試的正確姿勢
其實，這次事件也揭示了一個很普遍存在問題，很多剛接觸 WebRTC 的獨立開發者，可能並不瞭解如何模擬弱網場景。我們來分享一些聲網Agora音視訊實驗室的經驗，推薦 3 個 WebRTC 開發者們都可以使用的弱網環境模擬測試工具。
下面詳細說一下每個工具的搭建、使用方法，以及三者之間優缺點對比:
Linux Traffic Control(TC)
Linux 核心內建了一個 Traffic Control 框架，能夠實現流量限速、流量整形、策略應用，可以注入延時故障、丟包故障、包重複故障、亂序故障，以及模擬網路閃斷等情況。TC 對硬體、系統還有一些要求：
硬體要求
PC - 建議配置不低於 CPU i3，4G 記憶體，64G 硬碟
雙網路卡 - 除原有板載網路卡外, 額外需要一塊 pci-e 網路卡（例如 intel 82574L）
路由器 - 支援橋接模式
網線 - 若干
系統要求
需要 Fedora、OpenSuse、Gentoo、Debian、Mandriva 或 Ubuntu，如果Linux核心版本大於 2.6，則已內建 TC。
系統模組
Ubuntu/Debian 系統下需要 iproute2
Fedora/RHEL 系統下需要 iproute-tc
iptables
Linux kernel module : sch_netem
同時，軟體方面還需要安裝 dhcp server。具體安裝方法，請參考 Ubuntu 官方文件[3]。
開始部署
NIC-0 通過網線連線外網, 假設對應 Net device eth0
NIC-1 通過網線連線路由器 WAN 口, 假設對應 Net device eth1
路由器: 開啟橋接模式, 關閉 DHCP 服務
PC 端輸入命令列：
1vi /etc/default/isc-dhcp-server複製程式碼新增：
1INTERFACESv4="eth1"複製程式碼重啟服務：
1sudo /etc/init.d/isc-dhcp-server restart複製程式碼重啟後執行以下命令：
1echo "1" > /proc/sys/net/ipv4/ip_forward2iptables -F3iptables -P INPUT ACCEPT4iptables -P FORWARD ACCEPT5iptables -t nat -A POSTROUTING -o eno1 -j MASQUERADE6modprobe ifb7ip link set ifb0 up複製程式碼至此，你已經完成了部署。
TC 的使用方法
做弱網測試基本是按照以下四個步驟：
裝置連線 Wi-Fi 熱點成功獲取 IP 地址，假設為：192.168.3.101。
開啟 Linux terminal，輸入 TC 命令為傳送端 IP 為 192.168.3.101 的裝置新增網損。
此時手機即在弱網環境下執行。
測試完成後，輸入 TC 命令取消弱網。
例如，你要是想限制 IP 地址為 192.168.3.101 的裝置上行丟包 5%，那麼需要執行如下命令：
1sudo tc qdisc add dev ifb0 root handle 1: prio bands 32sudo tc qdisc add dev eth1 ingress3sudo tc filter add dev eth1 parent ffff: protocol ip u32 match u32 0 0 flowid 1:1 action mirred egress redirect dev ifb04sudo tc qdisc add dev ifb0 parent 1:3 handle 30: netem loss 5 limit 10005sudo tc filter add dev ifb0 protocol ip parent 1:0 prio 3 u32 match ip src 192.168.3.101 flowid 1:3複製程式碼如果想要限制 IP 地址為 192.168.3.101 的裝置下行丟包 20%，需要執行如下命令：
1sudo tc qdisc add dev eth1 root handle 1: prio bands 32sudo tc qdisc add dev eth1 parent 1:3 handle 30: netem loss 20 limit 10003sudo tc filter add dev eth1 protocol ip parent 1:0 prio 3 u32 match ip dst 192.168.3.101 flowid 1:3複製程式碼可以說 TC 框架可以實現很多場景，但前提是需要開發者們學會使用 TC 命令列。如果你想了解更多的 TC 命令，可以學習一下官方文件[4]。
Augmented Traffic Control(ATC)
ATC 其實是 Facebook 在 2015 年開源的一套網路測試工具。ATC 是基於 TC 的封裝。
在部署好 ATC 弱網控制機後，在手機上通過 Web 介面就可以隨時切換不同的網路環境。多個手機可以連線到同一個 Wi-Fi ，複用同一臺弱網控制機，且多裝置之間模擬的網路環境互不影響。也就是說，部署好這個測試工具後，團隊裡的任何人都可以通過 Web 自行測試，且互不干擾。
ATC 的部署方法相對複雜，但只要根據官方文件[5]，就可以順利完成搭建。按照官方文件完成搭建之後，大家還需要通過以下幾行命令配置 HOST 地址，然後就可以啟動執行了。
開啟 Setting：
1vi atcui/atcui/settings複製程式碼新增 HOST 地址 ：
1ALLOWED_HOSTS = ['*']複製程式碼啟動命令：
1atcd --atcd-wan eth0 --atcd-lan eth1複製程式碼使用方法
裝置接入對應 Wi-Fi
開啟 http://192.168.3.1:8000 （假設 eth1 IP地址為：192.168.3.1）
輸入對應弱網引數後，點選按鈕 [Update Shaping] 生效，該弱網僅對本機生效
測試完成後，點選按鈕 [Turn Off] 清除弱網設定。
Network Link Conditioner(NLC)
可能有些 iOS 開發者已經認出來了。NLC 是蘋果官方提供的網路模擬工具，支援安裝在 macOS 和 iOS 上。
macOS 端安裝
開啟 Xcode，選擇 Xcode -> Open Developer Tool -> More Develop Tools。
用蘋果賬號登入網站，搜尋 Additional Tools for Xcode，下載 Xcode 對應版本的 Additional Tools。
開啟下載的檔案，在 Hardware 資料夾中雙擊 Network Link Conditioner 安裝。 安裝完成後，工具會在系統設定中的最後一排出現。
iOS 端安裝
通過開啟“開發者選項”就可以使用 Network Link Conditioner 功能。
資料線連線手機到 Mac 上，Xcode -> Windows -> Devices -> 選中當前手機裝置，右鍵彈出
選單 -> 選擇Show Provisioning Profiles... 會彈出一個證書列表視窗
如果手機已經安裝了必要的開發者證書，直接點選視窗中的 done 按鈕即可。否則需要點選左下角的 + 號，把從網上下載下來的證書匯入進去， 點選 done 按鈕關閉視窗。
此時手機設定中就多了一個開發者選項，進入開發者選項可以看到 Network Link Conditioner 選項。
使用方法
NLC 的使用方法就簡單多了，不需要用命令列。如果 NLC 中的配置不滿足需求的話，可以手動新增更多的配置。在 Mac 端和 iOS 上，按照以下操作即可。
Mac 端
iOS 端
需要注意的是 interface 設定，當 iOS 通過共享 Wi-Fi 熱點的方式作為接入裝置的弱網控制機時，需要將 interface 設定為 Cellular。
對比與小結
相對來講，TC 的引數最為豐富，可以控制更多細節，能模擬出多種不同的網路情況，但操作太複雜，需要開發者熟悉 TC 命令及網路模型。NLC 最簡單易操作，引數配置可以滿足普通開發需求。
WebRTC 1.0 的重點是提供給開發者更多對媒體、資料通道的控制。而根據此前的提案[6]顯示，下一版本的 WebRTC 將有可能使資料處理脫離主執行緒。使用 RTCDataChannels 傳輸資料，相比使用 WebSocket 會有更好的擁塞控制。
根據 WebRTCHacks 博主 Philipp Hancke 的分析[7]，Zoom 的 Web Client 並沒有使用 WebRTC，客戶端用 WebSocket 進行媒體傳輸，該方法類似於 WebRTC 中的 Turn/TCP。儘管有利於穿越防火牆，但在進行實時通訊時，如果出現丟包，就會進行重傳，最終導致積累延時。僅從這個角度看，下一個版本的 WebRTC 的方案更優於 Zoom。
我們在上文中也曾提到，WebRTC 伺服器的策略配置開發是 QoE 的難點。所以，多人通訊的質量不佳，是原生 WebRTC 應用最常被人詬病的問題。其實，聲網的 Agora Web SDK 也是基於 WebRTC 開發而來的，並且基於原生 WebRTC 進行了多方面的優化。聲網 Agora Web SDK 始終聚焦於通訊質量的提升，優化至現在的版本，已經可支援17人的視訊通話。我們針對 WebRTC 閘道器進行了多層面的優化，比如傳輸質量保障，對原生 WebRTC QoS 調優，針對場景差異做了不同的優化策略。
我們提供的是全球化的服務，覆蓋了包括視訊會議、線上醫療、線上教育、社交直播、社交遊戲音視訊、金融、IoT 等多種實時音訊、視訊通訊場景。目前，Agora Web SDK 已經是全球商用服務中規模最大的基於 WebRTC 的實時通訊 SDK。很多情況下 WebRTC 不會被考慮作為大頻道解決方案。而 Agora Web SDK 現在已經支援百萬級別併發的大頻道通話。
與更多 WebRTC 開發者交流開發問題與經驗，歡迎訪問 RTC 開發者社群 WebRTC 版塊