Mr *_*ion 44 networking checksum tcp
如果TCP有效负载在传输过程中损坏,则重新计算的校验和将与传输的校验和不匹配.很棒,到目前为止都很好.
如果TCP校验和在传输过程中损坏,则重新计算的校验和将与现在已损坏的校验和不匹配.很棒,到目前为止都很好.
当有效负载和校验和都被破坏并且重新计算的校验和虽然与它应该是不同的时候会发生什么,恰好匹配现在已损坏的校验和？
我可以看到一个良好的校验和算法(以及较低级别的额外校验和),这可能非常非常不可能,但TCP不是100%可靠吗？它如何解决这些误报？
Mec*_*cki 32
这里应该注意的事情,以及大多数人完全忽略的事实是,TCP校验和实际上是一个非常差的校验和.
TCP校验和是数据的16位补码和.该总和将捕获15位或更少的任何突发错误,以及所有16位突发错误,除了那些用另一个替换1的补码0(即16个相邻的1位替换为16个零位,或反之亦然).在均匀分布的数据上,期望以与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仍然绝对足够.
Bry*_*yan 13
TCP校验和是否会产生误报？
是.校验和比数据包小得多,因此许多不同的数据包可以匹配给定的校验和.
如果是的话,这是如何处理的？
在TCP中,根本没有.但是,大多数数据损坏都会在更高级别上显而易见,例如,您的XML不再格式正确; 您的电子邮件不再是英文等
以及较低级别的额外校验和
其中一些比校验和更严格,例如以太网使用CRC而不是校验和.
这可能非常非常不可能,但TCP不是100%可靠吗？它如何解决这些误报？
我认为不可以.即使它通过硬拷贝和载体鸽发送了副本,宇宙射线或量子效应也可能理论上也会以完全相同的方式破坏复制品.这非常非常不可能.
您还可以在应用程序层(在TCP之上)实现任意强大的完整性更新,例如使用加密签名.