緩存一直是前端優化的主戰場, 利用好緩存就成功了一半. 本篇從http請求和響應的頭域入手, 讓你對瀏覽器緩存有個整體的概念. 最終你會發現強緩存, 協商緩存 和 啟發式緩存是如此的簡單.

原文：瀏覽器緩存機制剖析

導讀

我不知道拖延癥是有多嚴重, 反正去年3月開的題, 直到今年4月才開始寫.(請盡情吐槽吧)

瀏覽器對于請求資源, 擁有一系列成熟的緩存策略. 按照發生的時間順序分別為存儲策略, 過期策略, 協商策略, 其中存儲策略在收到響應后應用, 過期策略, 協商策略在發送請求前應用. 流程圖如下所示.

緩存流程圖

廢話不多說, 我們先來看兩張表格.

1.http header中與緩存有關的key.

2.緩存協商策略用于重新驗證緩存資源是否有效, 有關的key如下.

下面我們來看下各個頭域(key)的作用.

Cache-Control

瀏覽器緩存里, Cache-Control是金字塔頂尖的規則, 它藐視一切其他設置, 只要其他設置與其抵觸, 一律覆蓋之.

不僅如此, 它還是一個復合規則, 包含多種值, 橫跨 存儲策略, 過期策略 兩種, 同時在請求頭和響應頭都可設置.

語法為: "Cache-Control : cache-directive".

?Cache-directive共有如下12種(其中請求中指令7種, 響應中指令9種):

假設所請求資源于4月5日緩存, 且在4月12日過期.

當max-age 與 max-stale 和 min-fresh 同時使用時, 它們的設置相互之間獨立生效, 最為保守的緩存策略總是有效. 這意味著, 如果max-age=10 days, max-stale=2 days, min-fresh=3 days, 那么:

• 根據max-age的設置, 覆蓋原緩存周期, 緩存資源將在4月15日失效(5+10=15);
• 根據max-stale的設置, 緩存過期后兩天依然有效, 此時響應將返回110(Response is stale)狀態碼, 緩存資源將在4月14日失效(12+2=14);
• 根據min-fresh的設置, 至少要留有3天的新鮮期, 緩存資源將在4月9日失效(12-3=9);

由于客戶端總是采用最保守的緩存策略, 因此, 4月9日后, 對于該資源的請求將重新向服務器發起驗證.

Pragma

http1.0字段, 通常設置為Pragma:no-cache, 作用同Cache-Control:no-cache. 當一個no-cache請求發送給一個不遵循HTTP/1.1的服務器時, 客戶端應該包含pragma指令. 為此, 勾選?? 上disable cache時, 瀏覽器自動帶上了pragma字段. 如下:

Pragma:no-cache

Expires

Expires:Wed, 05 Apr 2017 00:55:35 GMT

即到期時間, 以服務器時間為參考系, 其優先級比 Cache-Control:max-age 低, 兩者同時出現在響應頭時, Expires將被后者覆蓋. 如果Expires, Cache-Control: max-age, 或 Cache-Control:s-maxage 都沒有在響應頭中出現, 并且也沒有其它緩存的設置, 那么瀏覽器默認會采用一個啟發式的算法, 通常會取響應頭的Date_value - Last-Modified_value值的10%作為緩存時間.

如下資源便采取了啟發式緩存算法.

啟發式緩存生效

其緩存時間為 (Date_value - Last-Modified_value) * 10%, 計算如下:

const Date_value = new Date('Thu, 06 Apr 2017 01:30:56 GMT').getTime();
const LastModified_value = new Date('Thu, 01 Dec 2016 06:23:23 GMT').getTime();
const cacheTime = (Date_value - LastModified_value) / 10;
const Expires_timestamp = Date_value + cacheTime;
const Expires_value = new Date(Expires_timestamp);
console.log('Expires:', Expires_value); // Expires: Tue Apr 18 2017 23:25:41 GMT+0800 (CST)

可見該資源將于2017年4月18日23點25分41秒過期, 嘗試以下兩步進行驗證:

1. 試著把本地時間修改為2017年4月18日23點25分40秒, 迅速刷新頁面, 發現強緩存依然有效(依舊是200 OK (from disk cache)).

2. 然后又修改本地時間為2017年4月18日23點26分40秒(即往后撥1分鐘), 刷新頁面, 發現緩存已過期, 此時瀏覽器重新向服務器發起了驗證, 且命中了304協商緩存, 如下所示.

緩存過期, 重新發起驗證, 命中304協商緩存

3. 將本地時間恢復正常(即 2017-04-06 09:54:19). 刷新頁面, 發現Date依然是4月18日, 如下所示.

本地時間恢復正常, 緩存依然有效

從?? Provisional headers are shown 和Date字段可以看出來, 瀏覽器并未發出請求, 緩存依然有效, 只不過此時Status Code顯示為200 OK. (甚至我還專門打開了charles, 也沒有發現該資源的任何請求, 可見這個200 OK多少有些誤導人的意味)

可見, 啟發式緩存算法采用的緩存時間可長可短, 因此對于常規資源, 建議明確設置緩存時間(如指定max-age 或 expires).

ETag

ETag:"fcb82312d92970bdf0d18a4eca08ebc7efede4fe"

實體標簽, 服務器資源的唯一標識符, 瀏覽器可以根據ETag值緩存數據, 節省帶寬. 如果資源已經改變, etag可以幫助防止同步更新資源的相互覆蓋. ETag 優先級比 Last-Modified 高.

If-Match

語法: If-Match: ETag_value 或者 If-Match: ETag_value, ETag_value, …

緩存校驗字段, 其值為上次收到的一個或多個etag 值. 常用于判斷條件是否滿足, 如下兩種場景:

• 對于 GET 或 HEAD 請求, 結合 Range 頭字段, 它可以保證新范圍的請求和前一個來自相同的源, 如果不匹配, 服務器將返回一個416(Range Not Satisfiable)狀態碼的響應.
• 對于 PUT 或者其他不安全的請求, If-Match 可用于阻止錯誤的更新操作, 如果不匹配, 服務器將返回一個412(Precondition Failed)狀態碼的響應.

If-None-Match

語法: If-None-Match: ETag_value 或者 If-None-Match: ETag_value, ETag_value, …

緩存校驗字段, 結合ETag字段, 常用于判斷緩存資源是否有效, 優先級比If-Modified-Since高.

• 對于 GET 或 HEAD 請求, 如果其etags列表均不匹配, 服務器將返回200狀態碼的響應, 反之, 將返回304(Not Modified)狀態碼的響應. 無論是200還是304響應, 都至少返回 Cache-Control, Content-Location, Date, ETag, Expires, and Vary 中之一的字段.
• 對于其他更新服務器資源的請求, 如果其etags列表匹配, 服務器將執行更新, 反之, 將返回412(Precondition Failed)狀態碼的響應.

Last-Modified

語法: Last-Modified: 星期,日期 月份 年份 時:分:秒 GMT

Last-Modified: Tue, 04 Apr 2017 10:01:15 GMT

用于標記請求資源的最后一次修改時間, 格式為GMT(格林尼治標準時間). 如可用 new Date().toGMTString()獲取當前GMT時間. Last-Modified 是 ETag 的fallback機制, 優先級比 ETag 低, 且只能精確到秒, 因此不太適合短時間內頻繁改動的資源. 不僅如此, 服務器端的靜態資源, 通常需要編譯打包, 可能出現資源內容沒有改變, 而Last-Modified卻改變的情況.

If-Modified-Since

語法同上, 如:

If-Modified-Since: Tue, 04 Apr 2017 10:12:27 GMT

緩存校驗字段, 其值為上次響應頭的Last-Modified值, 若與請求資源當前的Last-Modified值相同, 那么將返回304狀態碼的響應, 反之, 將返回200狀態碼響應.

If-Unmodified-Since

緩存校驗字段, 語法同上. 表示資源未修改則正常執行更新, 否則返回412(Precondition Failed)狀態碼的響應. 常用于如下兩種場景:

• 不安全的請求, 比如說使用post請求更新wiki文檔, 文檔未修改時才執行更新.
• 與 If-Range 字段同時使用時, 可以用來保證新的片段請求來自一個未修改的文檔.

強緩存

一旦資源命中強緩存, 瀏覽器便不會向服務器發送請求, 而是直接讀取緩存. Chrome下的現象是 200 OK (from disk cache) 或者 200 OK (from memory cache). 如下:

200 OK (from disk cache)

200 OK (from memory cache)

對于常規請求, 只要存在該資源的緩存, 且Cache-Control:max-age 或者expires沒有過期, 那么就能命中強緩存.

協商緩存

緩存過期后, 繼續請求該資源, 對于現代瀏覽器, 擁有如下兩種做法:

• 根據上次響應中的ETag_value, 自動往request header中添加If-None-Match字段. 服務器收到請求后, 拿If-None-Match字段的值與資源的ETag值進行比較, 若相同, 則命中協商緩存, 返回304響應.
• 根據上次響應中的Last-Modified_value, 自動往request header中添加If-Modified-Since字段. 服務器收到請求后, 拿If-Modified-Since字段的值與資源的Last-Modified值進行比較, 若相同, 則命中協商緩存, 返回304響應.

以上, ETag優先級比Last-Modified高, 同時存在時, 前者覆蓋后者. 下面通過實例來理解下強緩存和協商緩存.

如下忽略首次訪問, 第二次通過 If-Modified-Since 命中了304協商緩存.

304

協商緩存的響應結果, 不僅驗證了資源的有效性, 同時還更新了瀏覽器緩存. 主要更新內容如下:

Age:0
Cache-Control:max-age=600
Date: Wed, 05 Apr 2017 13:09:36 GMT
Expires:Wed, 05 Apr 2017 00:55:35 GMT

Age:0 表示命中了代理服務器的緩存, age值為0表示代理服務器剛剛刷新了一次緩存.

Cache-Control:max-age=600 覆蓋 Expires 字段, 表示從Date_value, 即 Wed, 05 Apr 2017 13:09:36 GMT 起, 10分鐘之后緩存過期. 因此10分鐘之內訪問, 將會命中強緩存, 如下所示:

200 from cache

當然, 除了上述與緩存直接相關的字段外, http header中還包括如下間接相關的字段.

Age

出現此字段, 表示命中代理服務器的緩存. 它指的是代理服務器對于請求資源的已緩存時間, 單位為秒. 如下:

Age:2383321
Date:Wed, 08 Mar 2017 16:12:42 GMT

以上指的是, 代理服務器在2017年3月8日16:12:42時向源服務器發起了對該資源的請求, 目前已緩存了該資源2383321秒.

Date

指的是響應生成的時間. 請求經過代理服務器時, 返回的Date未必是最新的, 通常這個時候, 代理服務器將增加一個Age字段告知該資源已緩存了多久.

Vary

對于服務器而言, 資源文件可能不止一個版本, 比如說壓縮和未壓縮, 針對不同的客戶端, 通常需要返回不同的資源版本. 比如說老式的瀏覽器可能不支持解壓縮, 這個時候, 就需要返回一個未壓縮的版本; 對于新的瀏覽器, 支持壓縮, 返回一個壓縮的版本, 有利于節省帶寬, 提升體驗. 那么怎么區分這個版本呢, 這個時候就需要Vary了.

服務器通過指定Vary: Accept-Encoding, 告知代理服務器, 對于這個資源, 需要緩存兩個版本: 壓縮和未壓縮. 這樣老式瀏覽器和新的瀏覽器, 通過代理, 就分別拿到了未壓縮和壓縮版本的資源, 避免了都拿同一個資源的尷尬.

Vary:Accept-Encoding,User-Agent

如上設置, 代理服務器將針對是否壓縮和瀏覽器類型兩個維度去緩存資源. 如此一來, 同一個url, 就能針對PC和Mobile返回不同的緩存內容.

怎么讓瀏覽器不緩存靜態資源

實際上, 工作中很多場景都需要避免瀏覽器緩存, 除了瀏覽器隱私模式, 請求時想要禁用緩存, 還可以設置請求頭: Cache-Control: no-cache, no-store, must-revalidate .

當然, 還有一種常用做法: 即給請求的資源增加一個版本號, 如下:

<link rel="stylesheet" type="text/css" href="../css/style.css?version=1.8.9"/>

這樣做的好處就是你可以自由控制什么時候加載最新的資源.

不僅如此, HTML也可以禁用緩存, 即在頁面的<head>節點中加入<meta>標簽, 代碼如下:

<meta http-equiv="Cache-Control" content="no-cache, no-store, must-revalidate"/>

上述雖能禁用緩存, 但只有部分瀏覽器支持, 而且由于代理不解析HTML文檔, 故代理服務器也不支持這種方式.

IE8的異常表現

實際上, 上述緩存有關的規律, 并非所有瀏覽器都完全遵循. 比如說IE8.

資源緩存是否有效相關.

Last-Modified / E-Tag 相關.

本問就討論這么多內容,大家有什么問題或好的想法歡迎在下方參與留言和評論.

本文作者: louis

本文鏈接: http://louiszhai.github.io/2017/04/07/http-cache/

參考文章

• Cache Policy Interaction—Maximum Age and Maximum Staleness
• HTTP/1.1: Header Field Definitions
• http - What's the difference between Cache-Control: max-age=0 and no-cache?
• App 緩存方案：Http 緩存
• Cache-Control - HTTP
• 徹底弄懂 Http 緩存機制 - 基于緩存策略三要素分解法