networking - 自定义协议(protocol)的应用程序数据是否需要校验和？

Question

由于通过网络传输的数据包在不同层上具有校验和，以太网和 IPv4 的 header 具有校验和，TCP 的校验和甚至覆盖整个段。

我知道从应用层的角度来看，损坏的数据包可以溜进来而不被以太网/IP/TCP丢弃，这并非不可能，因为它们的校验和有可能是正确的，只是概率很低。

我正在为 IM 应用程序设计自定义二进制协议(protocol)。我的问题是我是否需要添加校验和以确保我的应用程序数据的完整性？真的需要校验和吗在实践中 ?

Answer 1

有关于这个主题的实际研究。它很旧，但与手头的问题非常相关。

这篇 2000 年的论文被 Jonathan Stone 和 Craig Partridge 称为“当 CRC 和 TCP 校验和不一致时”，他们调查数据包和帧错误，并查看 TCP 校验和错误的频率，但以太网 CRC 很好。您可以找到 PDF here .这是重要的部分。

从摘要:

Traces of Internet packets from the past two years show that between 1 packet in 1,100 and 1 packet in 32,000 fails the TCP checksum, even on links where link-level CRCs should catch all but 1 in 4 billion errors.

从结论(我的一些突出显示)

In practice, the checksum is being asked to detect an error every few thousand packets. After eliminating those errors that the checksum always catches, the data suggests that, on average, between one packet in 10 billion and one packet in a few millions will have an error that goes undetected. The exact range depends on the type of data transferred and the path being traversed. While these odds seem large, they do not encourage complacency. In every trace, one or two 'bad apple' hosts or paths are responsible for a huge proportion of the errors. For applications which stumble across one of the `bad-apple' hosts, the expected time until a corrupted data is accepted could be as low as a few minutes. When compared to undetected error rates for local I/O (e.g., disk drives), these rates are disturbing. Our conclusion is that vital applications should strongly consider augmenting the TCP checksum with an application sum.

我不知道对这个问题有任何新的研究(如果你知道的话，请启发我!)，所以从那时起，互联网可能变得更加可靠，论文中的数字可能无关紧要。

然而，这很重要，17 年过去了，自从那篇论文发表以来，互联网流量简直爆炸式增长。在 1Gbps 时，这在当今并不常见的连接速度，您正在发送大约 81K 完整的 TCP 段，其中包含 1460 字节的数据， 每秒 (如果数据包更小，则更多)。每 12.5 秒有一百万个大数据包，大约 3.5 小时内有十亿个(或者如果数据包很小，则更多)。

所以回答你的问题 - 这取决于。
对于传输大文件或其他数据，如果数据本身没有受到任何保护，我肯定会添加额外的检查。对于将非常少的数据推送到网络的消息传递，您可能会使用 TCP 的校验和，可能会对您要获得的输入进行一些健全性检查以确保其格式正确，并且各种参数和字段使感觉。