TCP/HTTPS 是否保证文件上传/下载的完整性？

问题描述

假设我想将文件上传到网络服务器。甚至可能是一个相当大的文件（例如 30 MB）。它是通过典型的文件上传表单完成的（参见下面的最小示例）。

现在网络并不完美。我认为可能出现这些类型的错误：

Bitflip 可能发生
包裹可能会丢失
包裹到达的顺序可能不是它们发送的顺序
一个包裹可以收到两次

在协议栈的较低级别，由于网络拥塞、流量负载平衡或不可预测的网络行为，IP 数据包可能会丢失、重复或无序传递。 TCP 检测到这些问题，请求重新传输丢失的数据，重新排列乱序数据，甚至帮助最小化网络拥塞以减少其他问题的发生。如果数据仍未交付，则会通知源此失败。一旦 TCP 接收器重新组合了最初传输的八位字节序列，它就会将它们传递给接收应用程序。因此，TCP 从底层网络细节中抽象出应用程序的通信。

读到这里，我明白为什么下载的文件可能会损坏的唯一原因是 (1) 下载后出现问题或 (2) 连接中断。

我错过了什么吗？为什么提供 Linux 映像的站点通常也提供 MD5 哈希值？通过 HTTPS（因此也通过 TCP）上传/下载文件的完整性是否得到保证？

最小文件 上传示例

HTML：

<!DOCTYPE html>
<html>
<head><title>Upload a file</title></head>
<body>
<form method="post" enctype="multipart/form-data">
    <input name="file" type="file" />
    <input type="submit"/>
</form>
</body>
</html>

Python/Flask：

"""
Prerequesites:

  $ pip install flask
  $ mkdir uploads
"""

import os
from flask import Flask,flash,request,redirect,url_for
from werkzeug.utils import secure_filename


app = Flask(__name__)
app.config["UPLOAD_FOLDER"] = "uploads"


@app.route("/",methods=["GET","POST"])
def upload_file():
    if request.method == "POST":
        # check if the post request has the file part
        if "file" not in request.files:
            flash("No file part")
            return redirect(request.url)
        file = request.files["file"]
        # if user does not select file,browser also
        # submit an empty part without filename
        if file.filename == "":
            flash("No selected file")
            return redirect(request.url)
        filename = secure_filename(file.filename)
        file.save(os.path.join(app.config["UPLOAD_FOLDER"],filename))
        return redirect(url_for("upload_file",filename=filename))
    else:
        return """<!DOCTYPE html>
<html>
<head><title>Upload a file</title></head>
<body>
<form method="post" enctype="multipart/form-data">
    <input name="file" type="file" />
    <input type="submit"/>
</form>
</body>
</html>"""
    return "upload handled"


if __name__ == "__main__":
    app.run()

解决方法

文件上传/下载的完整性是否由 TCP/HTTPS 保证？

简而言之：不会。但使用 HTTPS 比使用普通 TCP 更好。

TCP 只有非常弱的错误检测，所以它可能会检测简单的位翻转并丢弃（并重新发送）损坏的数据包 - 但它不会检测更复杂的错误。尽管 HTTPS 具有（通过 TLS 层）非常可靠的完整性保护，并且传输过程中未被检测到的数据损坏基本上是不可能的。

TCP 还具有强大的检测和防止重复和重新排序的功能。 TLS（在 HTTPS 中）对此类数据损坏具有更强大的检测能力。

但是当 TCP 连接简单地提前关闭时它会变得模糊，例如如果服务器崩溃。 TCP 本身没有消息指示，因此连接关闭通常用作消息结束指示符。例如，这适用于 FTP 数据连接，但也适用于 HTTP（以及 HTTPS）。虽然 HTTP 通常有一个长度指示符（Content-length 标头或带有 Transfer-Encoding: chunked 的显式块大小），但它也将 TCP 连接的结束定义为消息的结束。如果在声明的消息结束之前到达连接结束，客户端的行为会有所不同：有些将数据视为已损坏，其他将假设服务器损坏（即错误的长度声明）并将连接关闭视为有效的消息结束。

理论上 TLS（在 HTTPS 中）具有明确的 TLS 结束消息（TLS 关闭），这可能有助于检测早期连接关闭。在实践中，虽然实现可能只是在没有这种显式 TLS 关闭的情况下关闭底层套接字，因此遗憾的是不能完全依赖它。

为什么提供 Linux 映像的网站通常也提供 MD5 哈希值？

还有另一个故障点：下载可能在下载之前已损坏。下载站点通常有多个镜像，将文件发送到下载镜像时，甚至将文件发送到下载主机时，都可能发生损坏。在下载的同时进行一些强校验和有助于检测此类错误，只要校验和是在下载源创建的，因此是在数据损坏之前创建的。

integrity protocols