理解 HTTP Multipart：入门介绍

Multipart，亦或称为“表单编码数据”，虽然在各处可见，但我从未真正需要深入了解或使用过，因为 HTTP 库已经为我处理了一切。然而，最近在Cloudflare和我的新工作 KittyCAD 中，我不得不深入研究 multipart 的工作原理，因为它在文件上传方面的效率至关重要。使用正确的情况下，multipart 可以使文件上传更快并减少内存使用。我将从高层次解释它的工作原理，以便你在 HTTP 服务器/客户端中使用时，能够节省时间和内存。

顺带一提，本文假设你已了解什么是 MIME 类型。

为什么使用 multipart？

Multipart 解决了文件上传的效率问题。在 Multipart 出现之前，上传文件的标准是使用“application/x-www-form-urlencoded”，该方法要求客户端在上传文件前进行 URL 编码。如果文件主要是 ASCII 文本，URL 编码是高效的；但如果是二进制数据，那几乎每个字节都必须进行 URL 转义，这是非常低效的。如果你想在不 编码的情况下上传多个文件，你可以发送多个 HTTP 请求。但这比在一个请求中发送它们所有的延迟更大。

因此在 1998 年，RFC 2388 提出了一个新标准 “multipart/form-data”，它允许你在一个HTTP请求体中发送多个文件而无需编码。不进行编码意味着你可以节省大量的 CPU 周期并保持总体积较小。

这一协议最初是为 HTML 表单上传文件而设计的，因此得名。但实际上你可以用它从任何客户端上传文件到任何 HTTP 服务器，规范的任何部分都不要求使用<form>或任何 HTML。你甚至可以使用它来从任何 HTTP 客户端上传文件到任何 HTTP 服务器。

multipart 的另一个优点是服务器可以分别流式传输每个部分。例如，假设你正在通过将文件编码进一个 JSON 对象来上传 5 个文件。你的服务器必须将整个 JSON 对象缓存到内存中，解码并检查每个文件。但使用 multipart，服务器可以一次传输每个部分（即文件），这样可以减少内存使用并提高延迟（因为处理第一个文件时无需等待其他四个文件）。

(哦，并且 JSON 也无法处理二进制文件，所以你需要将每个文件转换为 base64 字符串。但如上所述，multipart 可以处理原始二进制数据，这也是一个优势)

在 Rust 中

你的 Rust HTTP 服务器或客户端框架可能已经支持 multipart。reqwest 也有内置支持。

如果你在构建自己的 HTTP 服务器，我建议使用 multer crate 来支持异步 multipart。这是 axum 使用的 crate，因此它应该非常快速可靠。重用生态系统中的 crate 意味着你甚至不需要知道 multipart 是如何实现的。但如果你感兴趣，继续阅读。

什么是 multipart？

MIME 类型分为两类，离散类型和 multipart 类型。

• 离散类型包含一个文档。例如application/（二进制），image/，text/等。
• Multipart 类型是包含多个部分的文档，这些部分可以有自己的 MIME 类型。

有两种 multipart 类型：message/ 和 multipart/ -- 是的，multipart 既是一个类型又是一个类有点混淆。message/类型基本上不再用于任何事情，但multipart/仍然非常重要。你经常看到multipart/form-data用于通过 HTML 表单从 Web 浏览器发送文件到服务器。part 在multipart中指的是一个文档。这个类型本可以被称为 multidocument！注意，它不必须包含多个文件。它也可以只包含一个文件，使用 multipart 进行高效的二进制编码。

multipart 的实现方式是什么？

如果内容类型是multipart/form-data，那么 HTTP 请求体将包含多个部分（即文档）。每个部分由“边界分隔符”分开。根 HTTP 消息有一个头部，它定义了边界分隔符，以便服务器知道每个部分之间的边界在哪里。每个部分也有一些头：

• Content-Disposition 头定义了每个部分的文件名或包含它的表单字段的名称（仅当你使用实际的 HTML 表单元素时相关）。
• Content-Type 头定义了每个部分的文件类型（好吧，技术上是它们的 MIME 类型，但这大致相当）。默认为 text/plain。非结构化二进制数据应使用 application/octet-stream，但如果你知道类型，你应该使用它，例如 application/zip，application/pdf 等。
• 除此之外，不能使用其他任何头部！引用RFC 7578: “multipart/form-data 媒体类型不支持在 Content-Type、Content-Disposition 和（在有限的情况下）Content-Transfer-Encoding 以外的部分中的任何MIME头字段。其他头字段不得包括且必须被忽略。 ”。

以下是一个来自 Stack Overflow 的实际示例，展示了HTTP 请求体的样子，这个请求体是一个包含 3 个 GIF 文件的 multipart。

POST /cgi-bin/qtest HTTP/1.1
Content-Type: multipart/form-data; boundary=2a8ae6ad-f4ad-4d9a-a92c-6d217011fe0f
Content-Length: 514

--2a8ae6ad-f4ad-4d9a-a92c-6d217011fe0f
Content-Disposition: form-data; name="datafile1"; filename="r.gif"
Content-Type: image/gif

GIF87a.............,...........D..;
--2a8ae6ad-f4ad-4d9a-a92c-6d217011fe0f
Content-Disposition: form-data; name="datafile2"; filename="g.gif"
Content-Type: image/gif

GIF87a.............,...........D..;
--2aakae6ad-f4ad-4d9a-a92c-6d217011fe0f
Content-Disposition: form-data; name="datafile3"; filename="b.gif"
Content-Type: image/gif

GIF87a.............,...........D..;
--2a8ae6ad-f4ad-4d9a-a92c-6d217011fe0f--

压缩

你可以对整个 Multipart 响应进行 gzip 压缩，但你不能为特定部分选择压缩。这是因为根 HTTP 请求体为整个消息定义了压缩头部，包括 multipart 请求体中的所有部分。因此，客户端无法告诉服务器“这个特定部分是压缩的，但那个不是”。而且，如上所述，在 multipart 文档内只允许使用3种特定的 HTTP 头部——压缩头部不是其中之一。

为什么这很有趣？

所以，“multipart”或“表单编码数据”是一种包含多个文件的 MIME 类型。每个文件都有自己的 MIME 类型和名称。从历史上看，这比其他上传多个文件的方式有很大的改进，因为它可以以原始二进制的形式发送每个文件，无需额外的编码或转义。

在我写这篇博客文章之前，我发现 multipart 有点无聊。它看起来有些古老和落后——我的意思是，它诞生于 HTML 表单是 Web 技术前沿的时代。自从其 RFC 首次发布以来已经过去了 25 年。当然，我们现在有更好的上传文件的方式了!

但实际上它在抽象的层面上颇有趣。它试图有效地组合多个文件上传，而“我们如何组合许多这样的东西在一起”的问题在计算机科学中始终是一个有趣的问题。

我之所以喜欢 JSON，是因为组合 JSON 很简单。如果每个文件上传都是一个 JSON 请求体，组合它们非常简单：只需将所有n 个单独的 JSON 请求体组合成一个包含n 个字段的大请求体。但这样性能不佳：

• 你必须将文件内容转换为 base64，因为 JSON 只能处理文本，不能处理二进制
• 服务器必须将整个 JSON 请求体缓存到 RAM 中，然后再解码

我想 multipart/form-data 是一种尝试有效组合多个文件上传的方法。这种权衡带来了一些复杂性，如边界和内容配置。我很好奇现代解决这个问题的方法会是什么样子。显然，multipart/form-data 已经足够好了，因为它正在被广泛使用。

• 源于：Introduction to HTTP Multipart