4.1 链路层优化：FEC与纠错

4.1 链路层优化：FEC 与纠错

第 3 章的选路解决"挑一条好路"，本节解决"路都不够好时怎么办"。承上：3.3 节末尾的"全不达标"分支，接力棒交到这里。启下：4.3 节的 QoS 排队与本节的纠错配合，构成边缘设备的完整质量工具箱。读完本节，你应当能给任意一条劣化链路开出纠错处方，并算清处方带来的带宽代价。

短板的物理来源

廉价链路的短板不是随机的。宽带丢包多发生在运营商拥塞队列（晚高峰突发）与无线空口（信号波动）；抖动主要来自队列调度（不同包排队时间不同）；时延则由物理路径绕行决定，算法帮不上忙。对策要分而治之：丢包用冗余修复（前向纠错、包复制），抖动用缓冲整形（接收端重排匀速），时延只能靠选路绕开（3.3 节）或就近分流（1.2 节）。把三类问题混为一谈、指望"优化"包治百病，是方案讨论里最常见的空转。

前向纠错：用带宽换重传

前向纠错（FEC）的原理是把一组数据包（例如 4 个）一起编码，额外生成校验包（例如 1 个）一起发送；接收端只要 5 个包里收到任意 4 个，就能完整还原原始数据——丢一个包无需重传、无需等待。对实时流（语音、视频会议）这是质变：重传一个包的代价是一个往返时延加排队，在 100 毫秒往返的链路上就是可感知的卡顿；FEC 把这个代价变成发送前就已支付的带宽。

冗余比例的账

FEC 的两个参数决定一切：组大小（多少个原始包一组）与冗余比例（每组加几个校验包）。修复能力与代价的换算：4 比 1 冗余（4 原始加 1 校验）可修复每组 1 包丢失，带宽开销 25%；若原始丢包率 2%，则未修复概率约为每组丢 2 包以上的概率，量级骤降到万分之一以下。反过来说，链路本底丢包 0.1% 时开 4 比 1 的 FEC，基本是白付 25% 的带宽——FEC 该不该开、开多大，应当跟随 3.2 节体检单的实测丢包动态调整：丢包低于阈值关掉，超过阈值按档位加码。主流实现都支持按应用组与链路质量的自适应 FEC，选型时把它当作必查项。

包复制：最暴力也最有效

对最高优先级的实时流，还有更直接的招：同一份数据包沿多条隧道各发一份，接收端去重、取先到者。单条链路丢 1% 时，两条独立链路双发的有效丢包约为两者乘积（0.01% 量级）。代价是带宽翻倍，所以只配给语音与关键控制流，且要求两条链路物理独立（同一运营商的同路由双线，相关性高，双发收益打折——3.2 节讲过的"体检单"在这里再次派上用场：先确认两条链路的丢包不相关，再开双发）。

抖动缓冲：接收端的匀速器

抖动的修复不花带宽，花时延：接收端把收到的包先放进缓冲区，按恒定节奏取出播放，波动被缓冲区吸收。核心参数是缓冲深度：太浅，波动大时缓冲被抽干（欠载，卡顿）；太深，所有包都多等一截（时延增加）。工程取法是自适应：缓冲深度跟随实测抖动动态调整，抖动 30 毫秒的链路配 60 毫秒左右的缓冲。配置骨架示意：

# 边缘设备上的纠错策略骨架（示意，各厂商语法不同）
policy voice-quality:
  match: app-group "voice-video"
  link-fec:
    mode: adaptive              # 跟随链路丢包自适应
    redundancy: auto            # 4:1 起步，丢包超3%升档
  packet-duplication:
    enabled: true               # 语音流双发
    min-links: 2                # 要求两条独立隧道
  jitter-buffer:
    target: dynamic             # 自适应缓冲
    max-depth-ms: 80            # 封顶，防止时延失控
​

这段骨架对应的验收方法：在一条人为注入 2% 丢包的链路上开语音呼叫，对比开关 FEC 的 MOS 语音质量分；再用抓包确认双发流在接收端正确去重。数字上，"2% 丢包链路开通 FEC 后 MOS 从 3.2 回到 4.0 以上"是常见的可达标尺。

补课的边界

纠错工具箱有三条边界要认清。其一，时延无解：FEC 与复制治丢包、缓冲治抖动，但物理绕路多出来的毫秒数算法抹不掉，时延问题最终仍是选路问题。其二，带宽税要记账：25% 到 66% 的冗余开销在瓶颈链路上会挤压正常流量，必须与 4.3 节的 QoS 排队联动——先保证纠错包本身的优先级，否则纠错会饿死业务。其三，TCP 流基本不受益：TCP 自带重传，FEC 对它的增益有限且干扰拥塞控制；纠错的主战场是 UDP 类实时流。

案例演练：一场跨区域语音卡顿的处置

把本节工具箱按处置顺序走一遍真实场景。某制造企业的华东-华南视频会议持续卡顿，业务投诉不断。第一步，看体检单定性：平台显示该方向两条链路——专线时延 38 毫秒丢包 0.1%（健康）、宽带时延 52 毫秒丢包 2.8%（晚高峰更差）。会议流量被策略绑定在宽带上（为了省钱），病根是宽带晚高峰丢包。第二步，对症下药：短期动作是给该应用组开启自适应 FEC（丢包 2.8% 落在 4 比 1 的适用区间），同时把会议组的选路偏好改为"专线优先"；长期动作是与宽带运营商排查晚高峰拥塞或升级接入。第三步，验证闭环：开启 FEC 后复测，MOS 从 3.1 回到 4.1；切换到专线后时延降到 38 毫秒，卡顿投诉归零。第四步，复盘入档：本次处置修正了策略模板——所有含实时会议的站点模板默认带自适应 FEC，该企业其余 40 个站点的同类隐患被批量消除。

这个案例的价值在第四步：单点故障的处置经验固化为模板策略，是 SD-WAN 集中管控对运维的实际回报——传统网络里同样的教训只会躺在工程师的个人经验里。

问题：FEC 开了没效果，可能是什么原因？

按命中率排查。原因一：丢包不是随机的——FEC 能修"组内零星丢包"，修不了"整组丢失"（比如秒级的链路闪断把整组连校验包一起吞了），后者的对策是包复制或换路。原因二：瓶颈带宽不够——25% 的冗余开销在已拥塞的链路上火上浇油，丢包反而加重，此时要先做 QoS 排队（4.3 节）再谈纠错。原因三：只开了单侧——FEC 需要收发两端协同（发送端编码、接收端解码），半边开启等于没开。三个原因覆盖了绝大多数"FEC 无效"工单。

本节要点

• 短板分三类对症下药：丢包用冗余，抖动用缓冲，时延只能靠选路与分流。
• FEC 是"提前支付的带宽"：4 比 1 修复组内单包丢失，开销 25%，本底丢包低时别开。
• 包复制只给最高优先级实时流，且要求链路物理独立、丢包低相关。
• 抖动缓冲自适应深度，封顶防时延失控；验收用 MOS 分对比说话。
• 纠错与 QoS 必须联动：先保纠错包优先级，TCP 流不是纠错的主战场。

链路层的丢包抖动有了对策，下一节转向吞吐：高时延链路上 TCP 为什么跑不满带宽，代理拆分怎么救。