WebRTC vs. Zoom 之外：WebRTC 的弱網(wǎng)模擬測試

　　如果你是長(cháng)期關(guān)注 WebRTC 的資深開(kāi)發(fā)者或技術(shù)愛(ài)好者，你可能留意到了，近期圈子里出了一個(gè)不大不小的話(huà)題，引得一些知名 WebRTC 技術(shù)博主紛紛發(fā)聲，表明觀(guān)點(diǎn)。

　　事情是這樣的。

　　前不久，Jitsi 在其官方博客[1]上發(fā)布了一個(gè) WebRTC 與 Zoom Web 客戶(hù)端的視頻通話(huà)對比測試。測試結果顯示，WebRTC 的視頻通話(huà)質(zhì)量比 Zoom 還要好。一石激起千層浪，不少博主發(fā)表了自己的看法。

　　視頻源自 Jitsi 的博客

　　看似是在挑事，但 Jitsi 出此一舉完全事出有因。

　　Jitsi 是一個(gè)開(kāi)源項目，可幫開(kāi)發(fā)者在 Web 、Windows、Linux、Mac OS X、Android 平臺上實(shí)現實(shí)時(shí)的語(yǔ)音、視頻通話(huà)應用。有很多獨立開(kāi)發(fā)者在基于這套代碼開(kāi)發(fā)自己的視頻通話(huà)應用。這一切，都是建立于 WebRTC 的基礎之上實(shí)現的。然而， Jitsi 卻看到作為視頻會(huì )議服務(wù)提供商的 Zoom 不但從 2015 年開(kāi)始就在一些地方一再聲稱(chēng)自己并沒(méi)有使用  WebRTC，甚至不斷表示“WebRTC 是一種能力非常有限的解決方案”：

　　圖：源自 Jitsi 官方博客

　　Jitsi 如何測試 WebRTC 弱網(wǎng)傳輸呢？

　　他們在同一個(gè) Wi-Fi 環(huán)境下，用同樣的一臺 Mac ，做了兩次測試，分別用 WebRTC 和 Zoom 進(jìn)行一對一視頻通話(huà)。在兩組通話(huà)的最初 10 秒，只是進(jìn)行正常通話(huà)，在 10 秒之后，開(kāi)始增加網(wǎng)損，同時(shí)限制上行與下行帶寬至 500kbps。這時(shí)測量?jì)蓚�(gè)方案各自需要多長(cháng)時(shí)間來(lái)調整，使正在進(jìn)行的視頻通話(huà)穩定適應目前網(wǎng)絡(luò )帶寬的變化。如下圖所示，博主 Tsahi Levent-Levi 在其博文[2]中，用一張比較形象圖描繪了測試過(guò)程中的碼率變化。

　　圖片源自 Tsahi Levent-Levi 的博客

　　結果是在帶寬受到人為限制后，WebRTC 的視頻通話(huà)用了 20 秒完全調整到了合適的碼率，而 Zoom 則用了 156 秒。

　　相對于與這個(gè)對比結果，我們更關(guān)心的是，這個(gè)方法對 WebRTC 開(kāi)發(fā)者有多大參考意義呢？WebRTC 開(kāi)發(fā)者參照這個(gè)方法，是否能準確地測試出自己與他人應用之間的差距呢？

　　答案是“否”，這個(gè)方法并不嚴謹。

　　以聲網(wǎng)的經(jīng)驗來(lái)講，上下行同時(shí)限制相同帶寬門(mén)限的測試，并非常用的質(zhì)量測試方式。通常會(huì )單向限制上行，或者限制下行。但是從測試本身來(lái)說(shuō)，是公平的。相信 Jitsi 并不會(huì )專(zhuān)門(mén)針對這個(gè)場(chǎng)景進(jìn)行調試后給出這樣的對比結果，應該是 Zoom 在這個(gè)場(chǎng)景下有弱點(diǎn)被抓住了。

　　從通信架構角度來(lái)看，Zoom 采用的是 MCU/SFU 的服務(wù)器接入通信方式，使用分段式的帶寬自適應策略。而 Jitsi 的 1 對 1 通信，相信是沿用了 WebRTC 的端到端反饋。所以，兩者是不同的。全鏈路反饋在這個(gè)場(chǎng)景中有一定優(yōu)勢，鏈路上的瓶頸可以快速反應到發(fā)送端，從而快速自適應。而分段式策略，就要分別估算上行和下行帶寬，依賴(lài)于服務(wù)器的投遞決策機制，策略配置是一個(gè) QoE 的難點(diǎn)。

　　Tsahi Levent-Levi 也在博客中表示，通過(guò)人為工具干預網(wǎng)絡(luò )傳輸的方式并不夠完全復現真實(shí)的用戶(hù)場(chǎng)景。但我們可以通過(guò)工具來(lái)盡可能的接近用戶(hù)的真實(shí)場(chǎng)景。

　　什么是真實(shí)的用戶(hù)場(chǎng)景呢？一個(gè)人晚上在家通過(guò) Wi-Fi 上網(wǎng)，在線(xiàn)電影播放基本流暢，可一旦在晚間用網(wǎng)高峰期打視頻電話(huà)就畫(huà)面糊，這時(shí)不僅可能帶寬受限了，還可能有較高的丟包率。

　　與有線(xiàn)網(wǎng)絡(luò )通信相比，無(wú)線(xiàn)網(wǎng)絡(luò )通信受環(huán)境影響會(huì )更大，比如高層建筑、用戶(hù)的移動(dòng)、環(huán)境噪音、封閉的環(huán)境等，網(wǎng)絡(luò )服務(wù)質(zhì)量相對不穩定，導致用戶(hù)經(jīng)常在弱網(wǎng)環(huán)境下通信。例如，在車(chē)庫的視頻通話(huà)通常都不如在室外的質(zhì)量。

　　除了受環(huán)境影響外，網(wǎng)絡(luò )覆蓋、過(guò)載控制、鄰區漏配等，也會(huì )造成呼叫失敗、服務(wù)質(zhì)量下降。這些真實(shí)的用戶(hù)場(chǎng)景。

　　Jitsi 所做的就是模擬弱網(wǎng)環(huán)境的測試。一般這種測試是靠修改帶寬、丟包、抖動(dòng)參數來(lái)進(jìn)行模擬。從數據角度講，不同的應用對弱網(wǎng)的定義是不同的，要對各網(wǎng)絡(luò )類(lèi)型最低速率、業(yè)務(wù)場(chǎng)景做綜合考慮。以移動(dòng)場(chǎng)景為例，一般 2G，速率較低的 3G，弱信號的 Wi-Fi 都算是弱網(wǎng)，需要被納入到弱網(wǎng)測試場(chǎng)景中。

　　其實(shí)，這次事件也揭示了一個(gè)很普遍存在問(wèn)題，很多剛接觸 WebRTC 的獨立開(kāi)發(fā)者，可能并不了解如何模擬弱網(wǎng)場(chǎng)景。我們來(lái)分享一些聲網(wǎng)Agora音視頻實(shí)驗室的經(jīng)驗，推薦 3 個(gè) WebRTC 開(kāi)發(fā)者們都可以使用的弱網(wǎng)環(huán)境模擬測試工具。

　　下面詳細說(shuō)一下每個(gè)工具的搭建、使用方法，以及三者之間優(yōu)缺點(diǎn)對比：

　　Linux 內核內置了一個(gè) Traffic Control 框架，能夠實(shí)現流量限速、流量整形、策略應用，可以注入延時(shí)故障、丟包故障、包重復故障、亂序故障，以及模擬網(wǎng)絡(luò )閃斷等情況。TC 對硬件、系統還有一些要求：

　　PC - 建議配置不低于 CPU i3，4G 內存，64G 硬盤(pán)

　　雙網(wǎng)卡 - 除原有板載網(wǎng)卡外， 額外需要一塊 pci-e 網(wǎng)卡（例如 intel 82574L）

　　路由器 - 支持橋接模式

　　網(wǎng)線(xiàn) - 若干

　　系統要求

　　需要 Fedora、OpenSuse、Gentoo、Debian、Mandriva 或 Ubuntu，如果Linux內核版本大于 2.6，則已內置 TC。

　　系統模塊

　　Ubuntu/Debian 系統下需要 iproute2

　　Fedora/RHEL 系統下需要 iproute-tc

　　iptables

　　Linux kernel module : sch_netem

　　同時(shí)，軟件方面還需要安裝 dhcp server。具體安裝方法，請參考 Ubuntu 官方文檔[3]。

　　

　　至此，你已經(jīng)完成了部署。

　　做弱網(wǎng)測試基本是按照以下四個(gè)步驟：

　　設備連接 Wi-Fi 熱點(diǎn)成功獲取 IP 地址，假設為：192.168.3.101。

　　打開(kāi) Linux terminal，輸入 TC 命令為發(fā)送端 IP 為 192.168.3.101 的設備添加網(wǎng)損。

　　此時(shí)手機即在弱網(wǎng)環(huán)境下運行。

　　測試完成后，輸入 TC 命令取消弱網(wǎng)。

　　例如，你要是想限制 IP 地址為 192.168.3.101 的設備上行丟包 5%，那么需要運行如下命令：

　

　　可以說(shuō) TC 框架可以實(shí)現很多場(chǎng)景，但前提是需要開(kāi)發(fā)者們學(xué)會(huì )使用 TC 命令行。如果你想了解更多的 TC 命令，可以學(xué)習一下官方文檔[4]。

　　ATC 其實(shí)是 Facebook 在 2015 年開(kāi)源的一套網(wǎng)絡(luò )測試工具。ATC 是基于 TC 的封裝。

　　在部署好 ATC 弱網(wǎng)控制機后，在手機上通過(guò) Web 界面就可以隨時(shí)切換不同的網(wǎng)絡(luò )環(huán)境。多個(gè)手機可以連接到同一個(gè) Wi-Fi ，復用同一臺弱網(wǎng)控制機，且多設備之間模擬的網(wǎng)絡(luò )環(huán)境互不影響。也就是說(shuō)，部署好這個(gè)測試工具后，團隊里的任何人都可以通過(guò) Web 自行測試，且互不干擾。

　　ATC 的部署方法相對復雜，但只要根據官方文檔[5]，就可以順利完成搭建。按照官方文檔完成搭建之后，大家還需要通過(guò)以下幾行命令配置 HOST 地址，然后就可以啟動(dòng)運行了。

　　測試完成后，點(diǎn)擊按鈕  [Turn Off]  清除弱網(wǎng)設置。

　　Network Link Conditioner（NLC）

　　可能有些 iOS 開(kāi)發(fā)者已經(jīng)認出來(lái)了。NLC 是蘋(píng)果官方提供的網(wǎng)絡(luò )模擬工具，支持安裝在 macOS 和 iOS 上。

　　打開(kāi) Xcode，選擇 Xcode -> Open Developer Tool -> More Develop Tools。

　　用蘋(píng)果賬號登錄網(wǎng)站，搜索 Additional Tools for Xcode，下載 Xcode 對應版本的 Additional Tools。

　　打開(kāi)下載的文件，在 Hardware 文件夾中雙擊 Network Link Conditioner 安裝。 安裝完成后，工具會(huì )在系統設置中的最后一排出現。

　　通過(guò)打開(kāi)“開(kāi)發(fā)者選項”就可以使用 Network Link Conditioner 功能。

　　數據線(xiàn)連接手機到 Mac 上，Xcode -> Windows -> Devices -> 選中當前手機設備，右鍵彈出

　　菜單 -> 選擇Show Provisioning Profiles… 會(huì )彈出一個(gè)證書(shū)列表窗口

　　如果手機已經(jīng)安裝了必要的開(kāi)發(fā)者證書(shū)，直接點(diǎn)擊窗口中的 done 按鈕即可。否則需要點(diǎn)擊左下角的 + 號，把從網(wǎng)上下載下來(lái)的證書(shū)導入進(jìn)去， 點(diǎn)擊 done 按鈕關(guān)閉窗口。

　　此時(shí)手機設置中就多了一個(gè)開(kāi)發(fā)者選項，進(jìn)入開(kāi)發(fā)者選項可以看到 Network Link Conditioner 選項。

　　NLC 的使用方法就簡(jiǎn)單多了，不需要用命令行。如果 NLC 中的配置不滿(mǎn)足需求的話(huà)，可以手動(dòng)添加更多的配置。在 Mac 端和 iOS 上，按照以下操作即可。

　　需要注意的是 interface 設置，當 iOS 通過(guò)共享 Wi-Fi 熱點(diǎn)的方式作為接入設備的弱網(wǎng)控制機時(shí)，需要將 interface 設置為 Cellular。

　　相對來(lái)講，TC 的參數最為豐富，可以控制更多細節，能模擬出多種不同的網(wǎng)絡(luò )情況，但操作太復雜，需要開(kāi)發(fā)者熟悉 TC 命令及網(wǎng)絡(luò )模型。NLC 最簡(jiǎn)單易操作，參數配置可以滿(mǎn)足普通開(kāi)發(fā)需求。

　　WebRTC 1.0 的重點(diǎn)是提供給開(kāi)發(fā)者更多對媒體、數據通道的控制。而根據此前的提案[6]顯示，下一版本的 WebRTC 將有可能使數據處理脫離主線(xiàn)程。使用 RTCDataChannels 傳輸數據，相比使用 WebSocket 會(huì )有更好的擁塞控制。

　　根據 WebRTCHacks 博主 Philipp Hancke 的分析[7]，Zoom 的 Web Client 并沒(méi)有使用 WebRTC，客戶(hù)端用 WebSocket 進(jìn)行媒體傳輸，該方法類(lèi)似于 WebRTC 中的 Turn/TCP。盡管有利于穿越防火墻，但在進(jìn)行實(shí)時(shí)通信時(shí)，如果出現丟包，就會(huì )進(jìn)行重傳，最終導致積累延時(shí)。僅從這個(gè)角度看，下一個(gè)版本的 WebRTC 的方案更優(yōu)于 Zoom。

　　我們在上文中也曾提到，WebRTC 服務(wù)器的策略配置開(kāi)發(fā)是 QoE 的難點(diǎn)。所以，多人通信的質(zhì)量不佳，是原生 WebRTC 應用最常被人詬病的問(wèn)題。其實(shí)，聲網(wǎng)的 Agora Web SDK 也是基于 WebRTC 開(kāi)發(fā)而來(lái)的，并且基于原生 WebRTC 進(jìn)行了多方面的優(yōu)化。聲網(wǎng) Agora Web SDK 始終聚焦于通信質(zhì)量的提升，優(yōu)化至現在的版本，已經(jīng)可支持17人的視頻通話(huà)。我們針對 WebRTC 網(wǎng)關(guān)進(jìn)行了多層面的優(yōu)化，比如傳輸質(zhì)量保障，對原生 WebRTC QoS 調優(yōu)，針對場(chǎng)景差異做了不同的優(yōu)化策略。

　　我們提供的是全球化的服務(wù)，覆蓋了包括視頻會(huì )議、在線(xiàn)醫療、在線(xiàn)教育、社交直播、社交游戲音視頻、金融、IoT 等多種實(shí)時(shí)音頻、視頻通信場(chǎng)景。目前，Agora Web SDK 已經(jīng)是全球商用服務(wù)中規模最大的基于 WebRTC 的實(shí)時(shí)通信 SDK。很多情況下 WebRTC 不會(huì )被考慮作為大頻道解決方案。而 Agora Web SDK 現在已經(jīng)支持百萬(wàn)級別并發(fā)的大頻道通話(huà)。