Tomcat 對靜態資源的處理

Tomcat 中的請求都是由 Servlet 處理，靜態資源也不例外。在默認的 web.xml 中，配置了一個 DefaultServlet 用於處理靜態資源，它支持緩存和斷點續傳。

DefaultServlet 的基本處理過程以下：

1. 查找資源是否存在緩存
2. 檢查是否知足可選 If 頭域指定的條件
3. 設置響應頭域，如 Content-Type、Content-Length、ETag、Last-Modified
4. 檢查是否知足 Sendfile 的條件，不然將內容拷貝到輸出流中

接下來主要分析資源緩存的設計和實現，以及 If 頭域的處理。

1. 資源緩存的設計

訪問磁盤的速度遠遠低於訪問內存的速度，因此適當的緩存一部分靜態資源可以讓系統快速響應。

Tomcat 在 6.0.53 版本實現靜態資源的處理時，藉助了 JNDI 的一些 API（但在使用時感受與 JNDI 的關係不大），相關類圖及核心方法和屬性以下：

緩存相關的類：

• ResourceCache: 緩存實現，提供了資源查找、加載、銷燬的功能
• CacheEntry: 一個緩存條目，包含緩存名稱，如 /tomcat.gif，資源和資源的屬性以及對應的目錄

資源目錄相關的類是：

• EmptyDirContext: 主要用於嵌入式模式，行爲就像沒有可用資源同樣
• FileDirContext: 基於文件系統的資源目錄服務
• WARDirContext: 基於 war 文件的目錄服務
• Resource: 封裝了資源內容，主要有字節數據和輸入流
• ResourceAttributes: 資源屬性，主要有內容長度和最後修改時間
• ProxyDirContext: 資源緩存和目錄服務的代理，提供查找資源緩存、校驗緩存是否過時等功能

默認狀況下，緩存最大爲 10 MB，單個緩存資源最大爲 512 KB，緩存的 TTL 爲 5s。

通常的，在 Mapper 映射處處理靜態資源的 Wrapper 時，會引發資源的加載，基本的方法調用狀況以下：

Mapper.map(MessageBytes, MessageBytes, MappingData)
└─Mapper.internalMap(CharChunk, CharChunk, MappingData)
 └─Mapper.internalMapWrapper(Mapper$Context, CharChunk, MappingData)
  └─ProxyDirContext.lookup(String)
   └─ProxyDirContext.cacheLookup(String)
    └─ResourceCache.lookup(String)
     └─ResourceCache.find(CacheEntry[], String)

緩存資源插入內部數組時是有序的，find 方法就是經過資源名二分查找緩存，資源名就是請求路徑，此時有兩種狀況，緩存命中和未命中。

緩存未命中，在 cacheLookup 方法中會新建一個 CacheEntry 對象，調用 cacheLoad 方法加入到 ResourceCache 的緩存數組中，加入前會對緩存條目進行如下操做：

• 獲取並初始化緩存資源屬性，主要是文件的 contentLength 和 lastModified
• 若是文件長度小於 512KB，那麼將文件內容加載到內存中
• 標記緩存存在，設置緩存時間戳

緩存命中，會對緩存條目進行校驗：

• 檢查是否過時，當前時間大於緩存條目設置的時間戳
• 若是過時，再檢查資源內容是否修改
• 若是修改，清除這個緩存，讀取最新內容

以上就是資源緩存簡單的處理過程。本文首發於微信公衆號：頓悟源碼，交流QQ羣：673986158

2. If 頭域的處理

客戶端接收並緩存請求的資源，，當再次請求此資源時，服務端根據特定的請求頭域來驗證資源是否修改，沒有變更，則只返回一個 304 Not Modified 響應，不然返回資源的內容，從而節省帶寬。

用於資源驗證的頭域有兩種，分別是：Last-Modified+If-Modified-Since 和 ETag+If-None-Match。

Last-Modified+If-Modified-Since，單位是秒，這個容易理解，若是服務端資源的最後修改時間小於 If-Modified-Since 的值，表示資源無變更。與 If-Modified-Since 對應的有個 If-Unmodified-Since，它相似一個斷言，小於此時間戳的資源才返回，大於等於的話會返回 412 Precondition Failed 的錯誤。

使用時間戳校驗有幾個弊端：

• 文件有可能只改變修改時間，內容不變
• 文件在秒如下的時間修改沒法判斷
• 服務器可能不能精確獲取文件的最後修改時間。

所以，HTTP 引入了 ETag。ETag(Entity Tags) 資源惟一標識，可看作服務端爲資源生成的一個 Token，用於校驗資源是否修改。HTTP 只規定 ETag 要放在雙引號內，沒有規定內容是什麼或者要怎麼實現，Tomcat 生成 ETag 的邏輯是 "W/\"" + contentLength + "-" + lastModified + "\""，其中 'W/' 表示大小寫敏感。

ETag+If-None-Match，If-None-Match 的值由一個或多個 ETag 組成，多個以逗號分割，若是服務端資源的 ETag 與其中的任何一個都不匹配，表示請求的資源有修改；不然無變更。它還有一個特殊值-星號（*），只在資源上傳時使用，一般是 PUT 方法，檢查是否已經上傳過。

此外 If-None-Match 的優先級高於 If-Modified-Since，也就是說，存在 If-None-Match 就不對最後修改時間進行校驗。與 If-None-Match 相對的有個 If-Match，它也相似斷言，只有資源的 ETag 匹配時才認爲沒有修改，一般用於斷點續傳。

Tomcat 實現此部分的核心代碼以下：

// 返回 true 是才認爲資源有變更
protected boolean checkIfHeaders(HttpServletRequest request,
    HttpServletResponse response,ResourceAttributes resourceAttributes)
    throws IOException {
  return checkIfMatch(request, response, resourceAttributes)
    && checkIfModifiedSince(request, response, resourceAttributes)
    && checkIfNoneMatch(request, response, resourceAttributes)
    && checkIfUnmodifiedSince(request, response, resourceAttributes);
}

2.1 一次請求流程

以請求 /main.css 靜態資源爲例，第一次請求響應頭信息以下：

HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Accept-Ranges: bytes
ETag: W/"72259-1557127244000"
Last-Modified: Mon, 06 May 2019 07:20:44 GMT
Content-Type: text/css
Content-Length: 72259
Date: Mon, 06 May 2019 07:20:57 GMT

第二次請求時，首先看一下請求頭域關鍵信息：

Cache-Control:max-age=0
Connection:keep-alive
Host:localhost:8080
If-Modified-Since:Mon, 06 May 2019 07:20:44 GMT
If-None-Match:W/"72259-1557127244000"

服務器收到請求後就會比對 ETag，這裏匹配成功，表示資源沒有修改，響應以下：

HTTP/1.1 304 Not Modified
Server: Apache-Coyote/1.1
ETag: W/"72259-1557127244000"
Date: Mon, 06 May 2019 07:21:46 GMT

注意：在復現時，要使用文本類型，若是使用 Chrome 瀏覽器，記得開啓緩存。

2.2 Accept-Ranges

在上文的響應中，服務器設置了一個 Accept-Ranges: bytes 頭，字面理解就是能夠請求資源的一部分字節，客戶端發現有這個頭時，就能夠嘗試斷點續傳。

解析過程就是對 HTTP 規範的實現，這裏不在具體分析了，規範詳細信息可查看 RFC7233#section-2.3.

3. SendFile 的處理

檢查是否支持 SendFile，NIO 模式下支持此操做，也就是零拷貝，此操做會減小一次到應用內存的拷貝，直接從內核將數據寫入通道。Tomcat 在文件大小大於 48KB 時會嘗試使用此方式發送。

4. 小結

Tomcat 對靜態資源處理的實現仍是比較完善的，但仍是略遜色於 Nginx 這類 Web 服務器，由於它們能直接處理靜態資源，而 Tomcat 還要多作一次映射。通常的都會進行動靜分離，讓 Tomcat 專一處理動態請求。