WebRTC通話質量調優：三個弱網模擬測試工具的使用與對比

做爲一個使用 WebRTC 獨立開發者或團隊，怎樣才能知道本身 App 的通話質量已經「達標」了呢？如何進行合理的弱網模擬測試？介紹給開發者們三個開源工具的部署、使用方法，及其各自優缺點。

歡迎訪問 RTC 開發者社區，與更多實時音視頻開發者交流經驗。 

若是你是長期關注 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 的使用方法

作弱網測試基本是按照如下四個步驟：

1. 設備鏈接 Wi-Fi 熱點成功獲取 IP 地址，假設爲：192.168.3.101。

2. 打開 Linux terminal，輸入 TC 命令爲發送端 IP 爲 192.168.3.101 的設備添加網損。

3. 此時手機即在弱網環境下運行。

4. 測試完成後，輸入 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複製代碼

使用方法

1. 設備接入對應 Wi-Fi

2. 打開 http://192.168.3.1:8000 （假設 eth1 IP地址爲：192.168.3.1）

3. 輸入對應弱網參數後，點擊按鈕 [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 版塊