提供 ISO 文件下载的网站通常会提供这些文件的 md5 校验和，我们可以使用该校验和来确认文件已正确下载且没有损坏。
为什么这是必要的？TCP 的纠错特性当然足够了。如果数据包没有正确接收，它将被重新传输。TCP/IP 连接的本质难道不能保证数据完整性吗？
答案1
正如其他人所指出的，数据损坏的可能性有很多，而传输层的任何校验和都无法解决这些问题，比如在发送端计算校验和之前就已经发生损坏、MITM 拦截和修改流（数据和校验和）、在接收端验证校验和之后发生损坏等等。
如果我们忽略所有其他可能性，而专注于TCP 校验和就其本身以及它在验证数据完整性方面实际的作用而言，事实证明，该校验和的属性在检测错误方面并不全面。选择此校验和算法的方式反映了对速度的要求以及时间段（20 世纪 70 年代末）。
这就是TCP 校验和计算如下：
校验和：16 位
校验和字段是报头和文本中所有 16 位字的补码和的 16 位补码。如果一个段包含奇数个要进行校验的报头和文本八位字节，则最后一个八位字节的右侧会用零填充，以形成一个 16 位字，用于校验和。填充不会作为段的一部分传输。在计算校验和时，校验和字段本身会被零替换。
这意味着，以这种方式对数据求和时平衡的任何损坏都无法被检测到。这将允许多种类型的数据损坏，但这只是一个简单的例子：更改 16 位字的顺序将始终无法被检测到。
实际上，它能捕获许多典型错误，但根本不能*保证*完整性。L2 层也会进行完整性检查（例如以太网帧的 CRC32），尽管只针对本地链路上的传输，但许多损坏数据的情况甚至从未传递到 TCP 堆栈，这也对完整性有所帮助。
使用强哈希或最好使用加密签名来验证数据，在确保数据完整性方面处于完全不同的水平。这两者几乎无法比较。
答案2
可能有无数个理由说明为什么需要检查 md5sum，但我只想到了以下几个：
- 恶意活动——你的 ISO 可能在从服务器传输的过程中被篡改
- 该页面本身是伪造的（最好对 md5sum 也进行签名：））
- 下载中断（尽管 TCP 错误更正）（检查这出去）
- ISO 刻录不正确
而且无论如何只需要几秒钟。
答案3
TCP/IP 确实保证了数据的完整性*。但它不能保证文件 100% 已下载。发生这种情况的原因有很多。例如：您可能会挂载中间某处缺少一两个字节的 ISO。除非您需要一两个损坏的特定文件，否则您不会遇到问题。比较校验和可确保您确实下载了整个文件。
*参见评论
答案4
验证通过 HTTP 下载的文件的校验和有几个原因：
- 确保您收到整个文件
- 一些客户，例如火狐，可能会将中断的连接视为成功下载，导致文件被截断，但会声称已下载成功
- 确保你收到正确的文件
- 例如，有漏洞的、被入侵的或恶意的服务器可能会向你发送其他内容
- 有人可能会篡改传输（中间人攻击）——如果你的系统受到 Superfish 等攻击，或者使用的加密方法较弱，即使是 HTTPS 也不安全
- 他们也可能只是向您展示一个虚假的下载页面，所以您甚至没有连接到真正的服务器（但在这种情况下，如果您从同一个虚假服务器获取校验和，那么校验和将没有太大帮助）
- 许多 ISP 被发现出于各种原因在传输过程中向页面注入 Javascript 1；根据实施情况，它还可能会破坏一些文件下载
- 镜像可能托管了文件的过期版本，或者管理员可能上传了错误的文件
- 确保文件没有被 TCP 无法检测到的损坏
- 例如，文件可能在服务器上损坏，因此 TCP 只能确保已损坏的文件不会在传输过程中进一步损坏
- 或者它可能在到达你的终端后被损坏，因为有故障的内存/磁盘，有缺陷的文件系统驱动程序等
- TCP 校验和只有 16 位，因此损坏的数据包无法被检测到的概率并不小（65536 分之一）
- 使用 ISO，确保光盘刻录正确
评论中有1 个来源，因为 lol rep