关于java:Tomcat-中是怎么处理文件上传的

43次阅读

共计 5074 个字符，预计需要花费 13 分钟才能阅读完成。

先点赞再看，养成好习惯

前言

这两天在另一个社区看到了一个对于 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 架构解析》– 刘光瑞 著

原创不易，禁止未受权的转载。如果我的文章对您有帮忙，就请点赞 / 珍藏 / 关注激励反对一下吧❤❤❤❤❤❤

正文完
java
发表至： java
2021-04-28
 0
hadoop伪分布式安装记录
关于java:简单理解ThreadLocal
关于java:面试阿里美团京东都会被问到的Spring-从基础到源码帮你全搞定
关于java:Java-位运算符与区别案例详解