抖动（Jitter）

什么是抖动？

抖动是数据包从发送到到达之间时间延迟的变化。延迟测量的是平均延时，而抖动测量的是这种延时的不一致性。可以把它想象成火车时刻表：延迟是平均旅行时间，而抖动则是不可预测性——有时火车准点，有时早到，有时晚点。

在视频通话中，数据包理想情况下应该以固定的间隔到达。你的编码器可能每 20 毫秒发送一个数据包，理想情况下接收方也每 20 毫秒收到一个数据包。但在现实中，网络状况会变化——数据包 1 在 50 毫秒后到达，数据包 2 在 35 毫秒后到达，数据包 3 在 60 毫秒后到达，数据包 4 在 40 毫秒后到达。这种变化就是抖动。

高抖动会导致音频丢失、视频冻结、机器人般或断断续续的声音，以及整体通话质量下降。它对实时通信特别有害，因为它破坏了人类感知所期望的流畅、连续的播放。

抖动 vs. 延迟

这些术语经常被混淆，但它们测量的是网络性能的不同方面：

• 延迟：数据包从发送方到接收方的平均时间。测量整体延时
• 抖动：数据包到达时间的变化。测量延时的不一致性

你可能遇到高延迟但低抖动的情况（一致但缓慢的传输，如卫星互联网），或者低延迟但高抖动的情况（快速但不可预测，如拥塞的 WiFi）。对于视频通话，你需要低延迟和低抖动两者兼具。

抖动反映的是数据包流中的短期状况或不一致性，而延迟（RTT）是较长时期内的平均时间。网络可能有 50 毫秒的平均延迟但有 30 毫秒的抖动，这意味着数据包在发送后的 20 毫秒到 80 毫秒之间的任何时间到达。

抖动是如何产生的

网络拥塞

这是最常见的原因。当路由器和交换机繁忙时，数据包会在队列中等待。队列长度不断波动——有时数据包立即通过，有时要等待 50 毫秒。这种可变性就产生了抖动。

拥塞在高峰时段（住宅网络的晚上、企业网络的工作时间）以及共享连接（公共 WiFi、蜂窝网络）上更加严重。

路由变化

互联网路由是动态的。如果网络路径在通话中发生变化（在移动网络中很常见，当你在基站之间移动时，或者当 ISP 调整路由时），数据包会突然经历不同的延迟，导致抖动激增。

WiFi 干扰

无线网络天生比有线连接抖动更大。无线电干扰、竞争设备、信号强度变化和重传都会引入时序可变性。WiFi 通常比有线以太网增加 10-30 毫秒的抖动（以太网 <5 毫秒）。

数据包优先级（QoS）

讽刺的是，服务质量（QoS）机制有时会增加抖动。当路由器优先处理某些流量时，其他数据包会根据当前优先级队列负载而不同程度地延迟。

数据包路由可变性

并非所有数据包都走同一条路径。有些可能走直接路线，有些可能通过额外的跳点。这种路径多样性会产生到达时间的变化。

对音频和视频质量的影响

音频影响

音频对抖动极其敏感，因为我们的耳朵很容易检测到时序不一致：

• 低抖动（0-20 毫秒）：无法察觉，音频听起来自然
• 中等抖动（20-50 毫秒）：偶尔断断续续或略显机械的声音
• 高抖动（50-100 毫秒以上）：频繁丢失、严重失真、语音难以理解

当抖动超过抖动缓冲区的容量时，缓冲区会耗尽要播放的数据包，导致音频间隙（静音）或乱序播放延迟的数据包（声音混乱）。

视频影响

视频对抖动的容忍度略高于音频，但仍会受到影响：

• 低抖动：以一致的帧率流畅播放
• 中等抖动：偶尔掉帧或卡顿
• 高抖动：频繁冻结、动作不流畅、帧乱序显示

由于视频帧可以灵活地解码和显示（不像音频必须连续播放），视频的抖动缓冲区可以更大而不会产生明显的质量影响。

抖动缓冲区：解决方案

抖动缓冲区是接收端的一个小队列，在播放之前临时存储传入的数据包。它不会在数据包到达时立即播放（由于抖动，这会听起来断断续续），而是收集数据包并以固定的间隔播放它们。

抖动缓冲区如何工作

1. 数据包由于抖动以不规则的间隔到达
2. 抖动缓冲区临时存储这些数据包
3. 缓冲区等待直到有足够的数据包以确保连续播放
4. 然后以固定的间隔播放数据包（例如，音频每 20 毫秒）
5. 这平滑了时序变化，提供一致的播放

权衡取舍：更大的缓冲区可以平滑更多抖动但会增加延迟。更小的缓冲区减少延迟但如果抖动高则有可能耗尽。

固定 vs. 自适应抖动缓冲区

固定抖动缓冲区使用恒定大小（例如，始终 60 毫秒）。简单但效率低——在良好网络上浪费延迟，在糟糕网络上不够用。

自适应抖动缓冲区根据当前网络状况动态调整大小。当抖动低时，缓冲区缩小以最小化延迟。当抖动增加时，缓冲区扩大以防止丢失。

现代 WebRTC 实现普遍使用自适应抖动缓冲区。它们持续监控数据包到达模式并实时调整缓冲区大小，音频通常范围为 15-120 毫秒。

NetEQ：WebRTC 的音频抖动缓冲区

NetEQ 是 Chromium 的复杂音频抖动缓冲区实现，用于所有基于 Chromium 的浏览器（Chrome、Edge、Opera）。它是生产环境中最先进的抖动缓冲区算法之一。

NetEQ 功能

• 自适应缓冲：根据网络抖动持续优化延迟
• 丢包隐藏：当数据包丢失时合成缺失的音频
• 时间拉伸/压缩：微妙地加速或减慢音频以维持缓冲区水平而不改变音高
• 舒适噪声生成：在静音期间添加柔和的背景噪声以避免刺耳的间隙
• 动态范围适应：在整个通话期间适应不同的抖动模式

缓冲区大小行为

NetEQ 通常从约 40 毫秒的缓冲区开始。在抖动最小的稳定网络上，它可以缩小到 15-20 毫秒，最小化延迟。在抖动高的糟糕网络上，它扩展到 100-120 毫秒以防止丢失。

算法不断评估："我能在不冒丢失风险的情况下减少缓冲区吗？"以及"我需要增加缓冲区来处理当前的抖动水平吗？"

视频抖动缓冲区

视频抖动缓冲区的工作原理与音频类似，但有不同的约束：

• 可以更大（50-200 毫秒），因为视频帧以离散间隔显示（例如，30 fps = 每 33 毫秒）
• 必须处理帧之间的依赖关系（H.264 等编解码器中的 I 帧、P 帧、B 帧）
• 当缓冲区不足时可以跳过帧，不像音频必须连续播放
• 通常优先处理关键帧（I 帧）而不是差分帧以确保可解码性

可接受的抖动水平

ITU-T 建议和行业标准建议：

• 优秀：<10 毫秒抖动（局域网、优质有线连接）
• 良好：10-30 毫秒抖动（典型宽带、良好 WiFi）
• 可接受：30-50 毫秒抖动（边缘连接、繁忙网络）
• 较差：50-100 毫秒抖动（严重拥塞或不稳定的网络）
• 无法使用：>100 毫秒抖动（通话质量严重下降）

这些阈值假设有足够的抖动缓冲。如果没有抖动缓冲区，即使 20-30 毫秒的抖动也会导致明显的质量问题。

测量抖动

WebRTC Stats API

在 RTCPeerConnection 上使用 getStats() 访问抖动指标：

• jitter：数据包到达时间变化（以秒为单位，通常为 0.001-0.100）
• jitterBufferDelay：当前抖动缓冲区大小
• jitterBufferEmittedCount：从缓冲区播放的数据包数量

浏览器工具

• Chrome：chrome://webrtc-internals 显示实时抖动图表
• Firefox：about:webrtc 显示每个连接的抖动统计

网络测试工具

像 iperf、mtr 或在线抖动测试这样的工具可以独立于 WebRTC 测量网络级抖动。

减少抖动

1. 使用有线连接

以太网的抖动远低于 WiFi（通常 <5 毫秒 vs. 10-30 毫秒）。对于关键通话，尽可能使用有线连接。

2. 减少网络拥塞

• 关闭占用大量带宽的应用程序（流媒体、下载、云同步）
• 在重要通话期间限制网络上的其他用户
• 如果持续拥塞，升级到更高带宽

3. 服务质量（QoS）

配置路由器优先处理 WebRTC 流量（STUN/TURN 使用的 UDP 端口，或使用 DSCP 标记）。这确保视频通话数据包优先于时间敏感性较低的流量（如文件下载）。

4. 优化 WiFi

• 使用 5GHz 频段而不是 2.4GHz（拥塞少，抖动低）
• 靠近接入点以获得强信号
• 通过更改 WiFi 信道减少干扰
• 如果可用，使用 WiFi 6（802.11ax）——负载下的抖动特性更好

5. 选择更好的 ISP/网络

一些 ISP 具有更稳定的路由和更好的对等协议，导致抖动更低。光纤连接通常比有线电视或 DSL 的抖动更低。

6. 增加数据包大小（打包时间）

更少频率地发送更大的数据包可以减少抖动的影响。对于音频，在良好网络上使用 20 毫秒打包，但在糟糕网络上增加到 60 毫秒甚至 120 毫秒。更大的数据包意味着更少的数据包时序变化很重要。

7. 边缘服务器

在更靠近用户的地方部署 WebRTC SFU 服务器。更短的网络路径具有更少的跳点，减少抖动累积的机会。

抖动 vs. 丢包

这些问题经常一起出现，但它们是不同的问题：

• 抖动：数据包以不规则的时间到达，但（通常）最终都会到达
• 丢包：有些数据包根本无法到达

如果抖动缓冲区溢出（数据包到达太晚被丢弃为无用），高抖动可能导致丢包。相反，丢包不一定会导致抖动——数据包可能一致性地丢失而没有时序变化。

结论

抖动是视频通话质量的沉默破坏者。虽然延迟决定整体延时，带宽决定最大质量，但抖动决定一致性。即使带宽完美、延迟可接受的网络，如果抖动高，仍然可能提供糟糕的通话质量。

幸运的是，WebRTC 的自适应抖动缓冲区（如音频的 NetEQ）在掩盖抖动方面非常有效，自动适应网络条件。但这有一个极限——极端抖动（>100 毫秒）无法在不增加不可接受的延迟的情况下完全补偿。

理解抖动可以帮助你诊断"通话听起来断断续续"的投诉，优化网络基础设施，并设定现实的质量期望。有线连接、QoS 优先级和边缘部署是对抗抖动的最佳防御。

参考资料

• Jitter - Glossary - Mozilla Developer Network
• How WebRTC's NetEQ Jitter Buffer Provides Smooth Audio - webrtcHacks
• What is Jitter and How to use Jitter Buffer to reduce jitter? - TRTC
• WebRTC and Buffers - Stream
• Improved Jitter Buffer Management for WebRTC - ACM
• Network Jitter or Round Trip Time - which is more important in WebRTC? - Cyara
• Jitter Buffer - BlogGeek.me
• Real-time Networking - WebRTC for the Curious