摘要

  • RFC 768 严格区分两种“零”：计算结果为零时发送全一，而字段全零表示发送方根本没有生成校验和。
  • 局域网里的效率捷径造成了未被发现的错误；IPv6 又取消了 IP 首部校验和，因此把 UDP 校验恢复为默认义务。
  • RFC 6935/6936 的隧道例外必须按端口、按端点启用，并附带完整性、路径验证、状态保护和安全责任。

这个字段可以拒绝作证

UDP 首部只有八个字节，校验范围却不只负载。RFC 768 还把源地址、目的地址、协议号和 UDP 长度组成伪首部纳入计算。这样既能发现比特损坏，也能帮助识别数据报被送往错误端点。

反码运算本身可能得到零。规范要求把这种合法结果写成全一。只有发送字段全零，才表示“没有校验和”。因此，零从来不是质量标记；它是证据缺席的声明。

私人节省制造了共同盲区

RFC 1122 允许应用控制是否生成校验和，但要求默认开启。它还明确记载：一些只在局域网运行的应用为了效率关闭校验后，出现了许多未被发现的错误。

发送方节省一次计算，接收方、应用和运营者却失去一次独立拒绝损坏或误投数据的机会。这说明技术上能够省略，不等于发送方拥有替未知路径和未知接收者放弃证据的授权。

IPv6 恢复最低共同判决

IPv4 只校验自己的首部，不保护 UDP 负载。IPv6 则连互联网层首部校验和也取消了。RFC 2460 因而要求 IPv6 上的 UDP 必须生成校验和，并让接收方丢弃校验字段为零的数据报。伪首部对地址和投递上下文的保护变得更重要。

现行 RFC 8200 保留这一默认规则：发送方计算校验，计算为零时写 FFFF；接收方丢弃零校验数据报，并应记录错误。

十六位校验和不是身份认证。它解决的是另一件事：发送方不能仅凭自己的效率偏好，让最小投递证据从共享路径中消失。

UDP-Lite 明示暴露区间

有些音视频应用宁愿收到局部损坏的负载，也不愿整包丢失。RFC 3828 设计 UDP-Lite，让应用声明部分校验范围，但 UDP-Lite 首部与 IP 伪首部始终受保护，而且发送的校验和不得全零。

受保护与不受保护的区域因此是可见的。接收应用主动接受，并能设定自己的最低覆盖范围。这不是假装风险不存在，而是把风险边界交还给真正参与关系的双方。

隧道例外指出责任主体

高速隧道端点封装本来已有校验保护的内层分组时，读取整段外层负载可能代价很高。RFC 6935 在受限情形下允许 IPv6 UDP 零校验，主要针对隧道；RFC 6936 则列出这项例外的制度条件。

默认仍然关闭。发送与接收端必须选择具体端口；允许零的接收端也必须接受正常计算的校验和。协议还要优先评估普通 UDP 或 UDP-Lite，保护控制信息与协议状态，处理分片和误投风险，探测会丢弃零校验包的中间设备，并防止注入和过载。

权限由此改变了位置。例外属于一个已知的隧道关系：端点和运营者能够配置、观察并撤回它。它不是任何发送方向公共互联网携带的一张空白许可。

来源与证据边界

这段历史来自 RFC 768、RFC 1122、RFC 2460、RFC 3828、RFC 6935、RFC 6936、RFC 8085 与 RFC 8200。这些文件证明规范要求和已记录的风险，不证明所有实现行为一致，也不提供全球错误率。校验和只检测一部分意外损坏，不是密码学认证。