WebRTC vs. Zoom 之外:WebRTC 的弱网模拟测试(一)

阅读数:77 2019 年 11 月 30 日 22:31

WebRTC vs. Zoom 之外:WebRTC 的弱网模拟测试(一)

作为一个使用 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 是一种能力非常有限的解决方案”:

WebRTC vs. Zoom 之外:WebRTC 的弱网模拟测试(一)

图:源自 Jitsi 官方博客

Jitsi 如何测试 WebRTC 弱网传输呢?

他们在同一个 Wi-Fi 环境下,用同样的一台 Mac ,做了两次测试,分别用 WebRTC 和 Zoom 进行一对一视频通话。在两组通话的最初 10 秒,只是进行正常通话,在 10 秒之后,开始增加网损,同时限制上行与下行带宽至 500kbps。这时测量两个方案各自需要多长时间来调整,使正在进行的视频通话稳定适应目前网络带宽的变化。如下图所示,博主 Tsahi Levent-Levi 在其博文 [2] 中,用一张比较形象图描绘了测试过程中的码率变化。

WebRTC vs. Zoom 之外:WebRTC 的弱网模拟测试(一)

图片源自 Tsahi Levent-Levi 的博客

结果是在带宽受到人为限制后,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_forward
2iptables -F
3iptables -P INPUT ACCEPT
4iptables -P FORWARD ACCEPT
5iptables -t nat -A POSTROUTING -o eno1 -j MASQUERADE
6modprobe ifb
7ip link set ifb0 up

至此,你已经完成了部署。

评论

发布