TCP 校验和可能无法检测到错误吗?如果是的话,这件事是如何处理的?

发布于 2024-09-25 09:24:45 字数 270 浏览 4 评论 0原文

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

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

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

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

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

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?

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?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(6

以为你会在 2024-10-02 09:24:45

这里应该注意的是,大多数人完全忽略了一个事实,即 TCP 校验和实际上是一个非常差的校验和。

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

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

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

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

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

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.

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.

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

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.

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.

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.

与他有关 2024-10-02 09:24:45

TCP 校验和会产生误报吗?

是的。校验和比数据包小得多,因此许多不同的数据包可以匹配给定的校验和。

如果有,如何处理?

在 TCP 中,完全不是。然而,大多数数据损坏在较高级别上会很明显,例如您的 XML 格式不再正确;您的电子邮件不再是英文等。

Can a TCP checksum produce a false positive?

Yes. The checksum is considerably smaller than the packet, so many different packets can match a given checksum.

If yes, how is this dealt with?

In TCP, not at all. However, most data corruptions will be noticeable at a higher level, e.g. your XML is no longer well-formed; your email is no longer English, etc.

浅忆 2024-10-02 09:24:45

不,它不可能 100% 可靠:本文提到,每 1600 万到 100 亿个数据包中就有 1 个没有被错误控制系统捕获。我会让你计算每天/每周的发生次数:)

No it can't be 100% reliable: this paper mentions 1 in 16 million to 10 billion packets not caught by the error control system. I'll let you calculate the occurences per day/week :)

も星光 2024-10-02 09:24:45

以及较低级别的附加校验和

其中一些比校验和更严格,例如以太网使用 CRC 而不是校验和。

这可能非常非常不可能,但是 TCP 不是 100% 可靠吗?它如何解决这些误报?

我认为不可以。即使它通过硬拷贝和信鸽发送了副本,理论上宇宙射线或量子效应也可能以完全相同的方式破坏副本。这只是非常非常不可能的。

您还可以在应用程序层(TCP 之上)实现任意强的完整性检查,例如使用加密签名。

and additional checksums at lower levels

Some of these are stricter than checksums, e.g. Ethernet uses a CRC instead of a checksum.

this might be very, very unlikely but isn't TCP meant to be 100% reliable? How does it resolve these false positives?

I don't think it can. Even if it sent a duplicate via hard copy and carrier pigeon, a cosmic ray or quantum effects might theoreticaly mangle the duplicate too in exactly the same way. It's just very, very unlikely.

You can also implement arbitrarily strong integrity chcking at the application layer (above TCP), e.g. using cryptographic signing.

落花浅忆 2024-10-02 09:24:45

假设

数据包有效负载: 1000 字节

数据包校验和: 数据包出现双错误的 2 字节

概率,校验和中的其中之一(假设 P 非常小,小于 1/10^5):

A = 8P*(1000*8P) = 6*10^4 * P^2

准确校验和的概率:

B = 1/2^16 = 6/10^4

误报概率:

A * B = 40 * P^2 

概率较低(P=1/10^6,则误报 A*B=4/10^11 的概率),但在任何情况下,使用任何 crc 算法,它都不可能为零。一个随机 1000 字节数据包作为另一个随机 1000 字节数据包出现的概率为 P^8000,就好像所有字节都包含错误一样。

如果 P 较高,例如从 1/10^3 到 1,则上述计算不适用。在这种情况下,A=1(所有数据包都包含双重错误),误报概率仅为 A*B = 6/10^4。这不是一个非常相关的案例,因为超过 99% 的接收数据包都会包含 crc 错误。

Assume

packet payload: 1000 byte

packet checksum: 2 byte

probability of packet with double error, one of wchich in checksum (assume P very small, less than 1/10^5):

A = 8P*(1000*8P) = 6*10^4 * P^2

probability of exact checksum:

B = 1/2^16 = 6/10^4

probability of false positive:

A * B = 40 * P^2 

The probability is low (P=1/10^6, then the probability of false positive A*B=4/10^11) but in any case with any crc algorithm it can't be zero. The probability of a random 1000 byte packet to appear as another random 1000 byte packet is P^8000, as if all bytes contain errors.

If P is high, for example from 1/10^3 to 1, the calculations above does not apply. In that case A=1 (all packets contain double errors) and the probability of false positive is just A*B = 6/10^4. It's not a very relevant case because more than 99% of received packets will contain errors in crc.

烟织青萝梦 2024-10-02 09:24:45

我想概率是十亿分之一,因为如果 TCP 数据(即传输层)损坏,也意味着其他层(数据链路和网络)也将损坏。我相信至少数据链路层有一个完整性校验和,所以你必须让两个校验和都失败。

以至少两个单独的校验和失败的方式进行损坏在天文数字上是不太可能的,甚至可能是不可能的。

I would imagine the probability is one in a billion million zillion kajillion, because if the TCP data is corrupted, which is the transport layer, it will also mean the other layers (datalink and network) will also be corrupted. I believe at least the datalink layer has a checksum for integrity, so you'd have to have both checksums fail.

Corrupting in such a way that at least two separate checksums fail, is astronomically unlikely, maybe even impossible.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文