videocalling
glossary.backToGlossary
丢包（Packet Loss）

丢包（Packet Loss）

技术

数据包在网络传输过程中未能到达目的地的现象

什么是丢包？

丢包是指一个或多个通过网络传输的数据包未能到达目的地的现象。想象一下寄出 100 封信，但只有 95 封到达——那 5 封从未送达的信就代表丢包。在视频通话中，那些丢失的数据包可能是你声音的一部分、视频帧或控制信号。

每个 WebRTC 通话每秒发送数千个数据包。你的摄像头和麦克风生成连续的数据流，被分解成小数据包（通常每个 1000-1500 字节）并通过互联网发送。当网络条件完美时，每个数据包都会到达。但在现实中，一些数据包会在途中丢失。

与下载文件不同（丢失的数据包可以重传而你不会注意到），实时视频通话必须继续播放。当数据包丢失时，你会听到音频丢失、看到视频冻结或经历像素化。WebRTC 采用复杂的技术来最小化丢包影响，但超过某些阈值后，质量不可避免地会下降。

丢包是如何发生的

网络拥塞

这是最常见的原因。当路由器、交换机或网络链路超载时，它们的缓冲空间是有限的。当缓冲区填满时，新到达的数据包会被简单地丢弃。这就像高速公路交通堵塞——当太多汽车试图使用同一条道路时，一些车必须被拒之门外。

拥塞在高峰使用时段、共享网络（公共 WiFi、蜂窝网络）以及多个应用程序在同一连接上竞争带宽时更加严重。

硬件故障

故障的网络设备（路由器、交换机、电缆、WiFi 接入点）可能损坏或丢弃数据包。损坏的以太网电缆、过热的路由器或故障的网卡会导致与拥塞无关的随机丢包。

WiFi 问题

与有线连接相比，无线连接天生更容易丢包：

  • 干扰：其他 WiFi 网络、微波炉、蓝牙设备、无绳电话
  • 信号衰减：墙壁、距离、障碍物削弱信号，导致传输错误
  • 冲突：多个设备在同一信道上同时传输
  • 隐藏节点问题：无法相互听到的设备都在传输，在接入点处造成冲突

优质 WiFi（强信号、5GHz 频段、WiFi 6）可能有 0.1-0.5% 的丢包率。糟糕的 WiFi 很容易达到 5-10% 以上的丢包率。

软件错误

有缺陷的网络驱动程序、防火墙配置错误或操作系统问题可能导致数据包丢失。虽然不如物理层问题常见，但仍会发生。

故意丢弃（QoS）

服务质量（QoS）系统有时会在拥塞期间故意丢弃较低优先级的流量。如果 WebRTC 流量未被优先处理，它可能会被丢弃以支持其他流量。

对通话质量的影响

音频影响

音频对丢包极其敏感：

  • <1% 丢包：无法察觉或几乎察觉不到
  • 1-2.5% 丢包：可接受的质量，偶尔有轻微故障
  • 3-5% 丢包：明显的质量下降，频繁丢失
  • 5-10% 丢包：严重的质量问题，语音变得难以理解
  • >10% 丢包：严重退化，通信变得非常困难

丢失的音频数据包会导致语音间隙、机器人般或失真的声音，或者如果连续数据包丢失则完全中断。

视频影响

由于帧间依赖性，视频对丢包甚至更敏感：

  • <1% 丢包：良好的质量，罕见的伪影
  • 1-3% 丢包：偶尔像素化或短暂冻结
  • 3-5% 丢包：频繁的伪影，明显的退化
  • 5-10% 丢包：严重像素化、长时间冻结、块状视频
  • >10% 丢包：视频几乎无法使用

丢失的视频数据包会导致像素化（块状伪影）、冻结（当关键帧丢失时）、颜色失真或完全掉帧。由于视频编解码器依赖于先前的帧，丢失一个数据包可能会损坏多个后续帧，直到下一个关键帧。

为什么 WebRTC 使用 UDP

WebRTC 主要使用 UDP（用户数据报协议）而不是 TCP（传输控制协议）。理解原因需要了解它们的区别：

TCP：可靠但慢

TCP 通过确认和重传保证数据包传递。如果数据包丢失，TCP 会检测到并重新发送。这确保了 100% 的可靠性——每个数据包最终都会按正确顺序到达。

问题在于：重传需要时间（通常一个往返需要 100-300 毫秒）。当重传的数据包到达时，已经太晚了——视频已经向前移动了。乱序播放旧的音频或视频数据包会导致比简单跳过它们更差的质量。

UDP：快速但有损

UDP 不提供重传、不提供确认、不提供保证。数据包发送后就被遗忘。如果它们到达，很好。如果没有，它们就永远丢失了。

对于实时通信，这实际上更好。UDP 开销最小、延迟低，并避免了"队头阻塞"问题，即一个丢失的数据包会延迟所有后续数据包（TCP 中会发生这种情况）。

WebRTC 接受一些丢包会发生的事实，并使用应用层技术来缓解它，而不是依赖传输层重传。

WebRTC 如何处理丢包

由于 UDP 不重传，WebRTC 实现了自己的错误恢复机制：

1. 前向纠错（FEC）

FEC 在传输前添加冗余数据，允许接收方在不重传的情况下重建丢失的数据包。可以把它想象成发送多个副本或奇偶校验信息。

音频 FEC（Opus）：Opus 编解码器包含内置的 FEC。启用后，它会添加 20-30% 的冗余，允许重建单个丢失的数据包。对隔离的丢包非常有效。

视频 FEC：不太常用，因为添加 20% 以上的冗余会降低视频质量（那些带宽本可以用于更高分辨率）。现代 WebRTC 使用选择性 FEC——只保护 SVC（可扩展视频编码）中的基础层，将开销减少约 35%。

权衡：FEC 会增加带宽使用并增加延迟（20-50 毫秒）。只有在丢包率高或需要完美质量时才激活 FEC。

2. 丢包隐藏（PLC）

当数据包丢失时，PLC 合成合理的替代数据来掩盖损失。

音频 PLC：WebRTC 的 NetEQ 抖动缓冲区包含复杂的 PLC，它可以：

  • 重复或拉伸最后接收到的音频片段
  • 根据前面的音频合成类似语音的声音
  • 对于扩展的丢失逐渐淡入舒适噪声

PLC 可以以合理的质量隐藏长达 60-80 毫秒的损失。超过这个时间，隐藏会变得明显。

视频 PLC：重复或冻结最后成功解码的帧。一些实现使用运动估计来合成中间帧，尽管这在计算上很昂贵。

3. 重传（RTX）

WebRTC 可以有选择地请求重传重要的丢失数据包——通常是视频的关键帧（I 帧）。RTX 与 TCP 重传的不同之处在于它是有选择性的和时间感知的：只有在数据包到达时仍然有用时才重传。

例如，即使延迟 100 毫秒到达，丢失的关键帧也可能值得重传，因为没有它，所有后续帧都无法解码。但丢失的差分帧（P 帧或 B 帧）通常不值得重传——当它到达时，我们已经向前移动了。

4. 冗余编码（RED）

RED（冗余编码）与当前数据包一起发送先前数据包的低质量版本。如果当前数据包丢失，接收方可以使用来自后续数据包的冗余（低质量）版本。

对于音频特别有效，其中发送先前帧（64 kbps）的低比特率副本（8 kbps）增加的开销很小，但可以从隔离的丢失中恢复。

5. 自适应比特率

当检测到丢包时，WebRTC 的拥塞控制会降低编码比特率。较低的比特率意味着发送的数据包更少，减少拥塞，从而减少未来的丢包。这是反应性的但有效——用质量换取可靠性。

6. 参考帧选择

视频编码器可以配置为使用抗错误的参考模式。编码器可以定期参考较旧的帧或使用多个参考帧，而不是每个帧都依赖于紧邻的前一帧（其中一次丢失会损坏许多帧）。这限制了丢包带来的错误传播。

测量丢包

WebRTC Stats API

在 RTCPeerConnection 上使用 getStats() 访问：

  • packetsLost：未能到达的总数据包数
  • packetsReceived：成功接收的总数据包数
  • packetsSent：发送的总数据包数
  • 计算丢包百分比：(packetsLost / (packetsReceived + packetsLost)) * 100

浏览器开发者工具

  • Chrome：chrome://webrtc-internals 实时显示丢包图表
  • Firefox：about:webrtc 显示每个轨道的丢包统计

网络测试工具

像 iperf 或 mtr 这样的工具可以独立于 WebRTC 测量网络上的丢包，帮助识别丢包是网络级别还是应用级别的问题。

预防和减少丢包

1. 使用有线连接

以太网的丢包率远低于 WiFi。对于关键通话，使用有线连接。典型丢包率：有线 <0.1%，WiFi 0.1-5%。

2. 优化 WiFi

  • 使用 5GHz 频段（干扰更少）
  • 靠近接入点（强信号）
  • 更改到拥塞较少的信道
  • 升级到 WiFi 6/6E（更好地处理多个设备）
  • 更换旧的/故障的硬件

3. 减少网络拥塞

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

4. 服务质量（QoS）

配置路由器优先处理 WebRTC 流量（UDP 端口、DSCP 标记）。这确保即使网络忙于其他流量，视频通话数据包也能通过。

5. 检查硬件

测试以太网电缆，更换故障的路由器/交换机，更新网络驱动程序。故障硬件会导致 QoS 无法修复的随机丢包。

6. 启用 WebRTC 错误恢复

  • 为音频启用 Opus FEC
  • 在需要时使用 RED（冗余编码）
  • 配置 RTX 用于关键帧重传
  • 调整抖动缓冲区以处理突发性丢失

突发性 vs. 随机丢包

并非所有丢包都是平等的：

  • 随机丢失：隔离的数据包不可预测地丢失。FEC 和 PLC 可以相当好地容忍 2% 的随机丢失
  • 突发性丢失：连续的数据包一起丢失。2% 的突发性丢失（例如，连续丢失 10 个数据包，然后 490 个到达）比 2% 的随机丢失严重得多。突发性丢失会破坏大多数恢复机制

突发性丢失通常表示严重拥塞、路由变化或 WiFi 干扰。它比随机丢失更难缓解。

结论

丢包是实时通信的敌人。虽然带宽决定最大质量，延迟决定延时，但丢包通过移除音频和视频流的片段直接破坏通话质量。

WebRTC 的错误恢复机制——FEC、PLC、RTX、RED——在掩盖低水平丢包（<3%）方面非常有效。但超过某些阈值后，再聪明的工程也无法重建丢失的数据。预防总是胜于缓解。

理解丢包可以帮助你诊断"音频断断续续"或"视频像素化"的投诉，优化网络基础设施，并设定现实的质量期望。有线连接、QoS 优先级和充足的带宽是对抗丢包的最佳防御。

参考资料

相关术语

带宽（Bandwidth）延迟（Latency）抖动（Jitter）
glossary.backToGlossary