问题描述
如果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.
来源: ftp://ftp.cis.upenn.edu/pub/mbgreen/papers/ton98.pdf
因此，如果您在数据包数据部分的任意位置随机翻转任何数字位，则即使您根本不触摸校验和，也有1到65536的机会检测不到此错误，作为新数据，即使完全损坏，其校验和实际上也与旧的相同.如果您只交换数据部分中的两个16位值，而无论交换哪个值和使用频率如何，由于该16位值出现在数据部分中的顺序，甚至有100％的机会未检测到此错误.数据包与计算出的校验和的值完全无关.
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.
我想在这里说的是，您不必担心数据和校验和都被损坏并且由于损坏的校验和与损坏的数据匹配而不会检测到此错误的可能性很小.事实是，每天Internet上数百万的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，漩涡等)都可以更好地工作，但是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校验和不能检测到错误吗?如果是，如何处理?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！