tomcat上传文件超过大小限制 tomcat修改上传文件大小限制



文章插图
tomcat上传文件超过大小限制 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="http://www.mnbkw.com/jxjc/168188/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#parsePartsif (part.getSubmittedFileName() == null) {String name = part.getName();String value = http://www.mnbkw.com/jxjc/168188/null;try {value = part.getString(charset.name());} catch (UnsupportedEncodingException uee) {// Not possible}......parameters.addParameter(name, value);}要知道这个 getParameter 是只能获取表单参数(FormParam)和查询参数(QueryString)的,不过 multipart 也是 form,能获取参数好像也没啥毛病……
一个简单的小结
Tomcat 对不同类型的请求处理方式:
如果参数是 GET queryString方式(url上拼参数),那么所有参数都在报文头中,会一次性全部读取至内存如果是 POST 类型的报文,Tomcat 只会对读取 Header 部分,Payload 部分不会主动读取,而是将 Socket 包装成一个 InputStream 供应用层 readx-www-form-urlencoded 这种类型的报文,虽然不会主动读取,但很多 Web 框架(比如 SpringMVC)会调用 getParameter,还是会出发 InputStream 的read,对 RCV_BUF 进行读取上面提到的 binary payload也是一样,Tomcat 并不会主动发起 read 操作,需要应用层调用 ServletRequest#InputStream 进行 read操作读取 RCV_BUF 的数据multipart 类型的报文,一样不会主动读取,调用HttpServletRequest#getParts 才会触发解析/读取;同样的,很多 Web 框架会调用 getParts,所以会触发解析为什么要先写入临时文件,直接包装 InputStream 交给应用层读取不行吗?
如果应用层不(及时)读取 RCV_BUF,那么当收到的数据写满 RCV_BUF 时,就不会再返回 ACK 了,客户端的的数据也会存储在 SND_BUF 中,无法继续发送数据,当 SND_BUF 被应用层写满时,这条连接就被阻塞了 。
【tomcat上传文件超过大小限制 tomcat修改上传文件大小限制】由于 multipart 一般是用于传输文件,但文件大小通常会远大于 Socket Buffer 的容量 。所以,为了不阻塞 TCP 连接,Tomcat 会一次性读取完整的 Payload 部分,然后将其中所有的 Part 存储至磁盘(Header在内存中,内容在磁盘) 。
应用层只需要再从 Tomcat 提供的 DiskFileItem 读取 Part 数据即可,这样看起来虽然中转了一层,但 RCV_BUF 中的数据却可以被及时消费了 。
从效率上说,中转+存磁盘这种操作,一定比不中转要慢的多,不过可以及时消费 RCV_BUF,保证 TCP 连接不被阻塞 。
如果是在 HTTP2 的多路复用下,多个请求都使用同一个 TCP 连接,如果 RCV_BUF 没有及时消费,那么还会导致所有的“逻辑 HTTP 连接”都阻塞
那为什么其他类型的报文不用暂存磁盘呢?
因为报文小啊,普通的请求报文不会太大的,常见的也就几K 到几十K,而且对于纯文本报文来说,读取操作一定也是及时的且一次性全部读取的,而 multipart 这种形式的报文不同,它是文本+文件混合的方式,而且还可能是多文件 。
比如服务端在接收到文件后,还需要对文件进行转存,转存到某些云厂商的对象存储服务中,那么此时有两种转存方式:
接收到完整文件数据,存储至内存中,然后调用对象存储的SDK用流的方式,一边 read ServletRequest#InputStream,一边 write 到 SDK 的 OutputStream 中
方式 1,虽然及时读取了 RCV_BUF,但是内存占用过大,很容易把内存撑爆,非常不合理 方式 2,虽然内存占用很小(最多只有一个 Read Buffer 的大小),但由于是边读边写,两边都是网络,会导致 RCV_BUF 不能及时消费完成 。
而且不光是 Tomcat,连 Jetty 也是这么处理 multipart,其他 Web Server 虽然没看,但我想应该都会这么处理 。