【騰訊Bugly乾貨分享】完全弄懂 Http 緩存機制 - 基於緩存策略三要素分解法

時間 2019-11-13

標籤騰訊Bugly乾貨分享完全弄懂 http 緩存機制基於策略要素分解欄目 HTTP/TCP 简体版

原文原文鏈接

本文來自於騰訊Bugly公衆號（weixinBugly），未經做者贊成，請勿轉載，原文地址：https://mp.weixin.qq.com/s/qOMO0LIdA47j3RjhbCWUEQhtml

做者：李志剛web

導語

Http 緩存機制做爲 web 性能優化的重要手段，對從事 Web 開發的小夥伴們來講是必需要掌握的知識，但最近我遇到了幾個緩存頭設置相關的題目，發現有好幾道題答錯了，有的甚至在知道了正確答案後依然不明白其緣由，可謂至關的鬱悶呢！！爲了確認下是否只是本身理解不深，我特地請教了其餘幾位小夥伴，發現狀況也或多或少和我相似。瀏覽器

爲了避免給你們賣關子，下面我貼出2道題，你們能夠嘗試解答下：緩存

如下爲 page.html 內容：性能優化

<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
    <title>page頁</title>
</head>
<body>
    <img src="images/head.png" />
    <a href="page.html">從新訪問page頁</a>
</body>
</html>

首次訪問該頁面，頁面中 head.png 響應頭信息以下：服務器

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

問題1：請問當點擊「從新訪問 page 頁」連接從新加載該頁面後， head.png 如何二次加載？微信
問題2：若是將上述信息中的 Cache-Control 設置爲 private，那麼結果又會如何呢？ide

以上2道題，若是你能所有答對（哈哈，還請仔細確認下 why，以防歪打正着），那麼恭喜你，你已對這些知識理解很是透徹了，我後面講的內容你能夠忽略，不然還請繼續陪我往下嘮嘮吧！工具

首先回到開篇提到不少小夥伴（包括我）在解答 Http 緩存題目時栽跟頭的問題，我以爲出現這種現象的根本緣由在於咱們吸取的知識還不夠體系化，平時咱們在學習這些知識時多半將其看成知識點來記，什麼這個緩存頭做什麼、那個緩存頭做什麼用的，但實際中緩存頭每每是多個之間相互配合協同工做的，有一套完整的工做體系。性能

今天我將按本身的理解，從系統體系化角度來說講 Http 緩存頭是如何協同工做的（不正確的地方還請指正，但請不要噴我哦）：

HTTP 緩存體系

首先我將 Http 緩存體系分爲如下三個部分：

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 （單位是秒）至關

這裏須要注意的是：

Cache-Control 中指定的緩存過時策略優先級高於 Expires，當它們同時存在的時候，後者會被覆蓋掉。
緩存數據標記爲已過時只是告訴客戶端不能再直接從本地讀取緩存了，須要再發一次請求到服務器去確認，並不等同於本地緩存數據今後就沒用了，有些狀況下即便過時了仍是會被再次用到，具體下面會講到。

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 報文緩存頭時，只要能從中精準的分解出緩存三要素，咱們就能很是準確的預判到緩存設置最終能達到的效果。

更多精彩內容歡迎關注騰訊 Bugly的微信公衆帳號：

騰訊 Bugly是一款專爲移動開發者打造的質量監控工具，幫助開發者快速，便捷的定位線上應用崩潰的狀況以及解決方案。智能合併功能幫助開發同窗把天天上報的數千條 Crash 根據根因合併分類，每日日報會列出影響用戶數最多的崩潰，精準定位功能幫助開發同窗定位到出問題的代碼行，實時上報能夠在發佈後快速的瞭解應用的質量狀況，適配最新的 iOS, Android 官方操做系統，鵝廠的工程師都在使用，快來加入咱們吧！