tomcat源码学习-http文件上传

1. 前情交代

一直以来对于http的表单文件上传都没有一个细致的认知, 只是知道tomcat把http协议的解析过程做好了, 我们直接用就好了, 以至于到现在大家都是直接使用springboot开发微服务的时候, 对于表单提交过程中tomcat对multipart/form表单中的文件数据的解析过程更加陌生. 

前两年我所在的小组做过一个基于netty框架实现的http协议转换网关, 其中对于multipart/form表单的解析性能却相比tomcat差距甚远, 后来也是因为对multipart/form表单的解析和参数重组过程的性能实在无法忍受, 我们对该项目做了拆分重构, 选择基于tomcat来实现这一层协议转换. 程序的拆分重构已经完成, 性能上的数据大致是这样子的:

提升前上行数据流速上限: 5MB/s, 5MB以上大表单提交的并发能力: 50

提升后上行数据流速上限: 550MB/s, 5MB以上大表单提交的并发能力: 2000+

也就是说, 请求的解析性能提升了100+倍, 大表单并发支撑能力提升40+倍, 拆分重构的效果大家有目共睹, 从此之后程序再也没有出现内存问题和文件上传的性能问题, 但这也重新勾起了我想了解tomcat如何对multipart/form表单数据解析的. 

本文章就是为了记录下自己对于tomcat源码的学习, 专门针对multipart/form表单中对于文件的处理过程. 由于本人能力有限, 其中肯定有不少不对的地方, 希望大家不吝赐教.

2. 命名问题

从我开始翻阅tomcat源代码开始, 就一直很有挫败感, 因为很难找到decode/encode类似的包或者类, 以至于翻了好几次还没找到协议解析的过程在哪里. 今天脑袋里灵光一闪, 我让postman上传一个超过最大请求阈值的文件, 程序必然报错, 根据报错的地方顺藤摸瓜, 必然能够摸到我想找的地方, 说干就干. 果然得到了下下面的错误堆栈信息:

看到这个错误信息的时候, 恍然大悟: 我已经在netty中太久, 习惯了netty的命名方式, tomcat不是netty, 命名方式是另外的风格, 我要忘了netty才能看到tomcat.

———————————————— 废话完毕 ——————————————————— 

FileItemIteratorImpl类是一个用来实现文件处理的迭代器实现类, 其构造器中一个很重要的方法findNextItem(), 直接可以判断是否还有下一个文件元素.

 这里的FileItem其实就是一个MultipartStream, 因为FileItemIteratorImpl.next()返回的就是一个MultipartStream对象.

而findNextItem方法中很重要的一个点就是getMultiPartStream()

 

 这里MultipartStream的构造器可以看到, 它是对请求体数据流的一个包装器, 因为对于请求头部分的报文做了解析之后, 就可以拿到boundary这个请求体的“分隔符”了, 就具备了解析请求体的最基本条件.

 通过对FileItemIteratorImpl.next()方法的追踪, 可以看到FileUploadBase类中parseRequest这个从名字上看就知道是在解析请求的方法中, 对文件item拿到后, 先在本地尝试创建了临时文件, 然后将文件item的数据流写入到本地临时文件中.

从这一点看, 与netty的不同已经很明显了:

netty: 从将读入的ByteBuf反复喂给RequestDecoder的decode方法, 直到请求数据接收完毕, 这里是一段一段喂给解码器的, 并不是让解码器自己去根据实际情况读的.

tomcat: 从网络数据流中读取数据直接写入到本地临时文件, 这里可以看到这是解码器自己在根据解析的实际情况, 决定是一点一点读取数据(比如请求头这些小数据), 还是一段一段的大口吃进来(对于文件片段).

看到这里, 可以明白, 为什么在multipart/form表单提交大量文件的场景下, tomcat的性能会比netty高那么多, 因为这种场景下, netty的NIO线程是一段一段喂给decoder, 而tomcat是BIO线程模型, 让decoder独占当前线程, 根据当前请求的具体解析情况, 决定读如数据的“节奏”. 换句话说, 不是netty性能不高, 只是netty在对于http大表单的解析不占优势. 这也算是尺有所短, 寸有所长吧, 不同的框架擅长的领域是不同的.