1. WebRTC 抗丢包策略概述：为什么需要抗丢包？
各位同学好，我是老张。今天开始咱们聊 WebRTC 抗丢包策略。说实话，这个主题我讲了快五年，每次备课还是会想起当年踩过的坑。
先问个问题：你平时用视频通话，有没有遇到过画面突然卡成 PPT？或者声音断断续续像机器人？嗯，这背后十有八九是丢包在搞鬼。
1.1 丢包是什么？
丢包，说白了就是数据包在传输过程中丢了。你发出去 100 个包，对方只收到 95 个，那 5 个就是丢包。
为什么会丢？我简单列几个常见原因：
- 网络拥塞：路由器忙不过来，直接扔掉一些包
- 链路质量差：Wi-Fi 信号弱、4G 信号不稳定
- 缓冲区溢出：路由器或交换机的缓存满了
- 硬件故障：网卡、网线、光猫出问题
你想想看，互联网从设计之初就是"尽力而为"的。它不保证每个包都能送到，也不保证按顺序送到。这在网页浏览、文件下载场景下问题不大——大不了重传。但实时通信不行，你等不了。
核心矛盾：实时通信要求低延迟（通常 < 200ms），而丢包重传需要时间。这个矛盾就是抗丢包策略要解决的根本问题。
1.2 丢包对实时通信的影响
我在项目中遇到过最夸张的一次，丢包率到了 15%。视频画面直接变成马赛克拼图，音频完全没法听。用户投诉电话打爆了客服。
丢包的影响分几个维度：
| 丢包率 | 视频影响 | 音频影响 |
|---|---|---|
| 0% - 1% | 几乎无感知 | 几乎无感知 |
| 1% - 3% | 偶尔花屏、卡顿 | 轻微杂音 |
| 3% - 5% | 频繁花屏、跳帧 | 声音断续、听不清 |
| 5% - 10% | 画面严重破损 | 基本无法通话 |
| > 10% | 视频流几乎不可用 | 完全无法通话 |
注意看，音频比视频更敏感。为什么？因为人耳对声音的连续性要求极高。视频丢一帧，你眼睛可能没反应过来；但音频丢一个包，耳朵立刻就能听出"咔"的一声。
1.3 实时通信的特殊挑战
WebRTC 面临的挑战，跟传统 TCP 传输完全不同。我习惯用三个词概括：
- 实时性：延迟必须低。TCP 那种"丢了就等重传"的玩法，在实时通信里行不通。
- 连续性：画面和声音必须流畅。不能因为丢一个包就让整个通话卡住。
- 公平性：不能因为自己抗丢包，就把别人的带宽抢光。这在多人会议里尤其重要。
举个例子。TCP 传输文件，丢包了怎么办？等超时，重传。这个过程可能花几百毫秒甚至几秒。但实时通信里，一个视频帧的播放时间只有 33 毫秒（30fps）。你等不起。
我曾经踩过的坑：早期做项目时，我直接用 TCP 传视频流。结果丢包率一上来，整个通话就卡死。后来才明白，实时通信必须用 UDP，然后自己在应用层做抗丢包。
1.4 WebRTC 的抗丢包武器库
WebRTC 不是只用一种方法抗丢包。它有一套组合拳。我画了张图，帮你理清整体脉络：
从图上你能看到，WebRTC 的策略分两大块：
- 发送端：主动加冗余（FEC）、请求重传（NACK）、动态调整码率（GCC）
- 接收端：缓冲抗抖动（JitterBuffer）、丢包隐藏（PLC）、请求关键帧（PLI/FIR）
这些策略不是孤立的。它们互相配合，根据网络状况动态切换。比如网络好的时候，少用 FEC 省带宽；网络差的时候，加大 FEC 比例同时降低码率。
我的建议：初学者不要一上来就研究每个策略的细节。先理解整体架构，知道什么场景用什么策略。后面每个章节我会逐一拆解。
1.5 丢包率与用户体验的量化关系
我习惯用 MOS（Mean Opinion Score）来量化用户体验。这是通信行业的标准：
| MOS 分值 | 用户体验 | 对应丢包率（典型值） |
|---|---|---|
| 4.5 - 5.0 | 非常好，无感知 | < 0.5% |
| 4.0 - 4.4 | 良好，偶尔小瑕疵 | 0.5% - 1% |
| 3.5 - 3.9 | 一般，能接受但明显 | 1% - 3% |
| 3.0 - 3.4 | 较差，影响沟通 | 3% - 5% |
| < 3.0 | 不可用 | > 5% |
你看，丢包率超过 5%，用户体验就崩了。而现实中的互联网，尤其是移动网络，丢包率经常在 2% - 8% 之间波动。这就是为什么抗丢包策略不是"锦上添花"，而是"雪中送炭"。
1.6 本章小结
好了，这一章我们聊了：
- 丢包是什么，为什么会丢
- 丢包对音视频通话的具体影响
- 实时通信面临的特殊挑战
- WebRTC 抗丢包的整体策略框架
我个人觉得，理解"为什么"比"怎么做"更重要。你只有真正明白丢包带来的痛苦，才会在设计系统时认真对待抗丢包。后面每一章，我会带你深入每个策略的细节，包括算法原理、代码实现、参数调优。
嗯，今天就到这儿。记住这张全景图，它是我们整个课程的地图。