据我了解,当您使用 HTTP/HTTPS 协议(protocol)将文件从客户端发送到服务器时,您可以保证所有发送的数据都已成功到达目的地。但是,如果您正在发送一个巨大的文件,然后互联网连接突然中断,则不会发送所有数据包,因此您会失去文件的逻辑完整性。
我的陈述中是否遗漏了任何要点?
我想知道是否有一种方法可以让目标节点在不使用“自定义代码/api”的情况下检查文件逻辑完整性。
最佳答案
HTTPS 只是 TLS 层上的 HTTP,因此所有内容也适用于 HTTPS:
HTTP 通常通过 TCP/IP 传输。现在,TCP 具有流量控制(即丢失的数据包将被重新发送)和校验和(即,在接收方没有注意到并重新请求数据包的情况下数据被更改的可能性很小)。因此,如果您真的只是传输数据,那么您基本上已经设置好了(只要您的 HTTP 服务器配置为以字节为单位发送文件的长度,至少对于静态文件,通常是这样)。
如果您的传输在达到您的服务器发送给客户端的 HTTP GET 回复中公布的整个文件大小之前停止,您的客户端就会知道!许多 HTTP 库/客户端可以重新启动 HTTP 传输(如果服务器支持)。
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.15 甚至指定一个 MD5 校验和头域。您可以将 Web 服务器配置为使用该字段,客户端可能会使用它来验证整体文件的完整性。
编辑:rfc2616 指定的 Content-MD5 似乎已被弃用。您现在可以使用 a content digest ,这更加灵活。
另外,您提到您想要检查客户端发送到服务器的文件。这个问题可能会更难一些——虽然您通常可以完全控制您的网络服务器,但您不能强制任意客户端(例如浏览器)在上传之前对其文件进行哈希处理。
另一方面,如果您实际上可以控制客户端的 HTTP 实现,那么您很可能还可以使用比普通 HTTP 更面向文件传输的东西——想想 WebDav、AtomPUB 等,它们是基于HTTP,甚至更多面向文件交换的协议(protocol),如 rsync(如果您实际上正在同步东西,我会衷心推荐它——如果双方的版本仅部分不同,它会将网络使用量减少到最低限度)。如果出于某种原因,你的用户在一个定义明确的圈子内共享他们的大部分数据(例如,你正在构建摄影师共享他们相册的东西),你甚至可以只使用 bittorrent,它具有-chunk hashing,广泛的负载平衡选项,并允许“普通的旧 HTTP 种子”。
关于file - HTTPS 协议(protocol)文件完整性,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/28365110/