前言
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 的邏輯是 "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 專注處理動態請求。
總結
以上就是這篇文章的全部內容了，希望本文的內容對大家的學習或者工作具有一定的參考學習價值，謝謝大家對腳本之家的支持。
