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 版块