很多朋友学计算机网络的时候，看到“差错控制”“检错编码”这几个字，第一反应通常是：考试会考。但真到做项目、调网络、抓包排障的时候，又发现学校里背过的那些概念全对不上号。这篇内容我会直接从“为什么要做差错控制”讲起，把奇偶校验、校验和、CRC循环冗余校验的计算过程、能力边界和实际场景一次性捋清楚。不管是准备面试、复习专业课，还是真正在用网卡抓包分析误码，这篇都能直接当参考手册用。信息是怎么丢的、编码是怎么加的、余数是怎么算的，下面都会给出一手步骤。

1. 先搞清楚一个问题：网络传输为什么会出错

1.1 信号衰减、噪声与信道误码

数据在物理层传输的时候，本质是电磁波在介质里传播。铜线上的电压、光纤里的光脉冲、无线信道里的电磁波，都会受到干扰。常见的干扰源有这么几类：线缆自身的电阻发热导致信号衰减，隔壁线路的串扰，电源设备的电磁辐射，无线场景下的多径衰落和同频干扰。信号到了接收端之后，接收电路靠采样和判决把模拟信号还原成0和1。只要噪声幅度超过判决门限，0就可能被读成1，1也可能被读成0，这就产生了单比特翻转。

还有更隐蔽的问题，连续多个比特出错，比如无线信道里的突发干扰，或者光模块受到强电磁脉冲，一下就把几百个比特全冲掉。这种错叫突发差错。很多人意识到网络传输不可靠，是某一帧数据全部校验失败、不断重传之后才有的直观感受。差错控制的根本目的就是应对这种“底层一定会出错，但上层必须看起来可靠”的矛盾。

注意：传输过程中不只可能比特反转，还可能丢失、重复、乱序。不过检错编码主要解决的是比特错误检测问题，丢包、乱序更多交给序号、计时器和确认机制处理。

1.2 差错控制的两种基本思路

差错控制大体分两类：一类是检测，一类是纠正。

检测的思路是，发送方给数据附加一些冗余码，接收方只判断数据有没有坏、坏没坏，不负责恢复原始数据。如果发现坏了，就丢掉或者要求重传。这种机制叫检错重传，也称自动重传请求（ARQ），配合确认和超时机制使用。

纠正的思路则更进一步，编码要带上足够强的冗余，让接收方不仅能发现错误，还能从残缺的数据里把原始比特推出来。这种方式叫前向纠错（FEC），常见于磁盘存储、卫星通信、深空通信这些无法方便重传的场景。日常以太网链路，重传成本很低，所以绝大多数局域网设备使用检错加重传方案就够了。

判断一个检错码好不好，核心指标是漏检率，也就是错误发生了却没被检测出来的概率。没有任何编码能做到100%检出所有错误，但好的编码能在低成本下把漏检率压到极低水平。这也是下面几种方案在工程上长期并存的原因：它们各自在简单性、开销和检错能力之间找平衡点。

2. 检错编码到底在做什么：从信息冗余说起

2.1 冗余码的基本思想

检错编码的最底层逻辑很简单：发送的数据分成两部分，一部分是原始有效载荷，另一部分是附加的校验信息。接收方收到后按照同样的规则重新计算校验信息，如果和收到的校验信息一致，就认为数据大概率没坏；如果不一致，就认定出错了。

打个比方，寄快递的时候会在箱子上贴一张包裹清单，里面写着“内含文件3份”。快递送到后，收件人打开一数，发现只有2份文件，明显就出问题了。这里的“文件数量”就是一种冗余信息。真实网络里的检错码比这个精巧得多，但基本思想没变：用额外信息来验证核心信息。代价是占用带宽。1000比特数据如果加32比特校验，有效载荷占比约96.9%，剩余的3.1%专门用来“买个放心”。

编码比拼的核心归结为一个问题：用同样长度的冗余码，哪种方案能捕捉到更多类型的错误？奇偶校验只加1比特，就能检查奇数个比特翻转。CRC循环冗余校验加16到32比特，就能可靠检测长度远小于校验位位数的所有突发错误。冗余不白给，用处都在检错能力里。

2.2 如何衡量检错能力

检错能力有一套量化指标，理解它们比背定义有用得多。

第一是汉明距离。两个等长码字的汉明距离，就是对应位置相比，二进制位不同的个数。一个编码方案的检错能力由“要检出的最少错误比特数”决定。如果你想让编码能检测出d比特错误，就需要编码的最小汉明距离达到d+1。这个数越大，抗干扰能力越强，但冗余也越多。

第二是突发错误检测长度。很多检错码对连续错误有专门的检测能力。比如传统多项式CRC能检测出所有长度不超过校验位位数的连续突发错误。这个指标在无线链路中非常重要，因为无线信道中的错误经常成串出现。

第三是漏检率。即便是优秀编码也无法检出所有错误，漏检率就是没查出来的错误占所有发生错误的比例。好的CRC多项式，配合精心选择的参数，漏检率基本在百万分之一甚至更低量级。实际工程里，以太网、Wi-Fi、USB这些链路宁愿多花几个比特做校验，也不愿让坏数据进入上层应用，就是因为漏检代价实在太高。

3. 最容易被低估的检错手段：奇偶校验

3.1 校验位怎么加

奇偶校验大概是全网最简单的检错方法。规则只有两条：发送方统计数据里“1”的个数，然后填一个校验位，让整个码字中“1”的个数成为偶数（这就是偶校验）或奇数（这就是奇校验）。接收方收到后重新统计，如果奇偶性对不上，就说明数据出错了。

举个例子。原始数据是1001011，里面一共有4个1（已经偶数），偶数校验位就填0；如果原始数据是1001010，里面只有3个1，偶数校验位的值就要填1，这样整体变成4个1。接收方收到10010101后数一遍，确实是4个1，就认为没出错。反过来，如果收到的数据出来5个1，哪怕只是因为一位从0翻到1，接收方也会立刻判定出错。

这个过程看起来没什么技术含量，但它的优点非常突出：额外开销只有1比特，硬件电路实现只需要一个异或门阵列，速度极快。所以串口通信、存储器内部总线里到现在还在用。

实操心得：串口产品中常见的“偶校验”和“标志位”是两个概念，很多人会混淆。偶校验是查数据位和校验位合起来的总个数；标志位只是在一个固定位置额外给1或0，没有任何检错能力。调试设备时看到配置项里写“无校验、偶校验、奇校验”要认真看，很多人就因为填错这一位，导致通信基本靠碰运气。

3.2 为什么叫垂直水平校验（二维校验）

单比特奇偶校验有个硬伤，它只能检出“1的个数奇偶性发生变化”的错误，也就是奇数个比特翻转。只要同时有两比特翻转，奇偶性不变，检错直接失效。真实噪声里两个比特同时出错并不罕见，尤其当两个错误正好在同一时刻不同线路出现时，单奇偶校验就跟没穿一样。

二维奇偶校验就是为了缓解这个问题。方法是一次把数据排成m行n列的矩阵，然后对每一行算一个校验位，对每一列也算一个校验位。这样本来只能查一行里奇数个错误，现在变成了行、列交叉检测。如果恰好两个比特错误，它们会同时影响自己那行和那列，接收方通过行列交叉定位，不仅能发现错误，某些情况下还能定位到出错坐标，甚至直接纠正过来。

实际工程中，二维校验在早期内存ECC、磁带存储里出现过，现在不少低速率工业总线仍然在用类似思路。它比完整CRC便宜，又比单校验可靠得多，是“花小钱办大事”的典型方案。

3.3 适用场景与能力边界

奇偶校验适合误比特率很低、且单帧数据很短的环境。比如UART串口一个字符就8到10位，加1位校验，额外开销不过10%，检测效果尚可。但在动辄几百上千字节的以太网帧面前，只加1位校验基本等于摆设，所以网络传输的主力并不是它。

它的边界大致可以总结成三类错误：偶数位翻转造成的漏检，突发错误里奇偶性恰好又配平的情况，以及多个错误叠加导致全行列奇偶性都“恰好正常”的极端情况。其中第一类最常见，也是面试里问得最多的点。

记住一个简化的判断办法：奇偶校验能“查单不查双”，也就是奇数个bit错误能查，偶数个bit错误查不出来。真正需要高可靠场景，还得靠下面要讲的CRC这类更强的方案。

4. 主力选手：CRC循环冗余校验

4.1 CRC的核心直觉

CRC循环冗余校验收发两端约定一个生成多项式G(x)，发送方把数据当作二进制多项式除以G(x)，得到的余数就是校验码，附加在数据后面发出去。接收方用同一个多项式去除完整接收的码字，如果余数为0，就判定没出错；余数不为0，就判定出错。

这里面的数学思想和普通除法很像。你要让1011除以3或者别的整数，总会有余数。这个余数是“1011这一个具体数值”留下的指纹，换一个数，余数通常就变了。CRC就是把数据看成一个大整数，用一种特殊的模2除法算余数。这个余数对原始数据极其敏感，任何一位翻动都会大幅改变除法结果，所以检错能力才会这么强。

模2除法和平常除法的区别在于：加减法全部替换成异或，不产生进位和借位。异或的规则是相同为0、不同为1，对应到除法里就是“能整除就写0，不能整除就写1，然后逐位异或对齐部分”。手算的时候对初学者最迷惑的就是这点，后面我会用完整例子一步步走一遍。

4.2 手算CRC过程详解（带例子）

我拿一个经典例子把所有步骤拆开。

假设要发送的数据M是101001，约好的生成多项式对应二进制G是1101（对应多项式x³+x²+1）。G是4位，说明校验位是3位。第一步，在原始数据后面补3个0，得到M'=101001000。为什么要补0？因为信息多项式要乘以x³，腾出位置放后面的余数。

第二步，用G=1101对M'做模2除法，逐步计算异或。我来演算一遍：

• 101001000，首先看最高的4位1010。1010除以1101，首位对齐后异或，1010异或1101得到0111，前导0去掉，剩下111，再从被除数下拉一位变成1110。
• 1110除以1101，最高位对齐，异或得到0011，去掉前导0为11，再下拉一位变成1100。
• 1100除以1101，不够除（因为首位1对齐后，1100小于1101在模2里的“小于”判断其实是看位数，只要最高位对齐但异或后会产生位数变化，本质就是不够），商写0，继续下拉一位变成11000。
• 11000除以1101，异或后得到0010，去前导0为10，再下拉一位变成100。
• 100已经不够位了，除法结束。

最终的余数是100，这个100就是CRC校验码。发送帧就是原始数据加余数：101001 100，也就是101001100，长度变成9位。

接收方接到101001100后，用G=1101再做一次异或除法，整个过程如果数据完好，最终余数一定是000。只要余数不是000，就是出错了。

注意：我在实际教别人的时候发现，最容易错的两步，一是补0位数搞错，必须等于生成多项式位数减1；二是除法过程中异或之后要正确处理前导0，该去掉的直接去掉，不要硬凑位。一旦这两点错位，后面全乱。

4.3 为什么CRC检错能力强

CRC检错能力的底气来自生成多项式的数学性质。一个K位的校验位，能保证检出所有长度不超过K的突发错误。比如CRC-16能保证检测出长度不超过16的连续翻转；对于长度超过16的突发错误，也能以极高概率检出，漏检率大约在2的负16次方量级，大约十万分之一再多打折一点。长度更短的错误几乎100%覆盖，这是奇偶校验完全做不到的。

除了突发错误，CRC还能检出所有奇数个比特翻转错误，因为标准CRC多项式都包含因子(x+1)，这个因子天然保证奇偶性检查。同时任何单个比特错误都会被检出来。跳过了“只查单不查双”的窘境，性能上了一个台阶。

需要注意一点，CRC是检错码不是纠错码。它只会告诉你数据坏了，不能告诉你坏在哪一位。在以太网链路里，FCS校验失败就直接丢弃这一帧，不尝试恢复。如果需要纠错，就得换成带纠错能力和更多冗余位的方案。所以“CRC能纠错”是个流传很广的误解，面试时经常有人在这里翻车。

4.4 实际工程中选哪个生成多项式

工程上不同协议选择不同的生成多项式，都是有讲究的。

CRC-8常见于传感器通信、SMBus这类低速场合，校验位1字节，成本最低。CRC-16在Modbus、USB部分低速协议、蓝牙低功耗里很常用，16位校验开销适中。CRC-32则几乎是数据链路层的标配，比如以太网帧尾部的FCS字段就是32位CRC，Wi-Fi MAC层也用它。

选多项式不止看长度，还看具体生成式的设计。好的多项式要同时覆盖单比特错误、双比特错误、奇数位错误和常见突发错误模式。比如0xEDB88320这个实际反映的是CRC-32的常用翻转多项式，很多查表实现里都能看到它。

我自己的习惯是：能用硬件直接算CRC的场景就不要手写软件循环位运算。很多MCU外设自带CRC计算模块，比如某核单片机里就有专用的CRC系数寄存器，配置好多项式后把数据推进去就行。省下来的CPU时间能用来处理别的任务。如果必须软件计算，优先用查表法而非逐位循环，尤其数据量大、速率高的时候，逐位循环会非常浪费时间。查表法思路是把每字节映射成一个预计算好的表项，一次处理一整个字节，速度能提升好几倍。

实操心得：网上很多CRC代码版本之间互相不兼容，核心原因在于初始值、结果异或值、输入数据是否反转这三个参数不同。不同协议对同一多项式可能定义不同配置，移植代码的时候一定要确认这三项。最稳妥的办法是用已知数据对跑一遍，输出一致再投入使用。

5. 校验和：简单场景的另一种选择

5.1 校验和的计算方式

校验和的实现思路更直白：把数据拆成若干等长片段，通常是16位或者32位一个字，把这些片段按补码算术求和，最后保存这个和的补码或截断值。接收方收到后重复同样的累加，再加上发送方附带的校验和，结果应为全1。只要有一个bit错位，累加结果大概率会变化。

比如要校验“0xC0A8, 0x0102, 0x4854”这三段，直接加起来，进位也一并回卷。回卷就是把最高位的进位再加回最低位，这是校验和算法特别容易忽略的细节。很多人第一次写校验和程序，忘记回卷这一步，导致本地计算结果跟抓包工具对不上。

实际最出名的校验和是IP头校验和和UDP校验和。IP头校验和只覆盖IP头，不覆盖载荷；UDP的校验和则把整个伪头部、UDP头和数据都算进去，伪头部里填源地址、目的地址、协议号等字段，用来防止数据被路由到错误的目标。TCP也类似，但TCP在IPv6下校验和是强制项，UDP在部分场景下允许关闭校验和，IPv4的UDP校验和甚至可以是0，表示不用校验。

5.2 CRC和校验和的区别

很多初学者分不清校验和与CRC，误以为它们干的是同一件事。两者确有相似点，都是冗余校验，但实现机制和适应岗位完全不同。

校验和的加法实现非常便宜，尤其适合在CPU上用普通加法指令加速完成，协议栈、软件层次实现方便。CRC的模2除法虽然检错能力更均衡，但是逐位计算很重，硬件化以后才真正发挥威力。所以网络分层里有个有趣分工：数据链路层帧尾常用CRC，专门保护链路一段一段的传输；传输层则常用校验和，保护端到端的完整报文。链路层帮你把每一跳的物理错误挡掉，传输层再兜底保护整个连接。

如果从检错能力上看，CRC对于突发错误的捕捉几乎无懈可击，校验和则因为累加过程可能发生多位错误互相抵消，漏检率更高。不过传输层的报文通常经过链路层之后已经相对干净，校验和在此基础上做最后一道检查，性价比是足够的。

6. 常见问题与排查技巧实录

这部分我把测试和排障中经常碰到的几个问题整理成一张速查表。结合我实际调过的一个模拟项目X，当时现象是某网卡持续收到大量坏帧，上位机统计FCS错误数不断上涨，一度怀疑是驱动bug，后来发现是配置时生成多项式选错，硬生生把CRC-32算成了CRC-16的口径。

第一类问题重点看物理层，很多所谓“丢包率上升”其实是FCS错误被驱动扔掉了。第二类问题是软硬件适配经典坑，尤其常见于自研硬件和第三方协议库对接。第三类场景要看清错误是随机单比特还是突发多比特，前者常常是阻抗不匹配，后者多半是电源噪声。

还有一个很多人不知道的技巧：抓包时如果怀疑是某一段链路出了问题，可以在交换机上把端口的光模块做环回测试。环回时数据不经过物理介质，只测设备内部收发链路。环回后再打开误码测试，如果此时错误为0，问题就在线缆或对端；如果还有错误，问题在设备自身主控或PHY芯片配置。

注意：任何检错方案都有漏检概率。不要因为CRC很强就放弃上层完整性校验。真正常见的做法是链路层CRC、传输层校验和、应用层再做完整性摘要，层层叠加才能把端到端可靠性拉满。

在实际项目中，我还有一个不算冷门但很容易被忽略的体会：很多人调试CRC只关注最后校验结果对不对，没意识到时序问题也容易导致“看起来对、偶尔对、大多数时候不对”。比如DMA搬运数据时若数据和CRC字段跨越了两个描述符边界，配置不当就会出现结果时好时坏。这类问题一旦出现，别急着改多项式，先把数据包完整性和DMA描述符链关系梳理清楚，往往比调编码参数更省时间。差错控制这块内容，说到底是“数学保障+工程落地”的结合，理解清楚底层的除法原理，再回到实际接线、驱动、抓包工具里去检验，基本就能把书面上学的知识真正长到自己身上。