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 架構解析》 - 劉光瑞 著

原創不易，禁止未受權的轉載。若是個人文章對您有幫助，就請點贊/收藏/關注鼓勵支持一下吧❤❤❤❤❤❤