向 UDP 数据包添加额外的校验和是否值得额外的开销？答案

【问题标题】：Is it worth additional overhead to add an extra checksum to UDP packets?向 UDP 数据包添加额外的校验和是否值得额外的开销？
【发布时间】：2011-06-09 16:53:49
【问题描述】：

我正在开发一个通过 UDP 传输加密文件的应用程序（是的；我知道 UDP 通常不用于文件传输，但这是一个边缘情况），并且想知道是否值得添加额外的开销数据包的额外校验和。我知道 UDP 数据包“不太可能”会损坏，但添加额外的校验和是否值得？

【问题讨论】：

UDP校验和不是已经是数据包的一部分了吗？ tools.ietf.org/html/rfc768
有一个小校验和（16 位），但协议不需要它。我不确定 .NET 框架是否总是与数据包一起发送校验和。
还有；我想在将其传递给我的解密库之前运行校验和验证。

标签： c# .net networking udp

【解决方案1】：

通过 UDP 加密的文件

如果您加密，那么您的加密必须包含HMAC。此外，如果您加密，您必须有一个会话密钥交换协议（通过 UDP？让我们暂时忽略它）并且您必须为每个 UDP 数据包生成一个随机 IV 并将此 IV 包含在数据包中。如果您不采取这种预防措施（每个数据包单独的 IV，添加 HMAC），那么您的加密基本上是无用的。如果您有 HMAC，则不需要校验和。

【讨论】：

我知道它已经在加密层进行了检查，但我想在它传递到该层之前对其进行检查，并尝试对其进行解密。

【解决方案2】：

UDP 已经有一个 16 位的校验和，理论上不太可能发生冲突。

您肯定想要部分校验和。如果你有一个 1TB 的文件需要一天的时间来传输，然后你得到一个哈希失败，那会让你非常难过。

懒惰的解决方案： 散列每兆字节左右？也许或多或少，眼球吧。

正确的解决方案：编写一个应用程序，使用您的 UDP 传输规范发送随机数据和散列。查看失败的百分比，（奖励：在您的应用中找到大量错误并提前修复它们）估计您应该散列的数据大小。

在这个问题上偷懒可能没什么大不了的。试想一下，你可以失去多少时间？在那段时间内，您 99% 的用例将传输多少数据？这就是你应该在中间散列多少数据。

【讨论】：

我测试了应用程序，发现损坏率相当高（尤其是在 802.11 Wireless N 网络上）。调查是值得的，现在似乎每个数据包上的校验和是理想的解决方案，因为故障似乎是随机的。

【解决方案3】：

UDP 数据包已经有一个校验和来检测损坏。我不认为添加另一个校验和可以改善任何事情。不过，您可能对Hash Trees 感兴趣。

哈希树可用于保护在计算机内部和计算机之间存储、处理和传输的任何类型的数据。目前哈希树的主要用途是确保从对等网络中的其他对等点接收到的数据块未损坏和未更改，甚至可以检查其他对等点没有撒谎和发送虚假块。

【讨论】：

【解决方案4】：

这取决于你。如果您需要非常高的可靠性，可以添加 CRC32 计算。

UDP 数据包的校验和是这样计算的：“所有 16 位字使用补码算法求和。然后对总和进行补码以产生 UDP 校验和字段的值。”

...对于现有的校验和，您似乎将获得相当高的可靠性，但并非万无一失。

【讨论】：

【解决方案5】：

可能不会，因为它们已经有了校验和。除非您真的担心 UDP 校验和无法识别的边缘情况，否则添加第二个不会有太大帮助。

【讨论】：

【解决方案6】：

我会说是的。如果我记得，IPV4 级别的校验和对于 UDP 流是可选的。 IPV6 强制要求。

【讨论】：

从内存中它们是可选的，因为应用程序可以选择禁用它们，但如果没有明确禁用它们必须启用。

【解决方案7】：

鉴于 UDP 已经进行了校验和（一个补码）并且加密算法也有某种类型的完整性检查（你没有说你使用的是什么类型的加密，但大多数已建立的加密方案都有完整性检查），我认为没有必要添加额外的校验和。话虽如此，我将指出您需要了解如何报告 UDP 和加密完整性失败。我相信校验和失败报告为 SocketException，错误代码设置为 WSANO_RECOVERY 11003。显然，如何为您的加密方案报告它取决于方案。然后，您将不得不决定如何处理它。在数据包级别捕获它允许请求再次发送该数据包，假设发送者跟踪每个数据包中的内容。这很快就会变得复杂，这就是为什么很多人最终都使用 TCP。

希望对您有所帮助。

【讨论】：