1. 丢包恢复概述：为什么需要丢包恢复？
各位同学，咱们今天聊聊丢包恢复。说白了，就是网络把数据包弄丢了，我们怎么把它找回来。
你可能觉得，丢几个包怕什么？重传不就行了？嗯，在实时通信里，事情没那么简单。
1.1 实时通信中的核心挑战
实时通信，比如视频会议、在线直播、远程手术，对延迟极其敏感。我做过一个项目，客户要求端到端延迟低于 200 毫秒。你想想看，200 毫秒是什么概念？眨一下眼都要 300 毫秒左右。
在这种场景下，传统的 TCP 重传机制基本不可用。为什么？因为 TCP 发现丢包后，会等超时，然后重传，再等确认。这一来一回，几百毫秒就没了。用户那边画面直接卡住，或者出现马赛克。
我个人习惯把实时通信的挑战归纳为三个核心矛盾：
| 挑战 | 描述 | 典型后果 |
|---|---|---|
| 延迟敏感 | 数据必须在几十到几百毫秒内到达 | 重传超时导致画面卡顿 |
| 带宽波动 | 网络带宽随时可能骤降 | 丢包率飙升，质量断崖式下跌 |
| 无序到达 | 包可能乱序，甚至晚到很久 | 解码器等待导致延迟增加 |
我曾经在一个跨国视频会议项目中遇到过这种情况：海外用户反馈画面经常花屏，但国内用户完全正常。排查下来，就是跨洋链路的随机丢包导致的。TCP 重传根本来不及，UDP 又不管丢包。最后我们不得不在应用层做 FEC（前向纠错）来兜底。
1.2 丢包对音视频质量的具体影响
丢包到底会造成什么后果？我分音频和视频来说。
音频丢包
音频数据量小，但连续性要求极高。丢一个包，可能就导致几十毫秒的音频丢失。人耳对断续非常敏感，听起来就是「咔咔咔」的杂音。
- 单包丢失：产生短暂爆音或静音，影响听感。
- 连续丢包：语音变得断断续续，完全无法理解。
- 突发丢包：比如一下子丢 5 个包，直接导致 100 毫秒以上的音频空白。
视频丢包
视频数据量大，而且帧之间存在依赖关系。丢一个关键帧（I 帧）的包，可能导致后面几十个 P 帧都无法正确解码。这就是为什么有时候画面突然花掉，然后过好几秒才恢复。
我整理了一个表格，方便你理解不同帧类型丢包的影响：
| 帧类型 | 丢包影响范围 | 恢复难度 |
|---|---|---|
| I 帧（关键帧） | 影响整个 GOP（图像组） | 高，需要重传或请求新关键帧 |
| P 帧（预测帧） | 影响后续依赖它的帧 | 中，可通过错误隐藏部分恢复 |
| B 帧（双向预测帧） | 影响范围较小 | 低，通常直接丢弃 |
1.3 丢包恢复的核心思路
既然丢包不可避免，那怎么恢复？目前主流思路就两条：
- 主动恢复：发送端提前加入冗余数据，接收端直接恢复。典型代表是 FEC（前向纠错）。
- 被动恢复：接收端发现丢包后，请求发送端重传。典型代表是 NACK（否定确认）和 ARQ（自动重传请求）。
你可能会问，哪个更好？其实没有绝对的好坏。我个人的习惯是：
- 对延迟要求极高（比如 < 50ms）的场景，优先用 FEC。
- 对带宽敏感、允许一定延迟的场景，用 NACK 重传更省带宽。
- 大多数实际系统，两者结合使用。
下面这张图，是我自己总结的丢包恢复技术分类，你可以先有个整体印象：
1.4 为什么编码层需要参与？
你可能觉得丢包恢复是网络层的事，跟编码有什么关系？
关系大了。编码器决定了数据包的依赖结构。如果编码器能把关键数据分散到多个包中，或者生成一些冗余数据，丢包恢复的效果会好很多。
举个例子，我在做 WebRTC 优化时发现，默认的编码器会把 I 帧数据塞进一个超大包。一旦这个包丢了，整个画面就崩了。后来我们在编码器里做了分片，把 I 帧拆成多个小包，再配合 FEC，丢包恢复率从 60% 提升到了 95% 以上。
核心观点：编码层是丢包恢复的第一道防线。编码器输出的数据包结构，直接决定了后续恢复手段的效果。好的编码策略，能让 FEC 和重传事半功倍。
嗯，这一章就到这里。记住一句话：丢包不可怕，可怕的是没有恢复策略。后面的章节，我会带你深入 FEC、NACK、ARQ 的具体实现，以及如何在编码器中设计丢包友好的数据布局。