UDP数据有效载荷应包含CRC吗？

对于我曾经工作过的公司，我必须实现一个套接字接收器，该接收器主要通过一些专用传感器硬件通过本地连接以UDP形式获取数据。所讨论的数据是格式正确的UDP数据包，但有趣的是，数据有效负载始终以使用其余数据形成的CRC16校验和结尾。

我按照规范在终端执行了检查，但是我一直想知道这是否有必要。毕竟，UDP协议本身不携带16位CRC吗？因此，尽管UDP数据包可能会丢失或乱序，但我给人的印象是，在到达OS进程之前，如果不被网络硬件丢弃，就无法破坏它们。还是我缺少一些特殊用例？

值得补充的是，我在国防行业工作，正如您确定的那样，我对这样的事情都非常清楚，所以我想知道这是否仅仅是“安全OCD”的案例。 ..

UDP协议不保证消息按顺序传递或全部交付，但它并确保那些消息不获取传递齐全，不变通过自动包括16位校验和。这意味着在应用层添加另一个16位校验和通常是多余的。

通常...

首先，对于IPv4（不是IPv6），校验和是可选的。这意味着您可能正在使用不执行校验和生成和验证的奇异配置（但在这种情况下，您应该修复网络堆栈，而不是在应用程序层上对此进行评审）。

其次，使用16位校验和时，完全随机的消息恰好具有有效校验和的概率为65536。当此误差幅度对于您的用例而言过大时（在国防工业中，我可以想象出它在哪里），添加另一个CRC-16校验和将进一步减少它。但是在那种情况下，您可能会考虑使用适当的消息摘要，例如SHA-256，而不是CRC-16。或者一路使用真正的加密签名。这不仅可以防止随机破坏，还可以防止攻击者的故意破坏。

第三，根据数据的来源和去向，在通过网络发送数据之前或之后，数据可能已损坏。在这种情况下，消息内部的附加校验和可能会保护消息的完整性，而不仅仅是两个网络主机之间。

UDP确实提供了校验和。

1. UDP校验和仅为16位。这意味着损坏的数据包通过校验和的概率为65536分之一。
2. 在基于IPv4的UDP中，校验和是可选的，因此，从理论上讲，发送方可以在没有校验和的情况下发送数据包。
3. 校验和涵盖IP /端口信息以及数据。虽然这在丢弃带有损坏地址的数据包时很有用，但是这意味着如果数据包通过NAT，则必须由NAT重新计算校验和。
4. 校验和仅保护数据在UDP数据包中传输时的安全。当数据通过更复杂的系统时，应用程序级校验和可以保护数据的端到端。
5. UDP校验和仅告诉您数据包是由UDP实现生成的。它不会告诉您它来自传感器。另一方面，应用程序级别的校验和可能有助于拒绝有效UDP但来自其他来源的数据包。

因此，我可以看到不信任UDP校验和但同样不信任UDP校验和，然后在应用程序级别实现类似的弱校验和的合理原因似乎很奇怪。

设计协议的人员可能根本不知道UDP提供了校验和，或者该协议实际上是设计为在不提供校验和的介质上运行的协议的细微变化。

PS，因为此帖子带有标签安全性，所以请注意，所讨论的校验和旨在防止意外更改。要防止故意的修改或欺骗，既需要使用能够抵抗故意的冲突/原像的加密哈希函数，也需要使用某些机制（例如，使用公钥进行的签名）来验证哈希自身是否已被修改。