WebRTC 基准测试：为什么一次看起来“干净”的通话恢复测试可能是错的

作者：Suman Paudel
原文：https://webrtc.ventures/2026/10/webrtc-benchmarking-call-recovery/

在更换视频 SDK、升级到新版本，或者续签供应商合同之前，技术负责人想知道自己产品的通话质量与竞品相比如何、差距在哪里。WebRTC 基准测试正是为此：让每个视频通话产品在完全相同的网络限制下运行（例如限速 500 kbps），并在接收端记录通话质量。

一次基准测试可能看起来正确，实际却是错的。我们对 Google Meet 和 Zoom Web（浏览器中运行的 Zoom）做了一次测试，考察它们在网络中断后如何恢复，结果遇到两种情况：

• 我们最初使用的限速方案限制住了普通网页流量，但 Google Meet 的通话视频绕过了它。​ 我们的速度测试显示约 490 kbps。在最干净的一次运行中，在“500 kbps”设置下，Meet 的接收视频达到了 2.2 Mbps。
• Zoom Web 的视频不出现在标准质量统计里。​ 基于这些统计生成的报告，对 Zoom 而言将没有任何画质数据。

这两种情况都没有报错。如果你正准备依据测试结果做优化、迁移或发布决策，这些就是你需要首先核对的检查项。本文将展示我们如何发现这两个问题，以及在修正之后，恢复测试呈现出了什么。

测试设计：在 Google Meet 与 Zoom Web 上做一次网络中断

测试在我们的 WebRTC 测试实验室中进行。该实验室自动化真实浏览器和一台实体 Android 手机，按固定时序施加网络条件，并每秒记录一次 WebRTC 统计（RTCStats，即浏览器的 getStats() 数据）。每次运行的时序都相同：30 秒正常条件，随后双向限速 500 kbps 持续 15 秒，再恢复正常 30 秒。

我们在两条设备路径上测试 Google Meet 和 Zoom Web：桌面 Chrome 对桌面 Chrome，以及桌面 Chrome 对 Android 手机。共运行 21 次。每次运行有两个接收视频的设备，合计 42 个接收端。

网络中断后的恢复只是一次完整基准测试中的一项。其他项还包括稳定连接下的通话质量、音视频同步、处理器负载和移动网络。同样的方法适用于任何实时音频或视频产品，包括你自己的产品。

WebRTC 网络限速：没有真正生效的限制

我们一开始用的是 Chrome 内置的网络限速，也就是 Puppeteer 之类的浏览器自动化工具所暴露的 DevTools 功能。最初这套设置限制住了普通网页流量，速度测试显示约 490 kbps，但 Google Meet 的通话视频绕过了它。在最干净的一次运行中，接收视频在限速前为 2.4 Mbps，在“500 kbps”设置下为 2.2 Mbps。没有任何报错。实验室之所以能发现，是因为每次运行都会把真实媒体速率与该限速阈值做比对。若保留那些运行结果，Meet 看上去几乎不受中断影响。

Chrome 只有在限速规则附着于某个通话连接时，才会限制它。Google Meet 在页面加载时就建立起通话连接，因此若在测试步骤之间清除再重设限速，后续整个通话就都逃出了限制。我们改为在每台设备上（包括通过 USB 由实验室驱动的手机）从页面加载到通话结束全程保持限速附着。每台设备在上下行各自获得独立的 500 kbps 限制，而且每次运行中通话媒体都未超过该上限。本文所有结果都来自这一设置的运行。

每次运行也会验证自身条件。每次通话前，必须由一项独立速度测试证明确实生效，并且精确记录施加与恢复的时间戳。实测的中断持续时间为 15.1 至 15.7 秒。

在条件得到验证之后，下一步是定义什么叫“已恢复”。

在看结果之前，先定义“已恢复”

恢复不是一个瞬间。我们把它拆成四个时间戳，全部在通话的接收侧测量。

• T0，网络恢复： 中断被解除的时刻。
• T1，媒体恢复传输： T0 之后第一个视频字节数与解码帧数重新增长的一秒采样。
• T2，回到区间内： 入向视频码率首次达到中断前中位数的至少 80% 的采样。
• T3，稳定： 连续第三个落在区间内的采样。稳定恢复时间即 T3 减 T0。

80% 的区间和“连续三个采样”的规则是我们的基准标准，不是 WebRTC 标准。先把它写下来很重要，因为同一通电话，选不同的数值，就可能被判定为“已恢复”或“未恢复”。我们还会把帧率与其自身基线做对比，因为只看数据包流可能会掩盖画面卡死。

getStats 对恢复过程的呈现

实验室每秒保存一次完整统计报告。以下是一条来自 Google Meet 接收端的入向视频记录，取自限速期间，已做裁剪并移除标识符：

{"timestamp": 1791548122391.871, "bytesReceived": 4039236, "packetsReceived": 4042,
  "packetsLost": 20, "framesDecoded": 1112, "framesPerSecond": 29,
  "frameWidth": 1280, "frameHeight": 720, "freezeCount": 8,
  "totalFreezesDuration": 2.497, "jitter": 0.014}

基于这些计数器，每个一秒步长的码率为 8 × ΔbytesReceived / Δt，每秒的“是否在区间内”标记会输入一个简单的连续计数检查。下面的函数按顺序遍历这些标记，统计连续处于区间内的秒数，一旦出现下滑就重置，并返回连续计数首次达到所需长度的时刻：T3。

def streak_end(flags, consecutive):
    """Time of flag number K of the first run of K consecutive True flags."""
    streak = 0
    for t, ok in flags:  # one (time, bitrate >= 80% of baseline) pair per second after T0
    streak = streak + 1 if ok else 0  # any dip below the band resets the count
    if streak >= consecutive:
        return t  # T3: the third in-band second in a row
    return None  # reported as "not recovered within the window", never as zero

第一张图展示的是一个 Google Meet 接收端。限速期间，其视频码率降到约 245 kbps，但仍在传输，并且保持在 720p，帧率大多接近正常。网络恢复后，码率缓慢爬升，用了 26.9 秒才回到正常值的 80% 并保持三秒。

在 Meet 的所有运行中，这一模式都成立。第二张图每次运行每个接收端点对应一个标记。

这些数字描述的是两个应用在一种受控条件下的表现，并不构成排名。工程团队该相信哪个数字，正是接下来几节要回答的问题。

把测量局限当作工程数据

最有用的发现，来自统计数据无法呈现的部分。

• 有些平台把帧信息藏起来了。​ Zoom Web 通过 WebRTC 数据通道传输视频，而非标准视频流，因此没有帧率、分辨率或冻结计数可读。我们改用数据通道字节数来计算其恢复时间。它在限速前的速率也很低：中断前速率介于 158 至 622 kbps，大多低于 500 kbps 的上限，而到会话结束时已增长约四倍。结果，20 个接收端中有 15 个在网络恢复之前就已经在区间内，这意味着所测得的恢复时间更多反映的是我们 30 秒的参考窗口，而非平台性能。下一步是从接收端实际渲染出的画面读取帧标记，让每个平台都以同样的方式被测量。
• “已配置”不等于“已观测”。​ 一条写着“500 kbps”的规则，在各阶段媒体速率确认之前，什么也证明不了。
• 缺失不等于零。​ 不支持的字段、被重置的计数器或提前终止的采集，都会如实标注，绝不以 0 参与平均。
• 把三类结果分开： 通话是否运行、遥测是否完整、质量恢复得多好。被剔除的运行会连同原因一并列出，而不是悄悄丢掉。

这些局限直指最重要的那个决策。

从恢复数据到平台决策

有两个观察到的差异，应当改变你评估平台的方式。所有路径上媒体都没有中断；但在我们测得的全部 22 个 Google Meet 接收端中，稳定码率要么用了超过 20 秒，要么在 30 秒窗口内没有恢复。“从未中断”和“30 秒内未恢复”，形容的是同一批通话。

第二个差异：同样的限速，对不同平台并不等于同样的中断。Zoom Web 的视频在限速开始时本就大多运行在 500 kbps 以下，因此在限速期间仍保持了正常速率的中位数 90% 以上，其 20 个接收端中有 15 个在网络恢复前就已在区间内。这并不意味着 Zoom 恢复得更快，而是说限速几乎没有对它造成中断，因此可测的“恢复”本就很少。

如果你的发布门禁或供应商评估只检查媒体是否恢复传输，它就会放过那些让视频在 30 秒乃至更长时间内停留在正常码率以下的产品。请把“稳定恢复”的目标写进验收标准，检查中断是否确实把各平台压到其正常速率以下，并要求获得足以验证这一切的统计数据。