1. WebRTC丢包恢复技术概述
做实时通信这些年，我见过太多团队在丢包面前栽跟头。明明编码、传输都调好了，一上弱网环境，画面直接变成马赛克。说白了，丢包是实时通信里最头疼的问题之一。今天我们就从根上聊聊这件事。
1.1 实时通信中的丢包问题
丢包，就是数据包在传输过程中没能到达对端。为什么会丢？原因其实挺多的：
- 网络拥塞：路由器缓冲区满了，直接丢弃新来的包
- 链路质量差：Wi-Fi信号弱、4G/5G信号不稳定
- 硬件故障：交换机、网卡偶尔抽风
- MTU限制：包太大被分片，分片丢失导致整个包废掉
我记得有一次帮客户排查线上问题，用户反馈视频通话每隔几秒就卡一下。抓包一看，丢包率其实只有2%。但就是这2%，让用户体验直接崩了。你想想看，2%的丢包率在文件传输里根本不算事，但在实时通信里，它就是灾难。
关键认知：实时通信对丢包的容忍度极低。WebRTC的目标是在丢包率高达20%-30%的网络环境下，依然保持可用的音视频通话质量。
1.2 丢包对QoE的影响
QoE（Quality of Experience）是用户主观感受的量化。丢包对QoE的影响，我习惯从三个维度来看：
| 丢包影响维度 | 表现 | 用户感受 |
|---|---|---|
| 视频质量 | 画面花屏、马赛克、块状模糊 | 看不清人脸、无法识别内容 |
| 音频质量 | 声音断续、金属音、爆音 | 听不清对话、听觉疲劳 |
| 流畅度 | 卡顿、延迟抖动、音画不同步 | 对话节奏被打乱、体验割裂 |
这里有个有意思的点。我曾经做过一个实验：同样的5%丢包率，视频通话的MOS分（Mean Opinion Score）从4.5直接掉到2.0，而音频通话只掉到3.0。为什么？因为人眼对画面瑕疵更敏感。所以很多WebRTC方案会优先保音频，视频可以降质，但声音必须清晰。
我的经验：在实际项目中，我建议把丢包恢复策略按优先级排序——音频 > 视频关键帧 > 视频非关键帧。这个顺序能最大化用户满意度。
1.3 丢包恢复技术分类
WebRTC里丢包恢复技术主要分三大类：FEC、ARQ和PLC。我画了一张图帮你理清它们的关系：
1.3.1 FEC（前向纠错）
FEC的思路是：发送端主动发送冗余数据，接收端即使丢了一部分包，也能靠冗余数据恢复出原始数据。说白了，就是多传一些数据来对抗丢包。
WebRTC里主要用两种FEC：
- ULP FEC：Uneven Level Protection，对不同重要性的数据提供不同保护级别
- Flex FEC：更灵活的FEC方案，可以自定义保护组的大小和冗余率
注意：FEC会增加带宽消耗。我曾经见过一个团队把FEC冗余率设到50%，结果丢包率是降了，但带宽不够用，反而导致更多丢包。FEC的冗余率需要根据网络状况动态调整。
1.3.2 ARQ（自动重传请求）
ARQ就是接收端发现丢包后，告诉发送端「这个包我没收到，再发一次」。WebRTC里用的是NACK（Negative ACKnowledgment）机制。
ARQ的优点是带宽利用率高——只在丢包时才重传。但缺点也很明显：重传需要时间，会增加延迟。对于实时性要求高的场景（比如视频通话），重传延迟超过200ms就没意义了。
我习惯把ARQ和FEC搭配使用：轻度丢包用FEC扛，重度丢包用ARQ补。这样既能控制延迟，又能保证恢复率。
1.3.3 PLC（丢包隐藏）
PLC跟前两种不一样。它不依赖发送端，而是接收端自己想办法「猜」出丢失的数据。说白了，就是靠算法把丢包的影响降到最低。
音频PLC常用波形插值：根据丢包前后的音频波形，预测中间缺失的部分。视频PLC更简单粗暴：要么冻结上一帧，要么用前一帧和下一帧做插值。
避坑指南：我曾经在项目中只依赖PLC处理所有丢包，结果发现丢包率超过10%时，PLC生成的音频听起来像机器人说话。PLC只能作为最后一道防线，不能替代FEC和ARQ。
1.4 WebRTC丢包恢复技术全景图
把上面三种技术放在一起看，WebRTC的丢包恢复体系其实是一个分层架构：
| 层级 | 技术 | 作用时机 | 延迟影响 | 带宽消耗 |
|---|---|---|---|---|
| 发送端主动 | FEC | 发送前 | 无额外延迟 | 高（固定冗余） |
| 接收端反馈 | ARQ | 丢包发生后 | 增加RTT | 低（按需重传） |
| 接收端本地 | PLC | 播放前 | 无网络延迟 | 无 |
实际应用中，WebRTC会综合使用这三种技术。比如Google Meet的架构里，FEC处理小规模丢包（<5%），ARQ处理中等丢包（5%-15%），PLC兜底处理极端丢包（>15%）。
嗯，这里要注意：没有一种技术能解决所有丢包问题。好的丢包恢复方案，一定是根据网络状况动态选择策略组合。这也是我们后面29章要深入探讨的内容。