TCP 校验和是否无法检测到错误?如果是，如何处理? [英] Can a TCP checksum fail to detect an error? If yes, how is this dealt with?

问题描述

如果 TCP 负载在传输过程中损坏，重新计算的校验和将与传输的校验和不匹配.太好了，到目前为止一切都很好.

If a TCP payload gets corrupted in transit the recomputed checksum won't match the transmitted checksum. Great, all fine so far.

如果 TCP 校验和在传输过程中损坏，重新计算的校验和将与现在损坏的校验和不匹配.太好了，到目前为止一切都很好.

If a TCP checksum gets corrupted in transit the recomputed checksum won't match the now corrupted checksum. Great, all fine so far.

当有效负载和校验和都被破坏并且重新计算的校验和虽然与它应该的不同，但恰好与现在损坏的校验和匹配时会发生什么?

What happens when both the payload and checksum get corrupted and the recomputed checksum, whilst different to what it should be, just happens to match the now corrupted checksum?

我可以通过一个好的校验和算法(以及较低级别的附加校验和)看到这可能非常非常不可能，但 TCP 不是 100% 可靠的吗?它如何解决这些误报?

I can see with a good checksum algorithm (and additional checksums at lower levels) this might be very, very unlikely but isn't TCP meant to be 100% reliable? How does it resolve these false positives?

推荐答案

这里应该注意但大多数人完全忽略的一点是，TCP 校验和实际上是一个非常差的校验和.

Something that should be noted here, and that most people overlook completely, is the fact, that the TCP checksum is actually a very poor checksum.

TCP 校验和是数据的 16 位补码和.这笔款项将捕获任何 15 位或更少的突发错误，以及所有 16 位突发除了那些用 1 的补码替换零的错误另一个(即，16 个相邻的 1 位被 16 个零位替换，或反之亦然).在均匀分布的数据上，预计检测其他类型的错误率与 2^16 中的 1 成正比.这校验和还有一个主要限制:一组 16 位的总和无论值的顺序如何，值都是相同的出现.

The TCP checksum is a 16-bit ones-complement sum of the data. This sum will catch any burst error of 15 bits or less, and all 16-bit burst errors except for those which replace one 1’s complement zero with another (i.e., 16 adjacent 1 bits replaced by 16 zero bits, or vice-versa). Over uniformly distributed data, it is expected to detect other types of errors at a rate proportional to 1 in 2^16. The checksum also has a major limitation: the sum of a set of 16-bit values is the same, regardless of the order in which the values appear.

来源:ftp://ftp.cis.upenn.edu/pub/mbgreen/papers/ton98.pdf

因此，如果您在数据包的数据部分的任何位置随机翻转任意数字位，则未检测到此错误的可能性为 1 到 65536，即使您根本不接触校验和，作为新数据，尽管完全损坏，但实际上与旧的校验和相同.如果您只是交换数据部分中的两个 16 位值，无论是哪一个，也不管频率如何，甚至有 100% 的机会没有检测到此错误，因为 16 位值出现在数据部分的顺序数据包与计算出的校验和的值完全无关.

So if you randomly flip any number bits anywhere in the data part of the packet, the chances are 1 to 65536 that this error is not detected, even if you don't touch the checksum at all, as the new data, even though totally corrupt, has in fact the same checksum as the old one. If you just swap two 16 bit values in the data part, regardless which ones and regardless how often, the chances are even 100% that this error is not detected, since the order in which the 16 bit values appear in the data part of the packet is totally irrelevant to the value of the calculated checksum.

我在这里想说的是，您不必太担心数据和校验和都被损坏并且由于损坏的校验和与损坏的数据匹配而未检测到此错误的不太可能的情况，事实是，每天互联网上数百万个 TCP 数据包只有损坏的数据，而未检测到此错误，因为未损坏的校验和仍然与损坏的数据匹配.

What I'm trying to say here is that you don't have to worry too much about the rather unlikely case that data and checksum both get corrupted and this error is not detected because the corrupted checksum matches the corrupted data, the truth is that every day millions of TCP packets on the Internet have only the data corrupted and this error is not detected because the uncorrupted checksum still matches the corrupted data.

如果您需要传输数据并且想要确保数据没有被损坏，那么仅靠 TCP 校验和肯定不足以完成这项任务.我什至敢说 CRC 校验和对于这项任务是不够的，因为 CRC32 可能无法检测到连续超过 32 位受到影响的错误(这些错误可以相互抵消").确保完美数据传输所需的最小校验和是数据的 MD5 值.当然，任何比这更好的东西(SHA-1、SHA-256、SHA-384、SHA-512、Whirlpool 等等)都会工作得更好，但 MD5 就足够了.MD5 可能不再足够安全用于加密安全(因为它过去曾多次被破坏)，但作为数据校验和 MD5 仍然绝对足够.

If you need to transfer data and you want to be sure the data didn't get corrupted, the TCP checksum alone is certainly not enough for this task. I would even dare to say that a CRC checksum is not enough for this task, since a CRC32 may not detect an error where more than 32 bits in a row are affected (these errors can "cancel out" each other). The minimum checksum you'd need for ensuring flawless data transfer is the MD5 value of the data. Of course anything better than that (SHA-1, SHA-256, SHA-384, SHA-512, Whirlpool, and so on) will work even better, yet MD5 is sufficient. MD5 may not be secure enough for cryptographic security any longer (since it has been broken multiple times in the past), but as a data checksum MD5 is still absolutely sufficient.

这篇关于TCP 校验和是否无法检测到错误?如果是，如何处理?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！