数据链路层差错控制：CRC、FEC与ARQ的工程实战

去年调一台工业串口设备，客户报障说上位机偶尔会收到乱码，有时候一帧里还夹着几个完全错误的字节。我带着示波器蹲在现场抓信号，发现离网关不到两米的地方有台变频器，一启动，RS-485总线上的波形立刻冒出一堆毛刺，干净的0和1被搅得面目全非。那一刻我突然意识到，数据链路层的差错控制从来不是教科书里抽象的名词，而是所有通信系统能不能稳定活下去的底线。

这篇文章想聊的，就是数据链路层差错控制里最常见也最实用的三种方法：检错编码、纠错编码、ARQ自动重传请求。不管你是刚学计算机网络的学生，还是在做嵌入式、网络设备、通信协议栈的工程师，把这三种方法搞明白，回头再看以太网帧、Wi-Fi重传、5G链路，你会通透很多。按多数教材的惯例，差错控制往往拆成“检错”和“纠错”两件事，但实际工程里没人只靠一种编码活着，所以我把ARQ也放进来一起说，这才是真实网络里的组合拳。

为什么数据链路层对差错这么敏感？因为物理层的传输介质本身就不完美。铜线会受到电磁干扰，光纤会有色散和衰减，无线信号更不用说，多径衰落、遮挡、天气变化都能让比特翻转。数据链路层的职责，就是在这条不可靠的信道上，给上层提供一个尽量可靠的数据帧交付服务。

1. 为什么数据链路层必须把差错控制当成头等大事

1.1 物理信道：理想信道只是数学课本的假设

很多初学者容易产生一种错觉，觉得数据从网线里传过去，就像水管里流水一样，送什么就是什么。真做过物理层测试的人都知道，信道里的错误五花八门。双绞线靠近电机或者变频器，脉冲干扰会在一瞬间打翻好几个比特；无线环境里一束反射波和直射波叠加，可能让接收端的信号幅度跌到噪声以下，形成一连串的突发错误；甚至光纤连接器脏了、熔接点老化，也会让误码率悄悄上升。

信道里的错误大体可以分成三类：随机单比特错误、突发性成串错误、整帧丢失。随机单比特错误主要来自高斯白噪声，比如半导体器件热噪声，特点是零星分散，一次错一位。突发错误来自脉冲干扰、多径衰落、雷击等，特点是一错就错一串，几十比特甚至几百比特连着重写。整帧丢失则可能是中间设备拥塞丢弃、缓冲溢出，或者碰撞造成的帧被接收端丢弃。这三类错误对通信的影响完全不同，后面选差错控制方法时，第一个要看的就是信道错误特征。

1.2 数据链路层在协议栈里的特殊位置

数据链路层的基本功能，是把物理层送来的原始比特流组织成帧，然后解决帧同步、差错控制、流量控制和链路管理。为什么这些工作不能全部交给上层？一个关键原因是上层协议离物理层太远，检测到错误时，往往已经浪费了大量资源。

举个例子，TCP的校验和确实能发现一部分错误，但网络层IP包在传输过程中经过路由器时，TTL字段会变，校验和变化，某些伪头部数据不参与校验，这导致TCP层的检错能力并不算强。更重要的是，很多实时业务根本不用TCP，比如UDP上的音视频流、心跳包，它们不在乎重传，却非常在意“坏帧别往上堆”。如果数据链路层能把坏的帧直接拦下来，上层就不需要面对一堆被污染的无效数据。所以数据链路层的差错控制，本质上是给整个协议栈建了一道防火墙。

1.3 差错控制要解决的四个具体问题

仔细拆一下，数据链路层差错控制要管的事其实不止“检错”这么简单。第一，帧内比特错误，这是最基础的，得能发现。第二，帧丢失，发送端发出去了，接收端却什么都没收到。第三，帧重复，同一帧被复制了两份到达接收端。第四，帧失序，先发的帧反而后到。ARQ协议里的序号、确认、超时重传，很大程度就是为了对付后面这三个问题。

这里有个容易混淆的地方：很多人以为差错控制就是“加个校验字段”，其实那只是检错编码。真正的差错控制是一个闭环，检测到错误之后怎么处理、怎么反馈、怎么避免重传风暴，这些才是工程师日常面对的重头戏。

2. 检错先行：奇偶校验与CRC到底在防什么

2.1 奇偶校验：成本最低的检查员，但不是万能

要说检错编码，最简单的就是奇偶校验。规则很直白：发送方统计数据位里“1”的个数，如果是偶校验，就在校验位上填一个值，让整个序列里“1”的个数变成偶数；奇校验则反过来，让“1”的个数变成奇数。接收方收到后重新统计，对不上就说明出错。

我在很多嵌入式UART项目里见过奇偶校验。比如经典8N1串口配置，8个数据位、无校验、1个停止位，也可以配置成8E1或者8O1，就是8个数据位加1位偶校验或奇校验。它成本几乎为零，只用1个比特就能发现一部分错误。但奇偶校验的致命弱点也很清楚：只能检测奇数个比特翻转。如果一帧里正好有2个比特翻错，统计上“1”的个数又变回偶数，错误就漏过去了。用个生活类比，这就像快递箱子上写着“如果里面有奇数个鸡蛋碎了，派送员请电话通知”，结果碎了两个鸡蛋，看起来完好无损。

所以奇偶校验目前主要用在信道质量很好、误码率极低的场景，比如主板内部的短距离通信、UART调试口。对真正要跑数据的链路来说，单靠奇偶校验远远不够。

2.2 CRC：用多项式除法把整个帧变成一条“指纹”

数据链路层应用最广泛的检错编码，是循环冗余校验，也就是CRC。CRC的基本思想，是把待发送的数据看成一个二进制多项式，然后除以一个事先约定好的生成多项式，把余数作为校验字段附加在数据后面一并发送。接收端用同一个生成多项式去除收到的整个码字，如果余数为0，就认为数据大概率是对的。

这里最关键的是“模2除法”，也就是按位异或，不借位、不进位。所以CRC运算在硬件上特别适合用移位寄存器实现，这也是它能在以太网、Wi-Fi、HDLC、PPP里遍地开花的原因。补3个0，是因为生成多项式是4位，最高次幂是3，所以要留下3位余数空间。传输的数据变成原始数据加余数，接收端再做一次除法，如果能整除，说明没有检测到错误。

我放一个具体手算过程，帮助你理解它在干什么。假设原始数据是110101，生成多项式G(x)=x³+x+1，二进制就是1011。先把数据后面补3个0，变成110101000，然后用1011做模2除法，最后得到的余数是111。也就是说，实际发送的帧是110101111。接收端收到后，用1011去除110101111，如果整除，余数就是0。

实际工程里当然不用手算，但理解这个原理，能帮你明白为什么CRC的检错能力跟生成多项式强相关。一个设计良好的生成多项式，可以检测所有奇数个比特错误，还能检测所有长度不超过校验位位数的突发错误。比如CRC-16的校验位是16位，就能检测长度不超过16的突发错误；对于更长的突发错误，漏检概率也低到大约2的负16次方，约等于十万分之一点五。常见多项式的选择，直接决定了链路的检错水平。

CRC强大，但并不是万无一失。它属于检错编码，只能告诉你“这帧可能坏了”，却不能告诉你坏在哪一位。所以凡是使用CRC的协议，都必须配套一个“错误之后怎么办”的策略，要么丢弃，要么请求重传，这正好引出后面的纠错编码和ARQ。

2.3 检错编码能做的和不能做的

检错编码最大的优点是开销小、实现快、漏检率低。CRC-32算一整帧也就是几百个时钟周期的事，对吞吐率影响不大。它的本质是给帧做了一次“完整性压缩”，但代价是只能给出一个“对/错”的粗粒度结论。

有些场合，仅仅知道“错没错”还不够。比如卫星通信、深空探测，信号往返一次可能要几十秒甚至几分钟，如果每发现一个错误就重传，链路效率低到不可接受。这时候就需要纠错编码登场了。

3. 重传太贵时的另一条路：汉明码等纠错编码是怎么“猜”出正确比特的

3.1 前向纠错的逻辑：给数据加上“自愈能力”

纠错编码又叫前向纠错，英文缩写FEC。它的核心思路，是在发送数据时额外加入足够的冗余信息，让接收端在错误数量不超过一定范围时，能直接推算出正确数据，不需要再回头问发送端要一遍。简单说，检错编码是“我告诉你车坏了”，纠错编码是“我告诉你车坏了，而且我自己就能修好”。

这种机制最典型的应用场景，就是那些“重传不起”的链路。卫星通信的往返时延动辄几百毫秒，地面站和卫星之间传一帧数据，一来一回就像寄一次信，重传一次成本极高。深空探测更是如此，探测器已经飞到几亿公里外，根本不可能回头要数据。实时音视频通话也怕重传，因为语音画面讲究连续性，等不到丢包重传回来，画面早就卡顿了。

FEC的商业模式是“用带宽换时延”。同样一段数据，普通传输可能用1000个比特，经过FEC编码可能变成1300个比特、1500个比特，甚至翻倍。多出来的冗余越强，能纠回来的错误越多，但有效数据吞吐率也越低。这就像寄一个陶瓷花瓶，为了防止运输途中磕坏，你可以在包装箱里塞满泡沫，泡沫越多越安全，但箱子也越大越贵。

3.2 手算一个(7,4)汉明码：看看冗余位怎么锁定错误

纠错编码最经典的入门例子是汉明码。汉明码能在每个码字中纠正1个比特错误，同时检测2个比特错误，代价是增加若干校验位。给定m位数据位，需要的校验位r必须满足2^r ≥ m + r + 1。4位数据加3位校验，组成7位码字，就是著名的(7,4)汉明码。

我用一个具体例子来演示。假设要发送4位数据1010，约定数据位放在第3、5、6、7位，校验位放在第1、2、4位。校验位分别覆盖不同的位置组合，使用偶校验：

• p1覆盖位置1、3、5、7，计算得p1 = 1 ⊕ 0 ⊕ 0 = 1
• p2覆盖位置2、3、6、7，计算得p2 = 1 ⊕ 1 ⊕ 0 = 0
• p4覆盖位置4、5、6、7，计算得p4 = 0 ⊕ 1 ⊕ 0 = 1

这样整个码字从左到右是1 0 1 1 0 1 0，也就是1011010。现在假设传输过程中第5位发生翻转，接收端收到1011110。接收端重新计算三组偶校验，发现第1组和第3组校验失败，而第2组通过。如果把失败的小组编码按二进制拼起来，得到值5，对应的正是第5位出错。于是接收端把这1位翻回去，就完成了纠错。

这背后的原理，是汉明码通过多个校验位的交叉覆盖，让每一位错误都对应一个唯一的“校验失败模式”。出现单比特错误时，三组校验结果的二进制组合可以直接当作出错位置，非常漂亮。实际硬件实现更简单，用几个异或门加译码器就能在几十纳秒内完成纠错。

当然汉明码的局限也明显。它只能纠正1位错，如果连续2位都翻转，汉明码会把一个错误码字误纠正成另一个错误码字，所以还要加一个总校验位做扩展汉明码，变成(8,4)码，才能同时纠正1位错、检测2位错。对于突发性成串错误，汉明码的表现就更差了，因为错误一旦超过纠错能力，它不但修不回来，还可能越修越错。

3.3 从汉明码到现代纠错码：能力与代价的权衡

汉明码只是FEC的入门款。真正的工程世界里有大量更先进的纠错码：RS码在光盘、二维码、DSL里用；卷积码和维特比译码在早期无线通信里独当一面；Turbo码、LDPC码和Polar码则在现代移动通信里轮番登场。这些复杂的码在高信噪比下能逼近香农极限，用较低的冗余换来很强的纠错能力。

问题是，纠错能力从来不是白来的。编码越强，编码解码的复杂度越高，时延越大，硬件功耗也越大。这也是为什么数据链路层传统上并不广泛使用强FEC——以太网的CRC检错加TCP重传已经够用，没必要增加成本。但在Wi-Fi、5G、卫星链路这些物理层本身就不稳定的环境里，FEC反而是标配。802.11ax物理层已经支持LDPC，5G NR的数据信道用LDPC，控制信道用Polar码，物理层先做一轮FEC，再做MAC层重传，两级防护才能扛住无线信道。

4. 把检测结果变成“重发”动作：ARQ三种协议的取舍

4.1 ARQ解决的不只是“重传”本身

检错编码发现错误，纠错编码尝试自愈，但有些错误超出了纠错能力，或者信道错误太频繁，总得有最后一招：让发送端重新发一遍。这套反馈重传机制，就是自动重传请求ARQ。

ARQ绝不是“错了重发”这么简单。它需要解决四个问题：接收端怎么告诉发送端“收到了”？发送端什么时候知道“要重发”？如何区分新帧和重发帧？如果帧丢失了，发送端总不能无限等下去。所以ARQ必须包含ACK确认、NAK否定确认、超时计时器、帧序号和发送窗口这几个核心组件。一套完整的ARQ协议，等于把不可靠的点到点信道变成可靠交付的最小实现。

这里有个容易踩的误区：ARQ通常要和检错编码一起工作。接收端之所以能判断某帧坏了，依赖的是CRC检错结果。所以前面说“三种方法互为补充”，并不是一句空话，而是ARQ本身就建立在检错编码之上。

4.2 停等ARQ：一台一等的代价

停等ARQ是最简单也最直观的协议。发送端发出一帧，然后停下来等ACK。收到ACK，发下一帧；收到NAK，重发刚才那帧；如果等到超时还没收到任何确认，也重发。

为了让接收端区分“新帧”和“重复帧”，停等ARQ只需要1位序号就够了，交替使用0和1。比如发送端发序号0，如果ACK丢了，超时后它会再发一次序号0，接收端看到序号0，知道这是上次那帧的重复，于是再回一个ACK，同时丢弃重复帧，这样就避免了重复接收。

停等ARQ的最大问题，是信道利用率低得吓人。假设发送一帧需要1毫秒，而信号往返时延是10毫秒，那这1毫秒发完帧之后，发端要白白等10毫秒才能继续。链路越大，时延越长，效率越低。一颗卫星链路可能来回600毫秒，停等ARQ能把100MB的链路利用率压到不足1%。所以在数据率低、往返时延小、实现要求简单的场景，停等ARQ够用；真正高吞吐链路，必须让发送端不要停下来等。

4.3 GBN和SR：用窗口把等待时间藏起来

为了解决停等ARQ的效率问题，协议引入了滑动窗口。发送端不用等每一帧的ACK，可以连续发出多帧，然后根据ACK的情况决定窗口往前走多少。根据出错后的处理策略，分为后退N帧ARQ和选择重传ARQ。

后退N帧ARQ，也叫GBN。发送端可以连续发送窗口里的N帧，接收端只按顺序接收。一旦某帧出错，接收端会丢弃该帧以及之后收到的所有帧，同时发送NAK。发送端收到NAK后，会从出错帧开始，把之后所有帧全部重传一遍。GBN的好处是接收端实现极简单，不用缓存乱序帧；坏处是一旦出现错误，后面已经发出去的一大堆帧都白发了。如果信道误码率比较高，GBN的吞吐量会被重复重传拖垮。

选择重传ARQ，也叫SR。它和GBN最大的区别，是接收端也会开一个窗口，把出错帧后面那些正确的帧先缓存起来，只要求发送端重传出错的那一帧。等缺的帧补齐后，接收端再按顺序把所有帧交给上层。SR协议需要更复杂的序号处理、缓存管理和排序逻辑，但换来的是在误码率较高的信道上更高的吞吐效率。

三种ARQ的对比，可以从窗口和重传范围看得很清楚：

这里有个重要的数学边界：后退N帧的发送窗口最大只能是2ⁿ-1，选择重传的发送窗口和接收窗口之和不能超过2ⁿ。如果窗口开得太大，接收端会分不清新帧和重传帧。这是后面实战部分经常出问题的地方。

4.4 三种ARQ怎么选：别看教科书，看链路参数

同样叫ARQ，为什么我不能统一用选择重传？因为SR要维护接收端缓存，在硬件资源紧张的无线传感器节点上，几百KB的缓存可能根本拿不出来。反过来，如果链路误码率极低，GBN和SR的差距微乎其微，GBN的简单逻辑就是最好的选择。

选型逻辑很简单：先看误码率。信道干净、偶尔错一帧，用GBN最划算。信道差、错误频繁，SR能救回很多吞吐。再看硬件缓存。缓存够大，SR的实现复杂度可以接受；缓存紧张，只能退回GBN。最后看实时性需求。实时音视频无法忍受太多重传，通常会关闭ARQ或限制重传次数，把纠错责任更多地交给FEC。

5. 真实网络中三种方法如何联手：从以太网到Wi-Fi再到5G的工程选型

5.1 以太网：链路层只做检错，重传交给TCP

我们从小到大都接触以太网，但很多人不知道，以太网数据链路层本身并没有自动重传机制。IEEE 802.3帧尾部带一个32位的CRC-32校验字段，也就是FCS。接收端收到帧后，立刻用硬件计算CRC，如果校验失败，这一帧就直接丢弃，不通知发送端，也不重发。

为什么有线以太网敢这么干？因为铜缆和光纤信道的误码率极低，突发错误在整条链路里非常罕见。既然BER已经低到10的负12次方甚至更低，链路层再做ARQ就是画蛇添足。万一真丢了帧，上层TCP会通过超时重传补回来。这个设计思路是“把可靠性卸载给需要可靠性的人”，实时游戏或者视频流不想要重传，链路层不重传反而正好。

5.2 Wi-Fi：CRC加立即确认重传，无线链路的保底方案

无线环境就完全不一样了。802.11 Wi-Fi在MAC层使用CRC-32做帧校验，同时对单播数据帧强制要求接收端返回ACK。发送端在一个确认窗口内如果没收到ACK，就会认为帧在无线信道里丢了或坏了，进入退避流程，然后重新尝试发送，默认的数据帧重传上限通常是7次，超过之后才把这帧丢掉。

从ARQ类型看，传统802.11 DCF更接近停等思想，一次只确认一帧。后来为了提高效率，引入了Block ACK聚合确认，接收端可以一次性确认一个突发组里的多帧，如果某些帧缺失，发送端只重传缺失部分，这就带上了选择重传的味道。Wi-Fi还要面对隐藏终端、碰撞、多径信道，所以它的MAC层实际上把检错、重传、优先级控制和退避策略揉在一起，比教科书里的简化ARQ复杂得多。

5.3 卫星与移动通信：FEC和HARQ的组合拳

如果把FEC和ARQ再结合起来，就得到混合ARQ，也就是HARQ。这也是现代移动通信的核心手段。5G NR在物理层先用LDPC码做一次前向纠错，相当于把所有数据都加了一层“自愈装甲”。大多数轻微错误，接收端在物理层就直接纠正了，根本不会上报到MAC层。如果信道的噪声太严重，纠不回来，接收端才反馈一个重传请求，而且重传并不一定发送一模一样的原始帧，可以发额外的校验位，和之前收到的数据合并，让解码器有更好的机会还原数据。这种“增量冗余”机制，是混合ARQ的精髓。

卫星通信也类似。高轨卫星往返时延很大，重传代价高，所以会配置较强劲的FEC编码，把残余误码率压到非常低。ARQ只作为最后兜底，平时几乎不触发。这套思路还可以反向应用：地面网络时延很低，可以依赖ARQ多一点，FEC轻一点；无线广域覆盖时延很大，就要重FEC轻ARQ。

5.4 如果你要自己定一个链路层协议，怎么配这三种方法

我在很多项目里需要自定义一套点对点通信协议，经常会给出这样一套配置思路。先说最典型的情况，一个工业现场使用RS-485总线，传输距离几百米，波特率9600到115200，信道里可能有变频器干扰。这种场景，我会优先做两个事：帧尾加CRC-16，再在MCU里实现一个滑动窗口ARQ，窗口不用大，4到8帧就够。成本低，可靠性已经比原始电平传输高一个档次。

如果信道是无线射频模块，比如LoRa或者2400MHz数传模块，我会进一步考虑物理层是否已经有FEC。LoRa本身带有前向纠错，选中合适的编码率后，MAC层再做ARQ。两块配合起来，即使矿场、变电站这种电磁环境恶劣的地方，也能维持稳定通信。如果信道误码率很高，又要求实时性，比如遥控指令，那就把ARQ的重传次数限制到1次或2次，别让重传拖垮了指令时效。

选型时建议画一张检查表：链路层用什么检错？物理层有没有FEC？允许等待多长时间？接收端有多少缓存？这四列一列出来，答案基本就清楚了。

6. 我踩过的坑：CRC位序颠倒、计时器误调、窗口回绕

6.1 CRC实现参数不统一：同一个多项式，结果对不上

我在实际代码里踩过最隐蔽的坑，是CRC的“实现参数”不一致。我以前做Modbus设备时，Modbus规定使用CRC-16，多项式是0x8005，而且要求LSB-first，也就是按最低有效位先处理，输出还要异或0x0000。第一次我直接抄了一个MSB-first的CRC-16代码，多项式看起来没错，结果连Modbus官方的测试样例都对不上。设备跟组态软件通信，立刻就是一堆FCS错误帧。

这个问题本质是：CRC算法不光看多项式，还看初始值、输入是否反射、输出是否异或、字节位序。同一个多项式可以有CRC-16/IBM、CRC-16/CCITT-FALSE、CRC-16/MODBUS好几种变体，结果完全不同。后来我养成了一个习惯，代码里必须写自检用例，用标准测试向量"123456789"去验证。CRC-32的标准结果应该是0xCBF43926，CRC-16/MODBUS的结果是0x4B37，测试不过，先不要怀疑协议，回头查参数。

6.2 重传计时器按平均RTT设置：抖动一来就崩

有一次调试无线Mesh网络，链路层延迟忽高忽低，重传次数总是爆表。我一开始把重传计时器设成链路的平均往返时延，比如80毫秒。结果网络一抖动，回包晚到了90毫秒，发送端以为丢了，立刻重发。重发又占用信道，让原来的ACK更堵，最终形成重传风暴。

后来我把超时时间调成“平均RTT加4倍标准差”，再配合指数退避，第一次超时等100毫秒，第二次翻倍到200毫秒，第三次400毫秒，重传率立刻降下来了。链路层重传