Tomcat 中是怎么处理文件上传的？

先点赞再看，养成好习惯

前言

这两天在另外一个社区看到了一个关于 Tomcat 的提问，还挺有意思。正好本身以前也没思考过这个问题，今天就结合 Tomcat 机制来聊聊这个“为何”。

本文对 HTTP 协议中的文件上传标准和 Tomcat 机制的分析内容较多，比较基础，不须要的大佬门能够直接跳到文末。

HTTP 协议中的文件上传

众所周知，HTTP 是一个文本协议，那文本协议如何传输文件呢？

直接传……是的就这么简单。文本协议只是在应用层的角度，到了传输层都是数据都是字节，没什么区别，并不用进行额外的编解码。

multipart/form-data 方式

HTTP 协议中仍是规定了一种基于表单的文件上传方式（Form-based File Upload）。在 form 中定义一个 ENCTYPE 属性，值为 multipart/form-data，而后增长一个 type 为 file 的 <input> 标签。

<FORM ENCTYPE="multipart/form-data" ACTION="_URL_" METHOD=POST>

   File to process: <INPUT NAME="userfile1" TYPE="file">

   <INPUT TYPE="submit" VALUE="Send File">

 </FORM>

这个 multipart/form-data 类型的表单和默认的 x-www-form-urlencoded 有些不一样。虽然都做为表单，能够上传多个字段，但前者能够上传文件，后者却只能传输文本

如今来看看这个表单文件上传方式的协议，下图是一个简单的 multipart/form-data 类型的请求报文：

从上图能够看到，HTTP header 部分变化很小，只是在 Content-Type 中增长了一段 boundary 标签；但 payload 部分变化却比较大

boundary 在 multipart/form-data 中做用是分隔表单的多个字段，在 payload 部分中，首尾两行各有一个 boundary，每一个字段（part/item）之间也会有一个 boundary

Server 端在读取时，只须要先从 Content-Type 中拿到 boundary ，而后经过这个 boundary 去拆分 payload 部分就能够获取全部的字段。

每一个字段的报文中，有一个 Content-Disposition字段，做为这个字段的 Header 部分。其中记录了当前字段名（name），若是是文件的话还会有一个 filename 属性，同时再下一行会附带一个 Content-Type 来标识文件的类型

虽然 x-www-form-urlencoded 和 multipart 两种类型的表单均可以完成字段的传输，但 multipart 不只能够传输文本字段，还能够传输文件。并且这个 multipart 传输文件的方式也是“标准”的，各类 Server 均可以支持，直接读取文件。

而 x-www-form-urlencoded 只能够传输基础的文本数据，不过你要是强行把文件当作文本，用这个类型传也没人能拦你，但做为文本传输时后端必然用字符串方式解析，byte -> str 时的编码开销彻底不必，并且可能会致使编码错误……

在 x-www-form-urlencoded 类型的报文中，并无 boundary，多个字段会经过 & 符号拼接，而且对key/value 都进行 urlencode 编码

虽然 x-www-form-urlencoded 增长了异步编码的过程，但不会给每一个字段增长header，也没有 boundary，报文体积相对 multipart 方式来讲小了不少。

除了这个 multipart，还有一种直接上传文件的形式，不过不太经常使用

binary payload 方式

除了 multipart/form-data以外，还有一种 binary payload 的上传方式。这个 binary payload 是我本身起的名字……由于在 HTTP 协议中并无找到这种方式的说明（若是有找到的大佬评论区贴个链接），不过不少 HTTP 客户端都支持。

好比 Postman：

好比 OkHttp：

OkHttpClient client = new OkHttpClient().newBuilder()
  .build();
MediaType mediaType = MediaType.parse("image/png");
RequestBody body = RequestBody.create(mediaType, "<file contents here>");
Request request = new Request.Builder()
  .url("localhost:8098/upload")
  .method("POST", body)
  .addHeader("Content-Type", "image/png")
  .build();
Response response = client.newCall(request).execute();

这种方式很是简单，就是将整个 payload 部分，都用来存放文件数据。以下图所示，整个 payload 部分都是文件内容：

这种方式虽然简单，客户端实现也简单，但……服务端没有很好的支持。好比 Tomcat 中，并不会将这种 binary file 的形式做为文件处理，而是当作普通的报文处理。

Tomcat 处理机制分析

Tomcat 在处理文本形式的报文时，会先读取前面的 Header 部分，解析 Content-Length 来划分报文边界，剩下的 Payload 部分并不会一次性读取，而是包装了一个 InputStream ，在内部调用 Socket read 进行读取 RCV_BUF 的数据（完整报文大小大于 readBuf Size时）

对 HttpServletRequest 调用 getParameter/getInputStream 等涉及 Payload 部分读取操做时，就会进行InputStream 内部的 Socket RCV_BUF 的读取，读取 Payload 的数据。

这种不一次性读取全部数据暂存至内存中的方式，而包装一个 InputStream 内部读取 RCV_BUF 的方式，特色是不存储数据，只是作一个包装，应用层对 ServletRequest#inputStream 的 read 操做会转发到对 Socket RCV_BUF 的read。

不过若是应用层完整的读取了 ServletRequest#inputStream ，而后转字符串，存储至内存中的话，那这就和 Tomcat 没什么关系了。

对于 multipart 类型的请求，Tomcat 处理机制上比较特殊。因为 multipart 是为了传输文件而设计的，因此在处理这种类型请求时，Tomcat 增长了一个暂存文件的概念，在解析报文时，将 multipart 中的数据写入到了磁盘中。

以下图所示，Tomcat 对每个字段都包装为一个 DiskFileItem - org.apache.tomcat.util.http.fileupload.disk.DiskFileItem（这个 DiskFileItem 不区分是文件仍是文本数据）。DiskFileItem 内又分为 Header 部分和 Content 部分。Content 中一部分存储在内存，剩下的存储至磁盘，经过一个 sizeThreshold 进行分割；不过这个值默认为0，也就是说默认会把内容部分所有存储至磁盘。

那既然存储至磁盘，读取时也确定也是从磁盘读取了……效率天然是比较低的。因此若是只是文本型的报文，仍是不要用 multipart 类型来传输了，这个类型会被转存磁盘的。

还有一个冷知识，Tomcat 在处理 multipart 类型的报文时，若是某个字段不是文件，会将这个字段的key/value 添加到 parameterMap 中，也就是说经过 request.getParameter/getParameterMap 能够获取到这些非文件的字段。

//org.apache.catalina.connector.Request#parseParts

if (part.getSubmittedFileName() == null) {
    String name = part.getName();
    String value = null;
    try {
        value = part.getString(charset.name());
    } catch (UnsupportedEncodingException uee) {
        // Not possible
    }
    ......
        parameters.addParameter(name, value);
}

要知道这个 getParameter 是只能获取表单参数（FormParam）和查询参数（QueryString）的，不过 multipart 也是 form，能获取参数好像也没啥毛病……

一个简单的小结

Tomcat 对不一样类型的请求处理方式：

1. 若是参数是 GET queryString方式（url上拼参数），那么全部参数都在报文头中，会一次性所有读取至内存

2. 若是是 POST 类型的报文，Tomcat 只会对读取 Header 部分，Payload 部分不会主动读取，而是将 Socket 包装成一个 InputStream 供应用层 read

   1. x-www-form-urlencoded 这种类型的报文，虽然不会主动读取，但不少 Web 框架（好比 SpringMVC）会调用 getParameter，仍是会出发 InputStream 的read，对 RCV_BUF 进行读取
   2. 上面提到的 binary payload也是同样，Tomcat 并不会主动发起 read 操做，须要应用层调用 ServletRequest#InputStream 进行 read操做读取 RCV_BUF 的数据
   3. multipart 类型的报文，同样不会主动读取，调用HttpServletRequest#getParts 才会触发解析/读取；一样的，不少 Web 框架会调用 getParts，因此会触发解析

为何要先写入临时文件，直接包装 InputStream 交给应用层读取不行吗？

若是应用层不（及时）读取 RCV_BUF，那么当收到的数据写满 RCV_BUF 时，就不会再返回 ACK 了，客户端的的数据也会存储在 SND_BUF 中，没法继续发送数据，当 SND_BUF 被应用层写满时，这条链接就被阻塞了。

如下缘由是我的见解，没有官方文献的支持，若有不一样意见欢迎评论区留言讨论

因为 multipart 通常是用于传输文件，但文件大小一般会远大于 Socket Buffer 的容量。因此，为了避免阻塞 TCP 链接，Tomcat 会一次性读取完整的 Payload 部分，而后将其中全部的 Part 存储至磁盘（Header在内存中，内容在磁盘）。

应用层只须要再从 Tomcat 提供的 DiskFileItem 读取 Part 数据便可，这样看起来虽然中转了一层，但 RCV_BUF 中的数据却能够被及时消费了。

从效率上说，中转+存磁盘这种操做，必定比不中转要慢的多，不过能够及时消费 RCV_BUF，保证 TCP 链接不被阻塞。

若是是在 HTTP2 的多路复用下，多个请求都使用同一个 TCP 链接，若是 RCV_BUF 没有及时消费，那么还会致使全部的“逻辑 HTTP 链接”都阻塞

那为何其余类型的报文不用暂存磁盘呢？

由于报文小啊，普通的请求报文不会太大的，常见的也就几K 到几十K ，并且对于纯文本报文来讲，读取操做必定也是及时的且一次性所有读取的，而 multipart 这种形式的报文不一样，它是文本+文件混合的方式，并且还多是多文件。

好比服务端在接收到文件后，还须要对文件进行转存，转存到某些云厂商的对象存储服务中，那么此时有两种转存方式：

1. 接收到完整文件数据，存储至内存中，而后调用对象存储的SDK
2. 用流的方式，一边 read ServletRequest#InputStream，一边 write 到 SDK 的 OutputStream 中

方式 1，虽然及时读取了 RCV_BUF，可是内存占用过大，很容易把内存撑爆，很是不合理
方式 2，虽然内存占用很小（最多只有一个 Read Buffer 的大小），但因为是边读边写，两边都是网络，会致使 RCV_BUF 不能及时消费完成。

并且不光是 Tomcat ，连 Jetty 也是这么处理 multipart，其余 Web Server 虽然没看，但我想应该都会这么处理。

参考

• Apache Tomcat
• Form-based File Upload in HTML - IETF
• 《Tomcat 架构解析》 - 刘光瑞 著

原创不易，禁止未受权的转载。若是个人文章对您有帮助，就请点赞/收藏/关注鼓励支持一下吧❤❤❤❤❤❤