8、前向纠错（FEC）：FEC 原理、媒体层 FEC（ULP FEC、Flex FEC）、FEC 的带宽开销与权衡

说到实时通信里的丢包问题，很多人第一反应是重传。但重传有个硬伤——它需要时间。你想想看，一个包丢了，你发个请求等对方回传，一来一回至少一个RTT。对于视频通话这种低延迟场景，200ms的延迟已经让人难受了，再等个重传？画面直接就卡住了。

所以就有了FEC。它的思路很直接：与其等丢包了再补，不如提前多塞点冗余数据。这样即使路上丢了一些包，接收端也能靠自己把数据拼回来。说白了，就是用带宽换延迟。

FEC的基本原理

FEC的核心思想其实很简单。我打个比方：你给朋友寄了三个快递，怕丢，就多寄了一个，里面写着"如果前三个都到了，这个扔掉；如果丢了一个，用这个补上"。这就是FEC。

在数学上，FEC通常用异或（XOR）运算来实现。假设我们有三个原始包A、B、C，我们计算一个冗余包R = A ⊕ B ⊕ C。如果接收端只收到了A、B和R，它可以通过A ⊕ B ⊕ R = C来恢复出C。

我在项目中遇到过一个问题：FEC的冗余度设得太高，带宽直接爆了。设得太低，丢包恢复率又不够。这个平衡点，说实话，得根据实际网络情况来调。

媒体层FEC：ULP FEC

ULP FEC是WebRTC早期支持的FEC方案。它的全称是Uneven Level Protection，意思是"不均匀保护"。为什么叫不均匀？因为它对不同的媒体数据给予不同级别的保护。

举个例子，视频帧里I帧比P帧重要得多。I帧丢了，后面一连串P帧都解码不了。所以ULP FEC会对I帧分配更多的冗余包，对P帧少分配一些。这样在有限的带宽下，能最大化视频质量。

ULP FEC的实现方式是这样的：

// 伪代码示例：ULP FEC编码
function encodeULPFEC(mediaPackets, protectionLevel) {
    let fecPackets = [];
    let groupSize = mediaPackets.length;
    
    // 根据保护级别决定冗余包数量
    let numRedundant = Math.ceil(groupSize * protectionLevel);
    
    for (let i = 0; i < numRedundant; i++) {
        let fecPacket = 0;
        // 对原始包进行异或运算
        for (let j = i; j < groupSize; j += numRedundant) {
            fecPacket ^= mediaPackets[j].payload;
        }
        fecPackets.push(fecPacket);
    }
    
    return fecPackets;
}

嗯，这里要注意：ULP FEC的编码效率其实不算高。因为它基于包级别的异或，如果丢包模式比较随机，恢复率还行。但如果连续丢包，效果就大打折扣了。

Flex FEC：更灵活的方案

Flex FEC是后来引入的，它解决了ULP FEC的一些痛点。最大的改进是：你可以自定义FEC的保护模式。

Flex FEC支持两种模式：

• 1D模式：类似于ULP FEC，基于行或列的异或。适合随机丢包。
• 2D模式：同时基于行和列的异或。能抵抗连续丢包，但带宽开销更大。

我个人习惯用2D模式，尤其是在WiFi环境下。WiFi的丢包经常是突发性的，一丢就是好几个包。2D模式在这种场景下恢复率明显更高。

Flex FEC的另一个好处是：它支持部分恢复。什么意思？就是即使冗余包不够，也能恢复出部分数据。这在视频解码中很有用——哪怕恢复出一半的数据，也比全丢了好。

FEC的带宽开销与权衡

这是最让人头疼的部分。FEC说白了就是用带宽换可靠性。你加的冗余越多，抗丢包能力越强，但带宽占用也越大。

我整理了一个表格，方便你直观地理解：

冗余度	抗丢包能力	带宽开销	适用场景
10%	可恢复1个丢包/10个包	低	有线网络，丢包率<5%
25%	可恢复2个丢包/8个包	中	WiFi，丢包率5%-15%
50%	可恢复3个丢包/6个包	高	移动网络，丢包率>15%

你可能会问：那是不是冗余度越高越好？当然不是。带宽是有限的，你给FEC用了太多带宽，留给原始数据的带宽就少了。视频质量反而会下降。

我曾经在一个项目中踩过坑：为了追求零丢包，把FEC冗余度设到了50%。结果视频分辨率被迫降到360p，用户反馈画面模糊得没法看。后来我学乖了，动态调整冗余度——网络好的时候少加点，网络差的时候多加点。

FEC与重传的配合

在实际的WebRTC实现中，FEC很少单独使用。它通常和NACK（重传请求）配合。我的做法是：

1. 先加少量FEC（比如10%-15%），应对随机丢包。
2. 如果丢包率上升，动态增加FEC冗余度。
3. 如果FEC恢复失败，再触发NACK重传。

这样既保证了低延迟（FEC恢复不需要等待），又保证了可靠性（重传兜底）。

下面这张图展示了FEC在WebRTC中的工作流程：

从这张图可以看出，FEC是作为第一道防线存在的。它能在不增加延迟的情况下，解决大部分丢包问题。只有当FEC恢复失败时，才会走重传路径。

最后说一句：FEC不是银弹。它有自己的适用场景和局限性。但如果你能掌握好它的原理和权衡，它绝对是你工具箱里最趁手的工具之一。