摘要

  • RFC 3385 把“32 位校验和”拆成一个不完整说法：未检测错误概率还取决于生成多项式、受保护块长、错误分布和真实数据的偏差。
  • 作者在明确的意外损坏模型下认为 CRC32C 适合作为 iSCSI 的基本错误检测机制，但没有把它写成密码学完整性或普遍概率保证。

假设一块存储数据后面都带四个字节。抓包工具显示的字段宽度相同，数值也同样像随机串。紧密成簇的比特错误穿过其中一种校验，却被另一种捕获。可见外壳都是 32 位，内部形成的检测空间却不一样。RFC 3385 的工作，就是让这个常被位宽掩盖的差异变得可计算。

这份文件于 2002 年 9 月以 Informational RFC 发布，目标是估算未检测错误概率，帮助 iSCSI 选择错误检测码。它不是完整 iSCSI 协议，也没有证明某项产品实现或现场采用。它是一份选择前的分析：在“32 位完整性”成为令人安心的口号以前，先要求人们说明这 32 位究竟防什么。

iSCSI 把 SCSI 命令和存储数据搬到 IP 网络上。普通网络负载中的一次隐藏损坏已经危险；存储路径中的隐藏损坏还可能以看似有效的内容进入设备或文件系统。数据量也把极小概率累积成运营问题。RFC 3385 讨论 PB 级传输，并把至少保护到 8 KiB 块长作为实用目标。

更早的 iSCSI 需求文件 RFC 3347 说明了为什么不能把 TCP 校验和当作全部答案。研究已经表明，一些比特错误可能逃过 TCP 校验。代理或网关还可能终止 TCP 流、拆除并重建 iSCSI 头部，然后重新计算 TCP 校验和。要保护 SCSI 数据、命令和状态，iSCSI 自己需要清楚的摘要边界。

RFC 3385 没有把错误看作同一种随机噪声。它分别分析嘈杂信道上的突发错误，以及低噪声信道上的独立单比特错误。内存故障、串行内部互连甚至软件处理错误也可能形成成簇损坏。重要的不只是“错了多少位”，还包括这些位怎样聚集、持续多久、落在多长的数据块中。

CRC 使用生成多项式为信息块计算冗余位。接收方重新计算并比较；错误数据只有在错误模式本身也符合码字结构时才会漏检。因此，最小距离和权重分布决定哪些模式一定被抓住，哪些仍可能隐形。“32 位”只说明冗余量，不说明码的几何结构。

缩短码让这一差异更突出。实际协议使用的块长远小于某些理论码长。即使生成多项式次数相同，缩短到实际长度后，最小距离和未检测概率也可能不同。RFC 3385 引用的研究中，某些 32 位多项式对特定突发条件的表现相差数个数量级。只按位宽分类，恰好会把这种关键差异抹掉。

熟悉的 IEEE 802 CRC 与 CRC32C 都是 32 位 CRC，但多项式不同。CRC32C 使用 0x11EDC6F41。这个十六进制值不是实现附注，它决定哪些误差多项式可被整除，也就改变特定长度范围内的最小距离与漏检面。

文件给出的概率全部有条件。作者假设突发错误率、独立比特错误率和突发持续时间分布，再把固定时间的突发换算成在某一速率下受影响的比特数，并针对 8 KiB 保护单元计算。换掉信道、块长、数据分布或错误分布，结论的边界也会移动。

有些估算值小到像宇宙尺度，最容易被脱离语境传播。在 RFC 声明的模型下，CRC32C 的未检测突发错误上界极低。这不是所有网络的现场测量，也不是部署承诺。正确表述应是“在这些假设下，该码得到这个界”，而不是“CRC32C 在任何环境中都几乎绝不失手”。

与 Fletcher 和 Adler 校验和的比较给出第二个教训。在所分析的独立错误条件下，RFC 估算 CRC 的表现约比 Fletcher 好 12,000 倍、比 Adler 好 22,000 倍。它还展示加法校验可能漏掉的短连续字节模式。真实数据并不均匀，热点与偏差会使校验和变得更弱，而 CRC 的敏感性分布不同。

总结表把同宽不同义摆在一起：Fletcher32、Adler32、IEEE-802 CRC 和 CRC32C 都使用 32 位，却拥有不同的最小距离范围与模型化漏检概率。作者据此认为，CRC32C 兼顾保护水平、对有偏数据的相对不敏感以及长块保护能力，是 iSCSI 的良好基本选择。

实现成本没有被隐藏。文档引用综合工具比较候选多项式所需 XOR 门和优化后单元。CRC32C 在该设置下比 CCITT-CRC32 占用更多硬件，但 CRC 电路仍不到一个代表性小型百万单元芯片的百分之一。证据不是“成本为零”，而是“额外成本在整体预算中处于何种比例”。

软硬件路径同样需要精确定义。文件给出串行与 32 位并行硬件实现，并说明软件通常通过输入数据和当前状态索引查表。仅仅同意使用某个多项式仍不够；比特顺序、初始值、补码处理、填充和余数映射必须一致，否则两个都自称 CRC32C 的实现也可能互不相通。

CRC 的线性允许增量更新。中间节点若修改受保护头部，可以用已知差值调整 CRC，而无需重新读取并计算全部数据。最终目标仍可对组合后的头部、数据和 CRC 检查，从而覆盖多跳路径中引入的意外变化。这是一种效率和覆盖属性，不是把中间节点变成可信主体的认证机制。

后来的合并版 iSCSI 规范 RFC 7143 把运行合同写得更具体。HeaderDigest 和 DataDigest 默认值都是 None，但每个发起方与目标方必须实现 CRC32C 和 None。双方协商摘要以后，完整功能阶段的 PDU 必须使用它。规范明确称其为非密码学数据完整性检查，并让它覆盖会修改网络层 PDU 的路由器、交换机与代理等路径元素。

这条合同也产生多个不能混为一谈的事实：实现支持 CRC32C；会话提出 CRC32C；对端选中 CRC32C；某个 PDU 验证通过；保护在 iSCSI 边界后仍连续存在。前四项都不能自动证明第五项，也不能证明每条连接都启用了摘要。

安全边界写得毫不含糊。能修改数据的攻击者也能为修改后的数据重新计算错误检测码。CRC 检测意外变化，不认证发送者、不绑定授权，也不阻止恶意篡改。一次校验通过，只是针对某些意外错误模式的证据，绝不是针对主动攻击者的证据。

RFC 3309 以及后来的 RFC 4960、RFC 9260 也在 SCTP 中使用 CRC32C。这条时间线说明一个经过研究的码可跨协议复用，却不能证明每个协议拥有相同错误模型。包长、覆盖字段、下层传输、恢复规则和风险后果不同，证据含义就不同。

更早的 Internet 校验文档也显示“校验和”不是单一保证。RFC 1071 讨论 Internet 校验和的高效计算；RFC 1141 与 RFC 1624 讨论增量更新，其中后者还修正前者公式的问题；RFC 2151 为 UDP 描述 Fletcher 替代校验；RFC 1950 在 zlib 中使用 Adler-32。它们服务于不同边界，不能只按位数互换。

RFC 3385 最后把视线放回系统。固定持续时间的突发，在信道速度上升时会覆盖更多比特。高层 CRC 可以改进它所覆盖单元的检测，但无法单独保证长期风险不变。下层更好的编码和更低的错误率仍属于同一个控制面。

Lu Heng 的“最小初始规范”视角解释了为何协议必须固定多项式和计算步骤，同时允许实现选择软硬件优化。共享决定必须局部化在生成多项式、位映射与协商覆盖范围上；只有这些含义稳定以后，未来实现才可以自由优化而不破坏互操作。

“现实层”视角则把字段存在、算法受支持、会话协商成功、PDU 被覆盖、数值验证通过、在某错误模型下排除意外损坏、建立对抗性完整性分成七个事实。“它有 32 位校验和”把七层压成一个符号，却几乎没有证明其中任何一层。

RFC 3385 的历史贡献不只是推荐 CRC32C。它示范了怎样把完整性口号改写成有边界的证据陈述。位数只是可见外壳；多项式、数据块、工作负载、路径和威胁模型共同决定外壳能诚实地意味着什么。

来源