HTTPS协议文件完整性

Question

据我所知，当您使用HTTP / HTTPS协议将文件从客户端发送到服务器时，您可以保证成功发送的所有数据都到达目的地。但是，如果您发送一个巨大的文件，然后突然互联网连接断开，并非所有软件包都被发送，因此您将失去文件的逻辑完整性。

我的陈述中是否有任何遗漏？

我想知道目标节点是否有办法在不使用＆＃34;自定义代码/ api＆＃34;的情况下检查文件逻辑完整性。

Answer 1

HTTPS只是TLS层上的HTTP，所以所有这些都适用于HTTPS：

HTTP通常通过TCP / IP传输。现在，TCP具有流控制（即，将重新发送丢失的分组），并且校验和（即，没有接收器注意并且重新请求分组数据被改变的概率很小）。因此，如果您真的只是传输数据，那么基本上就是设置（只要您的HTTP服务器配置为以字节为单位发送文件的长度，至少对于静态文件，通常是这样）。

如果在达到服务器发送给客户端的HTTP GET回复中公布的整个文件大小之前停止传输，则客户端将知道！许多HTTP库/客户端可以重新启动HTTP传输（如果服务器支持它）。

http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.15 even指定MD5校验和标头字段。您可以将Web服务器配置为使用该字段，客户端可以使用它来验证整体文件的完整性。

编辑：rfc2616指定的Content-MD5似乎已被弃用。您现在可以使用a content digest，这更加灵活。

另外，您提到要检查客户端发送到服务器的文件。这个问题可能会有点困难 - 虽然您通常完全控制您的Web服务器，但在上传之前，您无法强制任意客户端（例如浏览器）对其文件进行哈希处理。

另一方面，如果你实际上是控制客户端的HTTP实现，你很可能也会使用比普通HTTP更多的文件传输 - 想想WebDav，AtomPUB等，它们是HTTP，甚至更多面向文件交换的协议，如rsync（如果您实际上正在同步内容，我会衷心推荐它 - 如果双方版本仅部分不同，则会将网络使用率降至最低）。如果出于某种原因，您的用户可以在明确定义的圈子中共享大部分数据（例如，您正在构建摄影师共享其相册的内容），您甚至可能只使用bittorrent， -chunk哈希，广泛的负载平衡选项，并允许“普通的旧HTTP种子”。

Answer 2

这里有几个问题：

1. 正如Marcus所说，他的答案是TCP保护您的字节不被意外损坏，但如果下载被中断则无效
2. HTTPS还可以确保服务器和客户端之间没有篡改这些字节（您）
3. 如果你想验证文件的完整性（传输是否被中断）你应该使用校验和来防止意外的文件损坏（例如CRC32，可能有更好的文件，你应该校验）
   1. 如果您另外使用HTTPS，那么您也可以免受故意攻击，因为您知道您的校验和是正常的，并且您获得的文件部分未被篡改。
4. 如果您使用校验和，但不使用HTTPS（但您确实应该使用），那么您应该可以安全地防止意外数据损坏，但不能防止恶意攻击。它可以减轻，但它超出了这个问题的范围

Answer 3

在HTTP / 1.1中，收件人始终可以检测是否收到了完整的消息（通过比较Content-Length，或通过正确处理transfer-encoding：chunked）。

（如果怀疑传输层出现位错误，添加内容哈希会有所帮助。）