彻底弄懂 HTTP 缓存机制 —— 基于缓存策略三要素分解法
導語
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，那么結果又會如何呢？
以上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 （單位是秒）相當
這里需要注意的是：
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 又可分解成：
最終我們得到了以下完整的緩存策略三要素：
所以最終結果是：瀏覽器會再次請求服務端，并攜帶上 Last-Modified 指定的時間去服務器對比：
- 對比失敗：服務器返回200并重發數據，客戶端接收到數據后展示，并刷新本地緩存。
- 對比成功：服務器返回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 報文緩存頭時，只要能從中精準的分解出緩存三要素，我們就能非常準確的預判到緩存設置最終能達到的效果。
了解最新移動開發相關信息和技術，請關注 mobilehub 公眾微信號（ID: mobilehub)。
騰訊 Bugly是一款專為移動開發者打造的質量監控工具，幫助開發者快速，便捷的定位線上應用崩潰的情況以及解決方案。智能合并功能幫助開發同學把每天上報的數千條?Crash?根據根因合并分類，每日日報會列出影響用戶數最多的崩潰，精準定位功能幫助開發同學定位到出問題的代碼行，實時上報可以在發布后快速的了解應用的質量情況，適配最新的 iOS, Android 官方操作系統，鵝廠的工程師都在使用，快來加入我們吧！
from:?http://geek.csdn.net/news/detail/131318
總結
以上是生活随笔為你收集整理的彻底弄懂 HTTP 缓存机制 —— 基于缓存策略三要素分解法的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 谈谈 Python 程序的运行原理
- 下一篇： JVM 调优 —— GC 长时间停顿问题