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

DefaultServlet 的基本處理過程如下：

• 查找資源是否存在緩存
• 檢查是否滿足可選 If 頭域指定的條件
• 設置響應頭域，如 Content-Type、Content-Length、ETag、Last-Modified
• 檢查是否滿足 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，那么將文件內容加載到內存中
• 標記緩存存在，設置緩存時間戳

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

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

以上就是資源緩存簡單的處理過程。

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 的邏輯是[code] "W/\"" + contentLength + "-" + lastModified + "\"" [/code]，其中 '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

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

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

注意：在復現時，要使用文本類型，如果使用 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 專注處理動態請求。