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

　　事情是這樣的。

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

　　視頻源自 Jitsi 的博客

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

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

　　圖：源自 Jitsi 官方博客

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

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

　　圖片源自 Tsahi Levent-Levi 的博客

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

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

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

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

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

　　Tsahi Levent-Levi 也在博客中表示，通過人為工具干預(yù)網(wǎng)絡(luò)傳輸?shù)姆绞讲⒉粔蛲耆珡?fù)現(xiàn)真實的用戶場景。但我們可以通過工具來盡可能的接近用戶的真實場景。

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

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

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

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

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

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

　　Linux 內(nèi)核內(nèi)置了一個 Traffic Control 框架，能夠?qū)崿F(xiàn)流量限速、流量整形、策略應(yīng)用，可以注入延時故障、丟包故障、包重復(fù)故障、亂序故障，以及模擬網(wǎng)絡(luò)閃斷等情況。TC 對硬件、系統(tǒng)還有一些要求：

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

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

　　路由器 - 支持橋接模式

　　網(wǎng)線 - 若干

　　系統(tǒng)要求

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

　　系統(tǒng)模塊

　　Ubuntu/Debian 系統(tǒng)下需要 iproute2

　　Fedora/RHEL 系統(tǒng)下需要 iproute-tc

　　iptables

　　Linux kernel module : sch_netem

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

　　

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

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

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

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

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

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

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

　

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

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

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

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

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

　　Network Link Conditioner（NLC）

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

　　打開 Xcode，選擇 Xcode -> Open Developer Tool -> More Develop Tools。

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

　　打開下載的文件，在 Hardware 文件夾中雙擊 Network Link Conditioner 安裝。 安裝完成后，工具會在系統(tǒng)設(shè)置中的最后一排出現(xiàn)。

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

　　數(shù)據(jù)線連接手機到 Mac 上，Xcode -> Windows -> Devices -> 選中當(dāng)前手機設(shè)備，右鍵彈出

　　菜單 -> 選擇Show Provisioning Profiles… 會彈出一個證書列表窗口

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

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

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

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

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

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

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

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

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