Http 緩衝機制，http緩衝機制

Http 緩衝機制，http緩衝機制
HTTP 緩衝體系

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

1 HTTP/1.1 200 OK2 Cache-Control: no-cache3 Content-Type: image/png4 Last-Modified: Tue, 08 Nov 2016 06:59:00 GMT5 Accept-Ranges: bytes6 Date: Thu, 10 Nov 2016 02:48:50 GMT7 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 OKCache-Control: no-cacheContent-Type: image/pngLast-Modified: Tue, 08 Nov 2016 06:59:00 GMTAccept-Ranges: bytesDate: Thu, 10 Nov 2016 02:48:50 GMTContent-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 OKCache-Control: privateContent-Type: image/pngLast-Modified: Tue, 08 Nov 2016 06:59:00 GMTAccept-Ranges: bytesDate: Thu, 10 Nov 2016 02:48:50 GMTContent-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: privateHTTP Last-Modified Header is present: Tue, 08 Nov 2016 06:59:00 GMTNo 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 報文緩衝頭時，只要能從中精準的分解出緩衝三要素，我們就能非常準確的預判到緩衝設定最終能達到的效果。