关于CRC基础的几个问题答案

【问题标题】：A few questions about CRC basics关于CRC基础的几个问题
【发布时间】：2016-10-19 20:55:33
【问题描述】：

我是一名电子工程师，我发现从纯数学角度考虑 CRC 并不重要。但是，我有以下问题：

为什么我们在计算 CRC 时要在消息中添加 n 个零，如果 n 是生成多项式的次数？我在模2长除法以及CRC的硬件实现中看到了这一点
为什么我们希望生成多项式能被 (x+1) 整除？
为什么我们希望生成多项式不能被 x 整除？

【问题讨论】：

标签： checksum modulo crc polynomials

【解决方案1】：

我们在计算 n 位 CRC 时添加 n 零，因为在将 CRC 附加到消息并发送整体时（电信中的常见做法）：
- 这允许接收端处理 CRC 的位，就像消息的其余部分一样，从而为任何无差错传输产生已知的剩余部分。当消息的结尾由遵循 CRC（一种常见做法）的东西指示时，这尤其有用；在接收端，它保存了一个n 位缓冲区，而在发送端，它几乎没有增加复杂性（x(n) 的额外项减少为一个与门，在 CRC 传输期间将消息位强制为零，n在传输 CRC 时执行额外的缩减步骤）。
  在数学上，发送的 CRC 是 (M(x) * x^n) mod P(x) = R(x)（可能在某个常数范围内，或者/或者在 M(x) 的开头添加了一些规定的位，对应于 CRC 寄存器的初始化），并且在接收端计算 CRC是M(x) 和R(x) 的串联，即
  (M(x) * x^n + R(x)) mod P(x)，它为零（或称常数）。
- 它确保影响消息结尾和连续 CRC 的错误突发从多项式选择所提供的完整保护级别中受益。特别是，如果我们将C(x) 计算为M(x) mod P(x)，则翻转M(x) 的最后一位和C(x) 的最后一位将不会被检测到，而大多数用于错误检测的多项式确保检测到任何两位错误最大邮件大小。
通常的做法是让用于错误检测的 CRC 多项式可以被x+1 整除，因为这样可以确保检测到任何影响奇数位的错误。然而，这种做法并不普遍，它有时会阻止为更好的一些有用定义选择更好的多项式，包括最大化消息的长度，以便始终检测到 m 错误（假设没有同步丢失），对于某些组合m 和 n。特别是，如果我们希望能够检测到可能的最长消息的任何 2 位错误（这将是 2ⁿ-1 位，包括 n-bit CRC），我们需要多项式是原始的，因此不可约，因此（对于n>1）不能被x+1整除。
普遍的做法是让用于错误检测的 CRC 多项式不能被 x 整除，否则生成的最后一位 CRC 将是恒定的，并且无助于检测消息其余部分中的错误+CRC .

【讨论】：

很好的答案。 +1。我只想补充一点，添加 n 零是 CRC 定义的一部分，但几乎从来不是实现的一部分。可以并且几乎总是实施软件或硬件中的 CRC 以避免那些额外的 n 步骤。对于 3，我会说它是真正通用的。如果多项式没有 1 项，则不是 CRC。
@Mark Adler：合并了您的 cmets。我猜你就是来自 Adler-32 的 Mark Adler，值得称赞！
hmmmm 我需要更多地考虑答案 2。顺便说一下，2 中的“它防止多项式不可约”是什么意思。为什么我们需要不可约多项式？
@quantum231：修正了我关于 2 的论点，这在某些时候使用不可约多项式的理由是不正确的。我现在至少给出一个很好的理由：这样多项式就可以是原始的，从而最大化检测到所有 2 位错误的消息长度。