提供下载ISO文件的网站通常会提供这些文件的md5校验和，我们可以使用这些校验和来确认文件已经正确下载，并且没有被破坏。
为什么这是必要的？ 当然TCP的纠错属性是足够的。 如果一个数据包没有被正确接收，它将被重新发送。 TCP / IP连接的本质不是保证数据完整性吗？
可能有几十个理由为什么我们应该检查md5sum，但有几个出现在我的脑海里：
无论如何，这只需要几秒钟。
正如其他人所指出的那样，在传输层的任何校验和都无法帮助的情况下，数据损坏的可能性很大，例如在发送端计算校验和之前腐败已经发生，MITM拦截并修改stream（数据也是如此作为校验和），在validation接收端的校验和之后发生腐败等。
如果我们忽视所有这些其他的可能性，并关注TCP校验和本身的细节，以及它在validation数据完整性方面的实际作用，则会发现这个校验和的属性在检测错误方面并不全面。 这种校验algorithm的select方式反映了速度与时间段（20世纪70年代后期）相结合的要求。
这是如何计算TCP校验和 ：
校验和：16位
校验和字段是头部和文本中所有16位字的补码和的16位补码。 如果一个段包含校验和的奇数个头和文本字节，则最后一个八位字节在右边用零填充以形成一个16位字用于校验和。 垫没有传输作为部分的一部分。 在计算校验和时，校验和字段本身被replace为零。
这意味着，以这种方式总结数据时，任何损坏都不会被察觉。 对于数据来说，有许多types的腐败，但这只是一个微不足道的例子：改变16位字的顺序总是不被发现。
在实践中，它捕获了许多典型的错误，但完全不能保证完整性。 L2层如何进行完整性检查（例如，以太网帧的CRC32）也有所帮助，尽pipe仅用于本地链路上的传输，并且许多数据损坏的数据甚至不会传递到TCP堆栈。
在确保数据完整性方面，使用强散列或优选密码签名validation数据是完全不同的级别。 这两者甚至可以媲美。
TCP / IP确保数据完整性*。 但是并不能保证100％的文件已被下载。 可能有很多原因，为什么会发生这种情况。 例如：你可以挂载一个在中间某个地方丢失一个或两个字节的ISO文件。 直到您需要一个或两个损坏的特定文件时，才会有问题。 比较校验和可确保您确实下载了整个文件。
*见评论
TCP校验和只有16位。 这意味着在没有其他校验和的情况下，每65536个被破坏的数据包中将有一个被认为是未损坏的。 例如，如果您通过嘈杂的链接下载8GB的DVD映像，其损坏率为1％，那么您预计会有81个无法察觉的损坏的数据包。
MD5是一个更大的校验和，在128位。 那些与原来产生相同校验和的81包的几率约为十亿分之一十亿。
validation通过HTTP下载的文件的校验和有几个原因：
1来源评论，因为哈哈代表
丹尼尔，取决于你所使用的ISO下载工具。 如果是说Firefox ..它可能会显示文件下载。 但是，您可能没有完整的ISO。 如果你刻录它然后尝试使用它，信息可能会丢失。 这在不同的托pipe文件的networking服务器上时有发生。
至less比较文件大小（总字节数或位数）确保它们匹配是一个好习惯。 Windows将显示不同的文件字节数，然后说Linux。 MD5总和检查将显示相同的值不pipe哪个操作系统使用。 希望这有助于一点。 干杯…
我注意到很多有趣的答案，但还有最后一件事要考虑： 两个将军的问题
两个将军问题和拜占庭将军问题特别考虑了通过不可靠渠道可靠传递信息的意义。
校验和只是“增加可靠性”的另一个层面，而失败几率很小。 这就是它如此受欢迎的原因。