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 已经足够好了,因为它正在被广泛使用。

Logo

开放原子开发者工作坊旨在鼓励更多人参与开源活动,与志同道合的开发者们相互交流开发经验、分享开发心得、获取前沿技术趋势。工作坊有多种形式的开发者活动,如meetup、训练营等,主打技术交流,干货满满,真诚地邀请各位开发者共同参与!

更多推荐