作為一個使用 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 版塊

總結

以上是生活随笔為你收集整理的WebRTC通话质量调优：三个弱网模拟测试工具的使用与对比的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。