彻底弄懂 HTTP 缓存机制 —— 基于缓存策略三要素分解法
導(dǎo)語
HTTP 緩存機(jī)制作為 Web 性能優(yōu)化的重要手段，對從事 Web 開發(fā)的小伙伴們來說是必須要掌握的知識，但最近我遇到了幾個緩存頭設(shè)置相關(guān)的題目，發(fā)現(xiàn)有好幾道題答錯了，有的甚至在知道了正確答案后依然不明白其原因，可謂相當(dāng)?shù)挠魫災(zāi)?#xff01;！為了確認(rèn)下是否只是自己理解不深，我特意請教了其他幾位小伙伴，發(fā)現(xiàn)情況也或多或少和我類似。
為了不給大家賣關(guān)子，下面我貼出2道題，大家可以嘗試解答下：
以下為?page.html?內(nèi)容：
<!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?響應(yīng)頭信息如下：
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：請問當(dāng)點(diǎn)擊“重新訪問 page 頁”鏈接重新加載該頁面后， head.png 如何二次加載？
-
問題2：如果將上述信息中的 Cache-Control 設(shè)置為 private，那么結(jié)果又會如何呢？
以上2道題，如果你能全部答對（哈哈，還請仔細(xì)確認(rèn)下 why，以防歪打正著），那么恭喜你，你已對這些知識理解非常透徹了，我后面講的內(nèi)容你可以忽略，否則還請繼續(xù)陪我往下嘮嘮吧！
首先回到開篇提到很多小伙伴（包括我）在解答 HTTP 緩存題目時栽跟頭的問題，我覺得出現(xiàn)這種現(xiàn)象的根本原因在于我們吸收的知識還不夠體系化，平時我們在學(xué)習(xí)這些知識時多半將其當(dāng)作知識點(diǎn)來記，什么這個緩存頭作什么、那個緩存頭作什么用的，但實(shí)際中緩存頭往往是多個之間相互配合協(xié)同工作的，有一套完整的工作體系。
今天我將按自己的理解，從系統(tǒng)體系化角度來講講 HTTP 緩存頭是如何協(xié)同工作的（不正確的地方還請指正，但請不要噴我哦）：
HTTP 緩存體系
首先我將 HTTP 緩存體系分為以下三個部分：
1. 緩存存儲策略
用來確定 HTTP 響應(yīng)內(nèi)容是否可以被客戶端緩存，以及可以被哪些客戶端緩存。
這個策略的作用只有一個，用于決定 HTTP 響應(yīng)內(nèi)容是否可緩存到客戶端
對于 Cache-Control 頭里的 Public、Private、no-cache、max-age 、no-store 他們都是用來指明響應(yīng)內(nèi)容是否可以被客戶端存儲的，其中前4個都會緩存文件數(shù)據(jù)（關(guān)于 no-cache 應(yīng)理解為“不建議使用本地緩存”，其仍然會緩存數(shù)據(jù)到本地），后者 no-store 則不會在客戶端緩存任何響應(yīng)數(shù)據(jù)。另關(guān)于 no-cache 和 max-age 有點(diǎn)特別，我認(rèn)為它是一種混合體，下面我會講到。
通過 Cache-Control：Public 設(shè)置我們可以將 HTTP 響應(yīng)數(shù)據(jù)存儲到本地，但此時并不意味著后續(xù)瀏覽器會直接從緩存中讀取數(shù)據(jù)并使用，為啥？因?yàn)樗鼰o法確定本地緩存的數(shù)據(jù)是否可用（可能已經(jīng)失效），還必須借助一套鑒別機(jī)制來確認(rèn)才行， 這就是我們下面要講到的“緩存過期策略”。
2. 緩存過期策略
客戶端用來確認(rèn)存儲在本地的緩存數(shù)據(jù)是否已過期，進(jìn)而決定是否要發(fā)請求到服務(wù)端獲取數(shù)據(jù)
這個策略的作用也只有一個，那就是決定客戶端是否可直接從本地緩存數(shù)據(jù)中加載數(shù)據(jù)并展示（否則就發(fā)請求到服務(wù)端獲取）
剛上面我們已經(jīng)闡述了數(shù)據(jù)緩存到了本地后還需要經(jīng)過判斷才能使用，那么瀏覽器通過什么條件來判斷呢？ 答案是：Expires，Expires 指名了緩存數(shù)據(jù)有效的絕對時間，告訴客戶端到了這個時間點(diǎn)（比照客戶端時間點(diǎn)）后本地緩存就作廢了，在這個時間點(diǎn)內(nèi)客戶端可以認(rèn)為緩存數(shù)據(jù)有效，可直接從緩存中加載展示。
不過 HTTP 緩存頭設(shè)計并沒有想象的那么規(guī)矩，像上面提到的 Cache-Control（這個頭是在HTTP1.1里加進(jìn)來的）頭里的 no-cache 和 max-age 就是特例，它們既包含緩存存儲策略也包含緩存過期策略，以 max-age 為例，它實(shí)際上相當(dāng)于：
Cache-Control：public/private（這里不太確定具體哪個） Expires：當(dāng)前客戶端時間 + maxAge 。而 Cache-Control：no-cache 和 Cache-Control：max-age=0 （單位是秒）相當(dāng)
這里需要注意的是：
3. 緩存對比策略
將緩存在客戶端的數(shù)據(jù)標(biāo)識發(fā)往服務(wù)端，服務(wù)端通過標(biāo)識來判斷客戶端 緩存數(shù)據(jù)是否仍有效，進(jìn)而決定是否要重發(fā)數(shù)據(jù)。
客戶端檢測到數(shù)據(jù)過期或?yàn)g覽器刷新后，往往會重新發(fā)起一個 http 請求到服務(wù)器，服務(wù)器此時并不急于返回數(shù)據(jù)，而是看請求頭有沒有帶標(biāo)識（ If-Modified-Since、If-None-Match）過來，如果判斷標(biāo)識仍然有效，則返回304告訴客戶端取本地緩存數(shù)據(jù)來用即可（這里要注意的是你必須要在首次響應(yīng)時輸出相應(yīng)的頭信息（Last-Modified、ETags）到客戶端）。至此我們就明白了上面所說的本地緩存數(shù)據(jù)即使被認(rèn)為過期，并不等于數(shù)據(jù)從此就沒用了的道理了。
關(guān)于 Last-Modified，這個響應(yīng)頭使用要注意，可能會影響到緩存過期策略，具體原因，后面我會通過解答開篇提到的2道題來作說明。
以上就是我所認(rèn)識的緩存策略，下面我將緩存策略三要素和常用的幾個緩存頭（項(xiàng)）結(jié)合一起，讓大家更清晰的認(rèn)識到它們之間的關(guān)系：
通過上圖我可以清晰的看到各緩存項(xiàng)分別屬于哪個緩存策略范疇，這其中有部分重疊，它表明這些緩存項(xiàng)具有多重緩存策略，所以實(shí)際在分析緩存頭的時候，除了常規(guī)的頭外，我們還需要將這些具有雙重緩存策略的項(xiàng)分解開來。
最后我們回到最開始提到的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 響應(yīng)頭發(fā)現(xiàn)有以下兩項(xiàng)與緩存相關(guān)：
Cache-Control: no-cache Last-Modified: Tue, 08 Nov 2016 06:59:00 GMT我們上面講到了 Cache-Control: no-cache 相當(dāng)于 Cache-Control: max-age=0，且他們都是多重策略頭，我們需將其分解：
Cache-Control: no-cache 等于 Cache-Control: max-age=0，?
接著 Cache-Control: max-age=0 又可分解成：
最終我們得到了以下完整的緩存策略三要素：
所以最終結(jié)果是：瀏覽器會再次請求服務(wù)端，并攜帶上 Last-Modified 指定的時間去服務(wù)器對比：
- 對比失敗：服務(wù)器返回200并重發(fā)數(shù)據(jù)，客戶端接收到數(shù)據(jù)后展示，并刷新本地緩存。
- 對比成功：服務(wù)器返回304且不重發(fā)數(shù)據(jù)，客戶端收到304狀態(tài)碼后從本地讀取緩存數(shù)據(jù)。以下為模擬此種情況下請求后的抓包情況：
這道題本身不難，但若認(rèn)為 no-cache 不會緩存數(shù)據(jù)到本地，那么你理解起來就會很矛盾，因?yàn)槿绻募?shù)據(jù)沒有被本地緩存，服務(wù)器返回304后將會無法展示出圖片內(nèi)容，但實(shí)際上它是能正常展示的。這道題很好的證明了 no-cache 也會緩存數(shù)據(jù)到本地這一說法。
第二道題：
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解題思路和上題一樣，首先先找到緩存相關(guān)項(xiàng)：
Cache-Control: private Last-Modified: Tue, 08 Nov 2016 06:59:00 GMT這時我們會發(fā)現(xiàn)根本找不到緩存過期策略項(xiàng)，那答案會不會和上面一樣？ 一時半會也分析不出答案，那只能實(shí)際測試下了：
再看看 Chrome 瀏覽器下抓包：
可以看到，瀏覽器后續(xù)請求都直接取的本地緩存，看來的確存在某種緩存過期策略（根據(jù)我上面的緩存過期策略理論，瀏覽器如果直接從本地加載緩存數(shù)據(jù)，說明它相信本地緩存數(shù)據(jù)有效，那一定存在某種緩存過期判斷條件）。這個問題百思不得其解，困擾了我好久，直到一次偶然的機(jī)會我在 Fiddler 響應(yīng)信息面板里的 Caching 選項(xiàng)卡中找到了答案：
原來，在沒有提供任何瀏覽器緩存過期策略的情況下，瀏覽器遵循一個啟發(fā)式緩存過期策略：
根據(jù)響應(yīng)頭中2個時間字段 Date 和 Last-Modified 之間的時間差值，取其值的10%作為緩存時間周期。
貼一下 Caching 面板里的描述，英語好的同學(xué)可以精準(zhǔn)翻譯下：
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.最終我們得到了以下完整的緩存策略三要素：
最終結(jié)果
瀏覽器會根據(jù) Date 和 Last-Modified 之間的時間差值緩存一段時間，這段時間內(nèi)會直接使用本地緩存數(shù)據(jù)而不會再去請求服務(wù)器（強(qiáng)制請求除外），緩存過期后，會再次請求服務(wù)端，并攜帶上 Last-Modified 指定的時間去服務(wù)器對比并根據(jù)服務(wù)端的響應(yīng)狀態(tài)決定是否要從本地加載緩存數(shù)據(jù)。
總結(jié)
HTTP 緩存設(shè)置起來并不復(fù)雜，但卻容易被輕視， 今天這篇文章結(jié)合2道題目，通過分析、解剖相關(guān)緩存頭，從系統(tǒng)化角度對 HTTP 緩存機(jī)制做了一個較完整的剖析：HTTP 緩存機(jī)制實(shí)際上是 HTTP 緩存策略三個要素（緯度）相互作用的集合，所以在分析和設(shè)置 HTTP 報文緩存頭時，只要能從中精準(zhǔn)的分解出緩存三要素，我們就能非常準(zhǔn)確的預(yù)判到緩存設(shè)置最終能達(dá)到的效果。
了解最新移動開發(fā)相關(guān)信息和技術(shù)，請關(guān)注 mobilehub 公眾微信號（ID: mobilehub)。
騰訊 Bugly是一款專為移動開發(fā)者打造的質(zhì)量監(jiān)控工具，幫助開發(fā)者快速，便捷的定位線上應(yīng)用崩潰的情況以及解決方案。智能合并功能幫助開發(fā)同學(xué)把每天上報的數(shù)千條?Crash?根據(jù)根因合并分類，每日日報會列出影響用戶數(shù)最多的崩潰，精準(zhǔn)定位功能幫助開發(fā)同學(xué)定位到出問題的代碼行，實(shí)時上報可以在發(fā)布后快速的了解應(yīng)用的質(zhì)量情況，適配最新的 iOS, Android 官方操作系統(tǒng)，鵝廠的工程師都在使用，快來加入我們吧！
from:?http://geek.csdn.net/news/detail/131318
總結(jié)
以上是生活随笔為你收集整理的彻底弄懂 HTTP 缓存机制 —— 基于缓存策略三要素分解法的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 谈谈 Python 程序的运行原理
- 下一篇： JVM 调优 —— GC 长时间停顿问题