Http 緩存機制

HTTP 緩存體系

首先我將 Http 緩存體系分為以下三個部分：

1 HTTP/1.1 200 OK
2 Cache-Control: no-cache
3 Content-Type: image/png
4 Last-Modified: Tue, 08 Nov 2016 06:59:00 GMT
5 Accept-Ranges: bytes
6 Date: Thu, 10 Nov 2016 02:48:50 GMT
7 Content-Length: 3534

1. 緩存存儲策略

用來確定 Http 響應內容是否可以被客戶端緩存，以及可以被哪些客戶端緩存

這個策略的作用只有一個，用於決定 Http 響應內容是否可緩存到客戶端

對於 Cache-Control 頭裡的 Public、Private、no-cache、max-age 、no-store 他們都是用來指明響應內容是否可以被客戶端存儲的，其中前4個都會緩存文件數據（關於 no-cache 應理解為“不建議使用本地緩存”，其仍然會緩存數據到本地），後者 no-store 則不會在客戶端緩存任何響應數據。另關於 no-cache 和 max-age 有點特別，我認為它是一種混合體，下麵我會講到。

通過 Cache-Control：Public 設置我們可以將 Http 響應數據存儲到本地，但此時並不意味著後續瀏覽器會直接從緩存中讀取數據並使用，為啥？因為它無法確定本地緩存的數據是否可用（可能已經失效），還必須藉助一套鑒別機制來確認才行， 這就是我們下麵要講到的“緩存過期策略”。

2. 緩存過期策略

客戶端用來確認存儲在本地的緩存數據是否已過期，進而決定是否要發請求到服務端獲取數據

這個策略的作用也只有一個，那就是決定客戶端是否可直接從本地緩存數據中載入數據並展示（否則就發請求到服務端獲取）

剛上面我們已經闡述了數據緩存到了本地後還需要經過判斷才能使用，那麼瀏覽器通過什麼條件來判斷呢？ 答案是：Expires，Expires 指名了緩存數據有效的絕對時間，告訴客戶端到了這個時間點（比照客戶端時間點）後本地緩存就作廢了，在這個時間點內客戶端可以認為緩存數據有效，可直接從緩存中載入展示。

不過 Http 緩存頭設計並沒有想象的那麼規矩，像上面提到的 Cache-Control（這個頭是在Http1.1裡加進來的）頭裡的 no-cache 和 max-age 就是特例，它們既包含緩存存儲策略也包含緩存過期策略，以 max-age 為例，他實際上相當於：

Cache-Control：public/private（這裡不太確定具體哪個）
Expires：當前客戶端時間 + maxAge 。

而 Cache-Control：no-cache 和 Cache-Control：max-age=0 （單位是秒）相當

這裡需要註意的是：

1. Cache-Control 中指定的緩存過期策略優先順序高於 Expires，當它們同時存在的時候，後者會被覆蓋掉。

2. 緩存數據標記為已過期只是告訴客戶端不能再直接從本地讀取緩存了，需要再發一次請求到伺服器去確認，並不等同於本地緩存數據從此就沒用了，有些情況下即使過期了還是會被再次用到，具體下麵會講到。

3. 緩存對比策略

將緩存在客戶端的數據標識發往服務端，服務端通過標識來判斷客戶端 緩存數據是否仍有效，進而決定是否要重發數據。

客戶端檢測到數據過期或瀏覽器刷新後，往往會重新發起一個 http 請求到伺服器，伺服器此時並不急於返回數據，而是看請求頭有沒有帶標識（ If-Modified-Since、If-None-Match）過來，如果判斷標識仍然有效，則返回304告訴客戶端取本地緩存數據來用即可（這裡要註意的是你必須要在首次響應時輸出相應的頭信息（Last-Modified、ETags）到客戶端）。至此我們就明白了上面所說的本地緩存數據即使被認為過期，並不等於數據從此就沒用了的道理了。

關於 Last-Modified，這個響應頭使用要註意，可能會影響到緩存過期策略，具體原因，後面我會通過解答開篇提到的2道題來作說明。

以上就是我所認識的緩存策略，下麵我將緩存策略三要素和常用的幾個緩存頭（項）結合一起，讓大家更清晰的認識到它們之間的關係：

通過上圖我可以清晰的看到各緩存項分別屬於哪個緩存策略範疇，這其中有部分重疊，它表明這些緩存項具有多重緩存策略，所以實際在分析緩存頭的時候，除了常規的頭外，我們還需要將這些具有雙重緩存策略的項分解開來。

最後我們回到最開始提到的2道題目，我們來一起分解下：

第一道題：

HTTP/1.1 200 OK
Cache-Control: no-cache
Content-Type: image/png
Last-Modified: Tue, 08 Nov 2016 06:59:00 GMT
Accept-Ranges: bytes
Date: Thu, 10 Nov 2016 02:48:50 GMT
Content-Length: 3534

分析上述 Http 響應頭髮現有以下兩項與緩存相關：

Cache-Control: no-cache 
Last-Modified: Tue, 08 Nov 2016 06:59:00 GMT

我們上面講到了 Cache-Control: no-cache 相當於 Cache-Control: max-age=0，且他們都是多重策略頭，我們需將其分解：

Cache-Control: no-cache 等於 Cache-Control: max-age=0，
接著 Cache-Control: max-age=0 又可分解成：

Cache-Control: public/private （不確定是二者中的哪一個）
Expires: 當前時間

最終我們得到了以下完整的緩存策略三要素：

所以最終結果是：瀏覽器會再次請求服務端，並攜帶上 Last-Modified 指定的時間去伺服器對比：

• a）對比失敗：伺服器返回200並重發數據，客戶端接收到數據後展示，並刷新本地緩存。

• b）對比成功：伺服器返回304且不重發數據，客戶端收到304狀態碼後從本地讀取緩存數據。以下為模擬此種情況下請求後的抓包情況：

這道題本身不難，但若認為 no-cache 不會緩存數據到本地，那麼你理解起來就會很矛盾，因為如果文件數據沒有被本地緩存，伺服器返回304後將會無法展示出圖片內容，但實際上它是能正常展示的。這道題很好的證明瞭 no-cache 也會緩存數據到本地這一說法。

第二道題：

HTTP/1.1 200 OK
Cache-Control: private
Content-Type: image/png
Last-Modified: Tue, 08 Nov 2016 06:59:00 GMT
Accept-Ranges: bytes
Date: Thu, 10 Nov 2016 02:48:50 GMT
Content-Length: 3534

解題思路和上題一樣，首先先找到緩存相關項：

Cache-Control: private     
Last-Modified: Tue, 08 Nov 2016 06:59:00 GMT

這時我們會發現根本找不到緩存過期策略項，那答案會不會和上面一樣？ 一時半會也分析不出答案，那隻能實際測試下了：

再看看 Chrome 瀏覽器下抓包：

可以看到，瀏覽器後續請求都直接取的本地緩存，看來的確存在某種緩存過期策略（根據我上面的緩存過期策略理論，瀏覽器如果直接從本地載入緩存數據，說明它相信本地緩存數據有效，那一定存在某種緩存過期判斷條件）。這個問題百思不得其解，困擾了我好久，直到一次偶然的機會我在 Fiddler 響應信息面板里的 Caching 選項卡中找到了答案：

原來，在沒有提供任何瀏覽器緩存過期策略的情況下，瀏覽器遵循一個啟髮式緩存過期策略：

根據響應頭中2個時間欄位 Date 和 Last-Modified 之間的時間差值，取其值的10%作為緩存時間周期。

貼一下Caching面板里的描述，英語好的同學可以精準翻譯下：

HTTP/1.1 Cache-Control Header is present: private
HTTP Last-Modified Header is present: Tue, 08 Nov 2016 06:59:00 GMT
No explicit HTTP Cache Lifetime information was provided.
Heuristic expiration policies suggest defaulting to: 10% of the delta between Last-Modified and Date.
That's '05:15:02' so this response will heuristically expire 2016/11/11 0:46:01.

最終我們得到了以下完整的緩存策略三要素：

最終結果

瀏覽器會根據 Date 和 Last-Modified 之間的時間差值緩存一段時間，這段時間內會直接使用本地緩存數據而不會再去請求伺服器（強制請求除外），緩存過期後，會再次請求服務端，並攜帶上 Last-Modified 指定的時間去伺服器對比並根據服務端的響應狀態決定是否要從本地載入緩存數據。

總結

Http 緩存設置起來並不複雜，但卻容易被輕視， 今天這篇文章結合2道題目，通過分析、解剖相關緩存頭，從系統化角度對 Http 緩存機製做了一個較完整的剖析：Http 緩存機制實際上是 Http 緩存策略三個要素（緯度）相互作用的集合，所以在分析和設置 Http 報文緩存頭時，只要能從中精準的分解出緩存三要素，我們就能非常準確的預判到緩存設置最終能達到的效果。