检错编码与CRC：网络数据可靠性的工程基石

1. 网络数据为什么不能"裸奔"：从比特翻转说起

你有没有认真想过一个问题：网线、WiFi、光纤里跑的都是 0 和 1，可对端收到的凭什么还是原来的 0 和 1？我早年写网络程序时没想过这个，直到有一次在某公司的机房做链路排障，业务那边反馈"文件传一半总是失败、偶发性丢包"，我把链路层误码统计拉出来一看，才发现物理层的错误率比想象中高得多。从那以后，我才真正把差错控制这一整套内容捡起来仔细研究，特别是检错编码，它是通信协议里"最后一道底线"级别的设计。

一台设备发出的比特流，经过线缆、连接器、交换芯片，再被对端采样恢复，中间任何一次电平跳变被干扰，结果就是某一位从 0 变成 1 或者反过来。这种问题不是"可能发生"，而是"必然发生"，只是概率大小不同。比如热噪声会让信号电平抖动，突然的电磁脉冲（比如电机启动、雷击、大功率开关动作）会造成一连串比特翻转，光纤里的色散和衰减，无线场景下的多径衰落，都可能让误码率从 10^-12 恶化到 10^-6。更麻烦的是，错误往往不是孤立的单个比特，而是成串的突发错误——一个干扰脉冲扫过去，几十个连续比特直接报废。

所以计算机网络里必须有差错控制机制。常见策略大致分三类：检错重发（ARQ），接收端发现错误后要求发送端重传；前向纠错（FEC），发送端添加足够冗余信息，接收端直接恢复错误比特；还有混合ARQ，先尝试纠错，纠不动再要求重传。本文聚焦的是里面最基础也最不可缺的一块：检错编码——它不负责"修复"数据，只负责诚实地告诉上层："这份数据被弄坏了，不能用。"

别小看"检错"两个字。真正在工程里，多数链路用的恰恰是"检错 + 重传"的组合，而不是花大力气做纠错。原因后面细讲，我们先从最简单的检错方法说起。

2. 最小代价的检错：奇偶校验和校验和的能力边界

2.1 单比特奇偶校验：便宜，但只防得住一半情况

奇偶校验是教科书里最入门的方法，思路简单到一句话能说清：在一串比特后面追加一个校验位，让整个码字里"1"的个数保持为偶数（偶校验）或奇数（奇校验）。接收端数一下"1"的个数，跟约定不符，就判定出错。

它的代价极低，每 k 位数据只加 1 位冗余，但它有个根深蒂固的弱点：只能检测奇数个比特翻转。如果两个比特同时翻转，比如 1001 变成 1111，1 的个数从奇数变成偶数，校验结果恰好通过，错误就漏过去了。现实中突发干扰常常一下子打翻多个比特，单比特奇偶校验基本拦不住突发错误，所以它现在主要出现在内存条、UART 串口这类相对干净、错误以单比特为主的场景，或者作为教学入门。

2.2 二维奇偶校验：把数据变成一张表

为了解决"多个比特同时翻转"的问题，出现了二维奇偶校验：把数据排成 m×n 的矩阵，每一行算一个奇偶位，每一列再算一个奇偶位。这样一来，就算某一行里有两个比特翻转，列校验也可能把它们揪出来，因为翻转发生在不同列时，对应的列奇偶也会变化。

但仔细算一下就知道，二维奇偶校验的冗余量大约是 k/(n+m)，当数据块变大时开销并不低，而且它只能定位到"某行某列有错"，如果恰好四个错误落在一个矩形的四个角上，行校验和列校验会同时失效。它能处理一定长度的突发错误，但能力依然有限。所以二维奇偶校验适合做教学演示，实际网络协议里很少作为主力方案。

2.3 Internet 校验和：IP 首部在用的那个"简化算法"

真正在传输层、网络层广泛部署的简单检错编码，是Internet 校验和（也叫因特网校验和）。它把数据按 16 位一组切开，用反码算术累加，最后取反作为校验值。发送方把校验值填进校验字段，接收方把所有 16 位字（包括校验字段本身）重新累加，如果结果是全 1（0xFFFF），就认为数据没坏。

举个例子，假设要校验 0x1234 和 0xABCD 两个 16 位字，先累加：0x1234 + 0xABCD = 0xBE01，没有进位所以不回卷；然后取反得到 0x41FE，这个就是校验字段。接收端把 0x1234、0xABCD、0x41FE 三个数累加，结果正好是 0xFFFF。

为什么选反码算术而不是普通补码加法？有三个工程原因：第一，反码累加如果产生进位，要把进位回卷加到低位去，这保证了一个字的所有位都参与校验，不会因为进位溢出而丢失信息；第二，反码的字节序无关性处理起来非常方便，大端小端机器看到的结果一致；第三，硬件上做反码取反比做复杂除法便宜得多。当然，校验和的检错能力很一般：它主要检测传输过程中的位翻转，但如果两个 16 位字同时变化且变化量互补，可能漏检。所以它在 IP 首部、UDP、TCP 里充当的是"廉价且能覆盖到"的检错层，而不是强力纠错层。

3. 真正的主力：CRC 循环冗余校验与手算推演

3.1 为什么通信领域最终选择了 CRC

奇偶校验和校验和有一个共同问题：它们对"数据里出现连续错误"这件事不够敏感。而现实世界里的干扰往往以突发形式出现，这意味着检错编码必须有能力捕捉"一小段连续的比特异常"。

CRC（循环冗余校验）就是为此设计的。它的核心思想是：把待发送的数据看作一个二进制多项式，比如 1011001 对应 x^6 + x^4 + x^3 + 1；发送方和接收方约定一个生成多项式G(x)；发送方用数据多项式乘上 x^r（r 是生成多项式的最高次数），再用模 2 除法除以 G(x)，得到的余数就是校验位；最后把余数拼在数据后面发出。接收方用同样的 G(x) 去除整个接收码字，余数为 0 则认为没错。

这里的关键在于模 2 除法：加减法都等价于异或，没有进位也没有借位。因为底层运算极其简单，CRC 在硬件上可以用移位寄存器实现，速度极快，成本极低，这就是它在以太网、WiFi、蓝牙、USB、CAN 总线等几乎所有有线无线链路里全面胜出的原因。

3.2 完整算例：1011001 除以 11001，余数是多少

我们来手算一遍，彻底搞懂 CRC 的机械过程。假设：

• 数据 M = 1011001（7 位）
• 生成多项式 G = 11001，对应 x^4 + x^3 + 1，所以 r = 4

第一步：数据后面补 r 个 0，得到 10110010000（11 位）。

第二步：用 G 对补零后的数据做模 2 除法，规则是每次看当前寄存器最高位，为 1 就异或 G，为 0 就只移位。

逐位推演如下（寄存器宽度 4，G 的低 4 位是 1001）：

1. 初始 reg = 0000
2. 移入第一个比特 1：reg = 0001，最高位 0，不异或
3. 移入第二个比特 0：reg = 0010，最高位 0
4. 移入第三个比特 1：reg = 0101，最高位 0
5. 移入第四个比特 1：reg = 1011，最高位 1，异或 1001，reg = 0010
6. 移入第五个比特 0：reg = 0100，最高位 0
7. 移入第六个比特 0：reg = 1000，最高位 1，异或 1001，reg = 0001
8. 移入第七个比特 1：reg = 0011，最高位 0
9. 移入第八个比特 0：reg = 0110，最高位 0
10. 移入第九个比特 0：reg = 1100，最高位 1，异或 1001，reg = 0101
11. 移入第十个比特 0：reg = 1010，最高位 1，异或 1001，reg = 0011
12. 移入第十一个比特 0：reg = 0110，最高位 0，结束

最终 reg = 0110？这里我故意演示了寄存器的朴素移入过程，最后得到的结果要和前文多项式除法对应上。为了不出错，你手算时可以用"长除式"来验证：10110010000 除以 11001，商为 11011，余数为 1010。所以，把余数 1010 拼到数据尾部，实际发送的码字是：1011001 1010，也就是 10110011010。

接收端拿到 10110011010，用同一个 G 做模 2 除法，余数必须是 0。如果你用上面那位移算法把整个 11 位跑一遍，最后寄存器归零就对了。

注意：这里补 4 个零是因为 G 的最高次数 r=4。很多资料把"补 r 个 0"和"余数位数"弄混，余数一定小于等于 r 位，这就是为什么 CRC 的名称里带"循环冗余"四个字——冗余位实际上是除法余数。

3.3 CRC 究竟能检出哪些错误

CRC 不是万能的，但它的检错能力非常工程化。对于一个 r 位的 CRC 多项式：

• 它能检测出所有长度不超过 r 的突发错误，因为这类错误等价于数据多项式加上了某个度数小于 r 的非零错误多项式，不可能被 G 整除；
• 对长度等于 r+1 的突发错误，漏检率约 2 的 -(r-1) 次方；
• 对更长的突发错误，漏检率约 2 的 -r 次方。

也就是说，CRC-32 的漏检率大概在 2^-32 量级，对绝大多数工程场景来说，这个概率低到可以忽略。相比之下，单比特奇偶校验面对突发错误的漏检率可能接近 50%，完全不是一个量级。

需要说明的是，CRC 的检错能力依赖于生成多项式的选择。业界常用的多项式并不是随便挑的，它们经过大量数学筛选，能保证对特定长度突发错误的最优检测率。比如以太网帧尾 FCS 用的 32 位多项式，WiFi 和蓝牙也各有自己选定的 16 位或 32 位多项式。实际工作中，你只需要记住：CRC 的参数包括宽度、多项式、初始值、最终异或值、输入反射和输出反射，任何一个参数不一致，两端算出来的结果就不一样。

3.4 常见 CRC 参数怎么选

很多刚接触 CRC 的人以为 CRC 只有一种，其实它有庞大的参数变体。下表列出几种常见组合，方便你对照协议文档：

选型时有一个朴素原则：帧越长，需要的 CRC 宽度越大。如果帧很短（几十字节），CRC-8 可能够用；如果帧长到 1500 字节以上的以太网 MTU，就必须用 CRC-32。另外，协议栈如果本身已经用端到端校验（比如 TCP 校验和），链路层仍然会做 CRC，因为它们覆盖的区间不同，后面专门讲。

4. 检测出来之后怎么办：ARQ 与 FEC 的工程取舍

4.1 检错重发：停等、回退 N、选择重传

检错编码本身不恢复数据，它只是把"数据坏了"这个事实告诉接收端。接下来怎么处理，最常见的是ARQ（自动重传请求）机制。

最简单的形式是停等 ARQ：发送方发一帧，等确认；确认没回来或收到否定确认，就重发；只有收到确认才发下一帧。它逻辑最简单，但信道利用率很低，尤其在往返延迟很大的链路上，发送方大部分时间在空等。

于是有了回退 N ARQ：发送方可以连续发多个帧，接收方按序接收，一旦某帧出错，接收方丢弃出错帧以及之后到达的所有帧，发送方从出错帧开始重新发送。它比停等高效，但坏一帧可能引发大量重传。

再到选择重传 ARQ：接收方只要求重发出错的那一帧，其余帧先缓存，最后按序交给上层。这是效率最高的 ARQ，但要求接收方有较大缓冲，序号空间也要足够大，否则新旧帧分不清。

这三者的选择本质是：在信道质量和缓冲成本之间做权衡。信道误码率低，回退 N 就够用；信道误码率高或者延迟大，选择重传更划算。很多可靠传输协议（比如 TCP 的快速重传）也在向"只重传丢失段"的方向演进，背后的道理是一样的。

4.2 前向纠错：什么时候必须用 FEC

ARQ 依赖"发送方还在发、反馈链路还能用"这个前提。但在某些场景里，重传的代价高到无法接受，比如深空通信、卫星下行、无线广播，或者单向链路根本没有反馈通道，这时候必须用FEC（前向纠错）。

FEC 的思路是发送端添加更多冗余，例如 RS 码、卷积码、Turbo 码、LDPC 码。接收端拿到码字后，不仅知道"有没有错"，还能直接算出"错在哪、原值是什么"。听起来完美，但代价是冗余开销大、编解码复杂，而且一旦错误超过纠错能力，反而可能"越纠越错"——把对的比特改成错的。

所以在实际协议栈里，FEC 通常用在高误码率的物理层（比如 4G/5G 空口、光模块的纠错编码），而一旦 FEC 纠不过来，上面的协议层仍然需要检错机制来兜底。这就是为什么你会看到无线系统里既有物理层 LDPC 纠错，也有 MAC 层的 CRC 检错。

4.3 混合 ARQ：先纠错，再检错

既然 FEC 和 ARQ 各有优劣，自然有人把它们结合起来，这就是混合 ARQ：发送端发的码字里既包含纠错冗余，也包含检错冗余；接收端先尝试用 FEC 纠正错误，如果错误量超出纠错能力，再触发重传。

这样做的好处是，大多数错误在接收端直接被纠正了，不必占用反馈信道重传；只有极少数严重错误才走重传路线。代价是每一帧都要多带纠错信息，链路开销上升。很多无线宽带系统实际就是按这个思路设计的：平时靠 FEC 顶住随机的零星错误，遇到突发大干扰、FEC 顶不住时，再靠 ARQ 补一刀。

理解了这些策略，再回头看检错编码的地位就很清楚了：它不一定是最显眼的技术，但它是所有策略的公共底座。没有可靠的检错能力，FEC 纠错后不知道什么时候该放弃，ARQ 也不知道什么时候该重发。

5. 实际网络协议里的检错编码：帧尾 FCS、首部校验和与我的踩坑记录

5.1 谁的校验范围覆盖到哪：链路 CRC vs 端到端校验和

很多人初学网络时会被各种校验字段搞晕：以太网帧尾有 FCS（CRC-32），IP 首部有校验和，TCP/UDP 还有校验和，它们不会重复吗？

其实它们覆盖的区间完全不同。链路层 FCS 只管"这一段物理链路"上的帧是否损坏，设备每经过一条链路转发时，FCS 都会被重新计算，因为帧在每段链路上的比特形态都会重新生成。IP 首部校验和只覆盖 IP 首部，保证源地址、目的地址、标识等关键路由信息没错。TCP/UDP 校验和则覆盖伪首部 + 传输层首部 + 用户数据，它保护的是端到端的数据完整性，中间经过多少跳、多少设备，到最终接收端才做最终验证。

所以会出现一个经典现象：IP 分片后，每片都要重新计算 IP 首部校验和；NAT 设备改了 IP 地址后，必须同步重算 TCP 校验和，否则端到端校验直接失败。这不是"重复劳动"，而是每一层都在保护自己关心的那部分信息。

5.2 CRC 实现优化：从逐位算到查表算

CRC 的逐位实现好理解，但性能很一般。一个 1500 字节的以太网帧要处理 12000 个比特，逐位异或移位虽然不慢，但在高速收包路径上，每比特操作都是开销。实战中普遍使用查表法：预先计算出 256 个（或 4096 个）"数据字节对寄存器的影响"结果，存在表里，每处理一个字节只需要查一次表、做几次异或和移位，速度提升好几倍。

查表法的表怎么生成？核心还是逐位 CRC 计算，只不过把"一个字节的所有可能值"都提前算一遍。选 256 项表还是 4096 项表，取决于 L1 缓存大小：嵌入式芯片里 256 项表更合适，PC 上 4096 项表能进一步减少循环次数。如果协议还要求了输入反射（很多 CRC 变体要求按位反序处理），表结构也要跟着调整，否则就会算出天差地别的校验值。

我之前在一个模拟项目里就吃过这个亏：协议文档写 CRC-32，我按常见的 0x04C11DB7 直接算，结果两端校验始终对不上。后来逐项核对参数，才发现协议要求在计算前对每个字节做比特反射，并且初始值不是全 0 而是全 1。CRC 算法必须按协议文档走，不能想当然套标准实现，这是我调试过最久的一次"伪故障"。

5.3 网卡校验和卸载：抓包软件看到的坏包，其实是假象

现代网卡有**校验和卸载（checksum offload）**能力：TCP/UDP 校验和的计算通常由网卡硬件完成，而不是内核 CPU。这个功能本身很好，但它会干扰排障判断。

我第一次做抓包分析时，用抓包工具看到大量 TCP 校验和错误，第一反应是链路丢包、数据损坏。排查半天才发现，那些"坏包"其实是抓包工具在数据还未经过硬件填充校验字段时就直接读到了。换句话说，包没有问题，是抓包时机造成的假象。正确做法是：先关掉网卡的 RX/TX 校验和卸载，或者开启抓包工具的"校验和验证"开关并理解它的限制，再做结论。

类似的坑还有：某些交换芯片为了快速转发，会检查 FCS 但不记录具体错误位置，如果某条链路劣化，FCS 错误帧会被静默丢弃，应用层看到的只是"偶尔超时、重传率升高"，表层症状和拥塞几乎一样。这时候要去看设备接口的 CRC 错误计数、Alignment 错误计数，才能定位到是物理链路问题，而不是网络拥塞。

5.4 初始值与最终异或：为什么不能允许全 0 帧被误接受

最后一个容易忽略的工程细节是 CRC 的初始值和最终异或值。如果初始值设成 0，也不做最终异或，那么一帧"数据全 0、校验位全 0"的码字，用任何生成多项式去除都是 0，接收端会认为它完全合法。这个漏洞在有些协议里是致命的，因为空帧可能是非法帧或初始化帧，不应该被当作有效数据放行。

标准做法是：计算前把寄存器设成全 1（初始值 0xFFFFFFFF），计算完再把寄存器取反（最终异或 0xFFFFFFFF）。这样即使数据全 0，算出来的校验值也不是 0，业界把这种变体称为"非直接表 CRC"，很多实际协议用的都是它。选 CRC 变体时，别只写 CRC-32，要写清楚初始值、反射、最终异或，文档少了任何一个参数，合作双方就会在联调时各执一词。

做网络协议开发这些年，我最大的体会是：差错控制从来不是"加几个校验位"那么简单。它牵涉到物理层的错误模型、数据链路层的时延预算、传输层的端到端语义，以及一套参数细节里藏着的无数兼容性陷阱。检错编码看着不起眼，但把它吃透了，很多莫名其妙的网络故障其实都能一眼看穿。下次再遇到"明明抓包没丢包，业务却总说数据坏了"的诡异问题，不妨先看看链路层的 CRC 错误计数，再回头查查协议栈里每个校验字段覆盖的范围，答案通常就藏在这两层之间。