如何检查从 HTTP 或 FTP 下载的数据是否损坏？

就其本身而言，根本不是。

HTTP 和 FTP 作为协议不提供完整性¹。

然而，HTTP 和 FTP 通常在 TCP/IP 之上使用，它们的传输中都有校验和 - 如果 TCP 校验和失败，您的操作系统将丢弃 TCP 数据包并再次请求它。因此，HTTP 甚至不需要实现完整性检查。

通过 TLS 传输任何内容（包括 HTTP 和 FTP）时，您会获得额外的完整性检查层。

那么 FTP 和 HTTP 是如何保证数据不被破坏的呢？

他们没有。保证完整性通常是传输的工作，而不是应用程序协议的工作。

我想在这里补充一点，如果您想故意修改传输，那么在 MD5（在这些标头中使用）内造成冲突当然比伪造 TCP 数据包更难。但如果这是您的攻击场景，那么 TLS 就是答案，而不是 HTTP 校验和。

HTTP 和 FTP 几乎总是使用 TCP 作为底层传输层，因此 TCP 的保护也适用于那里。然而，这些只涉及网络级别的意外损坏问题。正如您所指出的，文件是否成功写入的验证通常留给 CRC32 之类的校验和。

如果您担心故意操纵（我假设您是这样，因为这是在 security.SE 上），那么这些还不够，因为它们在密码学上并不安全。在网络端，我们通常通过引入 TLS 来处理不同的层（当与 HTTP 结合时，我们得到 HTTPS；当与 FTP 结合时，我们得到 FTPS）。但是，如果您想特别确定并验证磁盘上文件的完整性，供应商的常用方法是提供一个列出 SHA-2 校验和的文件，然后使用 GPG 密钥对其进行签名；您下载这两个文件，然后验证校验和文件已由您信任的密钥签名，并且其他文件与您刚刚验证的文件中列出的校验和匹配。

那么 FTP 和 HTTP 是如何保证数据不被破坏的呢？

简而言之，从安全的角度来看，他们没有。

所有这些协议都假定是堆叠的。堆栈中的每个级别都有自己的责任。相对于您的问题，奇怪的是消息的完整性既不是 FTP 或 HTTP 的问题，也不是 TCP 的问题。前者负责协议的高层部分，允许交换文件或数据，后者负责正确传递数据包。数据包的完整性是 OSI 堆栈中第 2 层（数据链路）的关注点。它应该保证在 2 个连续节点之间交换的数据包没有被更改。这里最常见的协议是使用强校验和的 HDLC。

当然，在 TCP 级别有一个校验和，但它只是一个包罗万象的功能，以防其中一个节点发疯并发送错误数据时发出警报，并且它确实使用了更弱的校验和。毕竟，诚信不是它的工作。

如果您使用普通网络，则完整的 TCP/IP 堆栈可以保证数据完整性。端到端校验和通常用于控制文件在发件人站点中没有损坏，因为您使用了镜像或原始文件系统出现问题。