3. 实时传输协议核心
各位好，我是老周。今天咱们聊一个在WebRTC低延迟传输里非常核心的话题——FEC前向纠错与NACK重传的协同工作。
说实话，我在刚接触WebRTC那会儿，也踩过不少坑。记得有一次做嵌入式视频通话，网络抖动一上来，画面直接卡成PPT。后来才发现，是FEC和NACK的配合出了问题。嗯，今天就把这些经验掰开揉碎了讲给你听。
3.1 FEC前向纠错原理
FEC，全称Forward Error Correction，前向纠错。说白了，就是发送方在发送原始数据包的同时，额外发送一些冗余包。接收方即使丢了一部分包，也能通过冗余包把原始数据恢复出来。
这样做的好处很明显——不需要等待重传，延迟低。但代价是带宽开销增加了。
3.1.1 Reed-Solomon码
Reed-Solomon（RS）码是FEC里最经典的算法之一。它基于有限域（Galois Field）的数学运算，能够纠正任意位置的丢包。
RS码的核心参数是(n, k)：
- k：原始数据包数量
- n：编码后总包数（原始包 + 冗余包）
- 冗余包数量：n - k
举个例子，如果使用RS(10, 8)，意味着每8个原始包生成2个冗余包。接收方只要收到任意10个包中的8个，就能恢复全部原始数据。
关键点：RS码的纠错能力 = n - k。也就是说，冗余包越多，能容忍的丢包率越高。
我在项目中遇到过一个问题：RS码的计算量跟包数量呈平方关系。k值太大，嵌入式设备的CPU扛不住；k值太小，冗余效率又低。我建议k值一般取8~16之间，具体看你的硬件算力。
3.1.2 ULPFEC（Uneven Level Protection FEC）
ULPFEC是WebRTC里默认使用的FEC方案。它跟RS码最大的区别在于——它提供不等保护。
什么意思呢？视频编码里，I帧（关键帧）比P帧重要得多。ULPFEC允许你对I帧使用更多的冗余保护，对P帧使用较少的保护。这样在同等带宽下，关键数据的恢复概率更高。
ULPFEC的包结构是这样的：
+----------------+----------------+----------------+
| RTP Header | FEC Header | FEC Payload |
+----------------+----------------+----------------+
| SSRC, Seq# | Mask, CN | XOR/RS数据 |
+----------------+----------------+----------------+其中FEC Header里的Mask字段是关键——它用位图标记了哪些原始包被保护。CN字段表示当前FEC包保护的原始包数量。
个人经验：ULPFEC的Mask设计很巧妙。它支持最多48个原始包的保护，但实际使用中我建议控制在16个以内。Mask越长，解码延迟越大。
3.2 FEC与NACK的权衡
FEC和NACK，一个主动冗余，一个被动重传。它们各有优劣，需要根据场景权衡。
| 特性 | FEC | NACK |
|---|---|---|
| 延迟 | 低（无需等待重传） | 高（至少1个RTT） |
| 带宽开销 | 固定（无论丢包与否） | 按需（仅丢包时产生） |
| 适用场景 | 高丢包、低延迟要求 | 低丢包、带宽敏感 |
| 实现复杂度 | 高（编解码计算） | 低（简单重传逻辑） |
| 恢复能力 | 有限（受冗余率限制） | 几乎100%（只要网络通） |
你想想看，如果网络丢包率只有1%，你用10%的FEC冗余，那90%的冗余带宽都浪费了。反过来，如果丢包率20%，只用NACK的话，每个丢包都要等一个RTT，延迟直接爆炸。
避坑指南：我曾经在一个项目中，把FEC冗余率设成了固定20%。结果网络好的时候，带宽浪费严重；网络差的时候，20%冗余又不够用。后来改成动态调整，才解决问题。
3.3 动态切换策略
既然FEC和NACK各有优缺点，那能不能根据网络状况动态切换呢？当然可以。这就是WebRTC里所谓的混合策略。
我常用的策略是这样的：
- 低丢包（< 2%）：只用NACK，FEC关闭。带宽开销最小。
- 中丢包（2% ~ 10%）：启用ULPFEC，冗余率 = 丢包率 × 1.2。同时保留NACK作为兜底。
- 高丢包（> 10%）：提高FEC冗余率到丢包率的1.5倍，NACK优先级降低。因为此时重传延迟已经不可接受。
动态切换的核心在于丢包率估计。WebRTC通过RTCP反馈包（Receiver Report）来获取丢包统计。我建议使用滑动窗口法，窗口大小取500ms~1s，避免瞬时抖动导致频繁切换。
关键公式：FEC冗余率 = 目标丢包恢复率 × 丢包率估计值
例如：目标恢复率90%，丢包率10%，则冗余率 = 0.9 × 0.1 = 9%
3.4 带宽开销计算
带宽开销是FEC方案里最需要精打细算的部分。咱们来算一笔账。
假设视频码率为1Mbps，丢包率5%，使用RS(20, 19)保护：
- 冗余率 = (20 - 19) / 19 ≈ 5.26%
- FEC带宽开销 = 1Mbps × 5.26% = 52.6kbps
- 总带宽 = 1Mbps + 52.6kbps = 1.0526Mbps
如果改用ULPFEC，对I帧使用20%冗余，对P帧使用5%冗余：
- 假设I帧占比10%，P帧占比90%
- 平均冗余率 = 10% × 20% + 90% × 5% = 6.5%
- FEC带宽开销 = 1Mbps × 6.5% = 65kbps
你看，ULPFEC虽然平均冗余率更高，但它保护了更重要的数据。在同等视频质量下，ULPFEC的主观体验往往更好。
我的建议：在做带宽预算时，FEC开销不要超过总带宽的20%。超过这个阈值，不如降低视频码率来得划算。
3.5 FEC与NACK协同的完整流程
下面这张图展示了FEC与NACK协同工作的完整流程：
从流程图可以看出，FEC和NACK是互补关系。FEC负责快速恢复，NACK负责兜底。我建议的优先级是：先FEC，后NACK。
3.6 实战中的常见问题
最后，分享几个我在实战中遇到的坑：
- FEC过度保护：冗余率设得太高，带宽爆炸，反而加剧网络拥塞。我建议冗余率不要超过丢包率的2倍。
- NACK风暴：丢包率突然升高时，大量NACK同时发出，导致网络拥塞。解决方案是NACK限速，比如每10ms最多发3个NACK。
- FEC与NACK冲突：FEC还没解码完，NACK就发出去了。我建议设置一个FEC解码等待窗口，比如5ms，等待窗口内不触发NACK。
避坑指南：我曾经在一个项目中，FEC解码等待窗口设成了20ms。结果网络好的时候，FEC解码很快完成，但NACK白白等了20ms，增加了延迟。后来改成动态等待窗口，根据历史解码时间自适应调整，才解决问题。
好了，关于FEC与NACK的协同，今天就聊到这里。记住一句话：没有银弹。FEC和NACK各有适用场景，关键是根据你的网络状况和应用需求，找到那个平衡点。