1. 丢包恢复概述：为什么我们需要它？
各位同学，咱们直接进入正题。做实时音视频通信，最让人头疼的问题之一就是丢包。你想想看，视频卡成幻灯片，声音断断续续，用户早就骂娘了。我做了十几年网络传输，见过太多因为丢包没处理好导致项目翻车的案例。
说白了，丢包恢复就是一套“防丢包”和“补丢包”的组合拳。今天这一章，我们先搞清楚三个问题：为什么丢包？丢包会怎样？有哪些手段可以对付它？
1.1 网络丢包的原因与影响
先说说丢包是怎么发生的。我习惯把丢包原因分成三类：
- 网络拥塞——这是最常见的。路由器缓存满了，新来的包只能扔掉。就像早高峰的地铁，挤不上去就只能等下一趟。
- 链路质量差——无线网络、Wi-Fi、4G/5G，信号波动大。我曾在一次户外直播项目中，现场Wi-Fi信号被干扰，丢包率直接飙到15%。
- 硬件/软件故障——网卡驱动问题、路由器老化、防火墙误杀。嗯，这些虽然少见，但遇到了就是大坑。
丢包的影响有多严重？我给大家列个表：
| 丢包率 | 音频体验 | 视频体验 |
|---|---|---|
| 0% - 0.5% | 基本无感知 | 偶有轻微马赛克 |
| 0.5% - 2% | 偶尔杂音、断字 | 画面卡顿、花屏 |
| 2% - 5% | 声音断续严重 | 视频无法正常观看 |
| > 5% | 通话基本不可用 | 画面冻结或黑屏 |
1.2 丢包恢复技术的三大分类
目前业界主流的丢包恢复技术，我归纳为三类：ARQ（自动重传请求）、FEC（前向纠错）、PLC（丢包隐藏）。它们各有各的适用场景，咱们一个一个说。
1.2.1 ARQ：最朴素的“重传”方案
ARQ的原理很简单：接收方发现丢了包，就告诉发送方“这个包我没收到，再发一次”。
- 优点：实现简单，带宽利用率高（只在丢包时重传）。
- 缺点：引入额外延迟。一次重传至少增加一个RTT（往返时间）。
- 适用场景：对延迟不敏感的场景，比如文件传输、非实时通信。
但在实时音视频里，RTT超过200ms时，ARQ基本就废了。我建议只在RTT < 100ms的局域网或优质网络中使用。
1.2.2 FEC：主动“冗余”方案
FEC的思路是：发送方在原始数据之外，额外发送一些冗余数据。接收方即使丢了一部分包，也能通过冗余数据恢复出原始数据。
- 优点：不依赖重传，延迟可控。
- 缺点：会占用额外带宽。冗余越多，带宽浪费越大。
- 适用场景：对延迟敏感、网络丢包率相对稳定的场景。
举个例子，假设每4个原始包生成1个冗余包。如果只丢1个包，接收方可以用剩下的3个原始包+1个冗余包恢复出来。但如果丢了2个包，那就恢复不了了。
核心思想：FEC是在带宽和恢复能力之间做权衡。冗余越多，抗丢包能力越强，但带宽消耗也越大。
1.2.3 PLC：接收端的“猜谜”方案
PLC跟前面两种完全不同。它不依赖发送方，而是接收方自己“猜”丢掉的包是什么内容。
- 音频PLC：根据前后音频波形，插值生成丢失的音频帧。比如WebRTC中的NetEQ就内置了PLC算法。
- 视频PLC：用前一帧的画面填补丢失的帧，或者做运动补偿。
- 优点：零额外带宽，零额外延迟。
- 缺点：恢复质量有限。丢包多了，猜出来的内容就失真严重。
我个人习惯把PLC当作“最后一道防线”。当ARQ和FEC都来不及或失效时，PLC至少能让用户体验不至于完全中断。
1.3 三种技术的对比与选择
我把它们放在一起对比，大家看得更清楚：
| 特性 | ARQ | FEC | PLC |
|---|---|---|---|
| 延迟影响 | 增加1个RTT | 无额外延迟 | 无额外延迟 |
| 带宽消耗 | 仅丢包时消耗 | 持续消耗冗余带宽 | 零消耗 |
| 恢复质量 | 完全恢复 | 取决于冗余度 | 近似恢复 |
| 实现复杂度 | 低 | 中 | 高 |
| 适用网络 | 低延迟网络 | 丢包率稳定网络 | 任何网络（作为补充） |
1.4 知识体系总览
下面这张图，我把本章的核心逻辑画出来了。大家先有个整体印象：
从这张图可以看出来，丢包恢复不是单一技术能解决的。你需要根据网络条件、延迟要求、带宽预算，灵活组合这三种手段。