为什么在下载文件时比较校验和是一种好习惯？

Question

提供 ISO 文件供下载的网站通常会提供这些文件的 md5 校验和，我们可以使用它来确认文件已正确下载，并且没有损坏。

为什么这是必要的？当然，TCP 的纠错特性就足够了。如果数据包没有被正确接收，它将被重新传输。TCP/IP 连接的本质难道不能保证数据完整性吗？

Answer 1

为什么应该检查 md5sum 可能有无数个原因，但我想到了几个原因：

• 恶意活动 - 您的 ISO 可能在从服务器发送的途中被篡改
• 该页面本身是欺骗性的（最好也对 md5sums 进行签名 :)）
• 下载中断（尽管 TCP 错误更正）（检查这个）
• ISO烧毁不正确

无论如何，它只需要几秒钟。

Answer 2

正如其他人所指出的那样，数据损坏的可能性有很多，传输层的任何校验和都无济于事，例如在发送端计算校验和之前已经发生损坏，MITM 拦截和修改流（数据以及作为校验和），在接收端验证校验和后发生损坏等。

如果我们忽略所有这些其他可能性，而专注于TCP 校验和本身的细节以及它在验证数据完整性方面的实际作用，那么就检测错误而言，该校验和的属性根本不全面。选择这种校验和算法的方式反映了对速度与时间段（1970 年代后期）相结合的要求。

这是怎样的TCP校验和计算公式为：

校验和：16 位

校验和字段是标题和文本中所有 16 位字的补码和的 16 位补码。如果一个段包含奇数个要校验和的报头和文本八位字节，最后一个八位字节在右边用零填充以形成一个 16 位字用于校验和目的。填充不作为段的一部分传输。在计算校验和时，校验和字段本身被替换为零。

这意味着在以这种方式对数据求和时平衡的任何损坏都不会被检测到。这将允许对数据进行多种类型的损坏，但仅举一个简单的例子：更改 16 位字的顺序将始终无法检测到。

在实践中，它捕获了许多典型的错误，但根本不保证完整性。L2 层如何进行完整性检查（例如以太网帧的 CRC32）也有帮助，尽管仅用于本地链路上的传输，而且许多损坏的数据甚至从未传递到 TCP 堆栈。

就确保数据完整性而言，使用强散列或最好是加密签名来验证数据处于完全不同的水平。两者几乎不能相提并论。

Answer 3

TCP/IP 确实保证数据完整性*。但它不能保证 100% 的文件已被下载。发生这种情况的原因可能有很多。例如：您可能会挂载一个在中间某处丢失一两个字节的 ISO。除非您需要一两个已损坏的特定文件，否则您不会遇到问题。比较校验和确保您确实下载了整个文件。

* 见评论

Answer 4

TCP 校验和只有 16 位。这意味着，在没有其他校验和的情况下，每 65536 个损坏的数据包中有一个将被视为未损坏。例如，如果您通过嘈杂的链接以 1% 的损坏率下载 8GB 的​​ DVD 映像，那么您会期望有 81 个无法检测到的损坏数据包。

MD5 是一个更大的校验和，为 128 位。这 81 个数据包产生与原始校验和相同的数据的几率约为 1,000,000,000,000,000,000,000,000,000,000,000 中的 1。

Answer 5

验证通过 HTTP 下载的文件的校验和有多种原因：

• 确保您收到整个文件
  • 某些客户端（例如Firefox）可能会将中断的连接视为成功下载，从而使您的文件被截断但声称已下载成功
• 确保您收到正确的文件
  • 例如，有问题的、受感染的或恶意的服务器可能会向您发送其他信息
  • 有人可能会篡改传输（中间人攻击） - 如果您的系统受到 Superfish 等攻击，或者所使用的加密方法较弱，即使 HTTPS 也不安全
  • 他们也可能只是给你一个虚假的下载页面，所以你甚至没有连接到真正的服务器（但在这种情况下，如果你从同一个假服务器获取校验和，校验和将无济于事）
  • 由于各种原因¹；取决于它的实施情况，它也可能会破坏一些文件下载
  • 镜像可能托管的是过时版本的文件，或者管理员可能上传了错误的文件
• 确保文件没有被 TCP 无法检测到的东西损坏
  • 例如，服务器上的文件可能已损坏，因此 TCP 只会确保已损坏的文件在传输过程中不会受到进一步破坏
  • 或者它可能在到达您的一端后被损坏，原因是内存/磁盘有问题、文件系统驱动程序有问题等
  • TCP 校验和只有 16 位，因此不会检测到损坏的数据包的可能性不是天文数字（65536 中的 1 个）
• 使用 ISO，确保光盘正确刻录

^{评论中有1 个来源，因为大声笑代表}