2. 程式人生 > >瀏覽器緩存機制剖析

瀏覽器緩存機制剖析

阿新 • • 發佈：2018-11-13
同步 打開 transform 數據 驗證 ats ber o-c www.

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

導讀

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

技術分享圖片

技術分享圖片

發起請求是否已緩存?[過期策略]-緩存是否過期?[協商策略]-重新向服務器發起驗證驗證是否通過?304響應[存儲策略]-根據響應頭更新緩存載入資源向服務器請求資源[存儲策略]-響應內容存入緩存是否是否是否

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

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

key描述存儲策略過期策略協商策略
Cache-Control 指定緩存機制,覆蓋其它設置 ?? ??
Pragma http1.0字段,指定緩存機制 ??
Expires http1.0字段,指定緩存的過期時間 ??
Last-Modified 資源最後一次的修改時間 ??
ETag 唯一標識請求資源的字符串 ??

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

key描述
If-Modified-Since 緩存校驗字段, 值為資源最後一次的修改時間, 即上次收到的Last-Modified值
If-Unmodified-Since 同上, 處理方式與之相反
If-Match 緩存校驗字段, 值為唯一標識請求資源的字符串, 即上次收到的ETag值
If-None-Match 同上, 處理方式與之相反

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

Cache-Control

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

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

語法為: “Cache-Control : cache-directive”

.

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

Cache-directive描述存儲策略過期策略請求字段響應字段
public 資源將被客戶端和代理服務器緩存 ?? ??
private 資源僅被客戶端緩存, 代理服務器不緩存 ?? ??
no-store 請求和響應都不緩存 ?? ?? ??
no-cache 相當於max-age:0,must-revalidate即資源被緩存, 但是緩存立刻過期, 同時下次訪問時強制驗證資源有效性 ?? ?? ?? ??
max-age 緩存資源, 但是在指定時間(單位為秒)後緩存過期 ?? ?? ?? ??
s-maxage 同上, 依賴public設置, 覆蓋max-age, 且只在代理服務器上有效. ?? ?? ??
max-stale 指定時間內, 即使緩存過時, 資源依然有效 ?? ??
min-fresh 緩存的資源至少要保持指定時間的新鮮期 ?? ??
must-revalidation / proxy-revalidation 如果緩存失效, 強制重新向服務器(或代理)發起驗證(因為max-stale等字段可能改變緩存的失效時間) ?? ??
only-if-cached 僅僅返回已經緩存的資源, 不訪問網絡, 若無緩存則返回504 ??
no-transform 強制要求代理服務器不要對資源進行轉換, 禁止代理服務器對 Content-Encoding, Content-Range, Content-Type字段的修改(因此代理的gzip壓縮將不被允許) ?? ??

假設所請求資源於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字段. 如下:

技術分享圖片

Expires

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

即到期時間, 以服務器時間為參考系, 其優先級比 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)
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6

可見該資源將於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協商緩存, 如下所示.

技術分享圖片

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"
  • 1

實體標簽, 服務器資源的唯一標識符, 瀏覽器可以根據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
  • 1

用於標記請求資源的最後一次修改時間, 格式為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
  • 1

緩存校驗字段, 其值為上次響應頭的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). 如下:

技術分享圖片

技術分享圖片

對於常規請求, 只要存在該資源的緩存, 且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協商緩存.

技術分享圖片

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

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
  • 1
  • 2
  • 3
  • 4

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

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

技術分享圖片

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

Age

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

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

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

Date

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

Vary

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

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

Vary:Accept-Encoding,User-Agent
  • 1

如上設置, 代理服務器將針對是否壓縮和瀏覽器類型兩個維度去緩存資源. 如此一來, 同一個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"/>
  • 1

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

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

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

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

IE8的異常表現

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

資源緩存是否有效相關.

瀏覽器前提操作表現正常表現
IE8 資源緩存有效 新開一個窗口加載網頁 重新發送請求(返回200) 展示緩存的頁面
IE8 資源緩存失效 原瀏覽器窗口中單擊 Enter 按鈕 展示緩存的頁面 重新發送請求(返回200)

Last-Modified / E-Tag 相關.

瀏覽器前提操作表現正常表現
IE8 資源內容沒有修改 新開一個窗口加載網頁 瀏覽器重新發送請求(返回200) 重新發送請求(返回304)
IE8 資源內容已修改 原瀏覽器窗口中單擊 Enter 按鈕 瀏覽器展示緩存的頁面 重新發送請求(返回200)

版權聲明：轉載需註明作者和出處。

本文作者：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? - Stack Overflow
  • App 緩存方案：Http 緩存 · baitouwei
  • Cache-Control - HTTP | MDN
  • 徹底弄懂 Http 緩存機制 基於緩存策略三要素分解法

瀏覽器緩存機制剖析

相關推薦

瀏覽器緩存機制剖析

同步 打開 transform 數據 驗證 ats ber o-c www. 緩存一直是前端優化的主戰場, 利用好緩存就成功了一半. 本篇從http請求和響應的頭域入手, 讓你對瀏覽器緩存有個整體的概念. 最終你會發現強緩存, 協商緩存 和 啟發式緩存是如此的簡單. 導讀

互聯網企業靜態資源的部署，如何充分利用瀏覽器緩存機制

本地 客戶 方式 sta blog scss tro 利用 exp 瀏覽器獲取靜態資源方式：緩存、版本 從html文件中解析出靜態資源的url，查看本地緩存是否存在、是否過期，是否需要重新獲取。根據url全路徑匹配查找是否存在，根據header的字段expire/cac

前端性能優化成神之路-瀏覽器緩存機制詳解

出現 開發者 細致 不同 兩種 頭信息 服務器 自動生成 spa 對一個網站而言，CSS、javascript、logo、圖標這些靜態資源文件更新的頻率都比較低，而這些文件又幾乎是每次http請求都需要的，如果將這些文件緩存在瀏覽器中，可以極好的改善性能。 通過設置htt

九種瀏覽器端緩存機制知多少（轉）

調用 內容 list content rect 本地 成功 asc 技術 瀏覽器緩存（Browser Caching）是瀏覽器端保存數據用於快速讀取或避免重復資源請求的優化機制，有效的緩存使用可以避免重復的網絡請求和瀏覽器快速地讀取本地數據，整體上加速網頁展示給用戶。瀏覽器

瀏覽器 HTTP 協議緩存機制詳解

blank 設置 響應頭 tag ble 1.0 強制 pri follow 1、緩存的分類 2、瀏覽器緩存機制詳解 2.1 HTML Meta標簽控制緩存 2.2 HTTP頭信息控制緩存 2.2.1 瀏覽器請求流程 2.2.2 幾個重要概念解釋 3、用戶行為與緩存 4

【Web緩存機制系列】2 – Web瀏覽器的緩存機制-(新鮮度 校驗值)

logs 決定 transfer action n-n clas 響應頭 正常 text Web緩存的工作原理 所有的緩存都是基於一套規則來幫助他們決定什麽時候使用緩存中的副本提供服務（假設有副本可用的情況下，未被銷毀回收或者未被刪除修改）。這些規則有的在協議中有定義（

從php到瀏覽器的緩存機制，不得不看！

基礎上 結束 apach 要素 而是 bubuko web應用 瀏覽器 img 所有的php程序員都知道在php腳本裏面執行 echo “1”;訪客的瀏覽器裏面就會顯示“1”。 但是我們執行下面的代碼的時候，並不是顯示“1”之後5秒再顯示“2”，而是等待5秒後直接顯示“12

深入理解瀏覽器的緩存機制

直接 們的 iba 引用 時間 也會 pad 說明文 wechat 該文章的原創作者是 浪裏行舟，看完這篇文章後對瀏覽器的緩存機制有了進一步的更深一層的理解，故記錄於此，供日後自己多次閱讀，加以自己的理解，也希望幫助到有需要的人。 一、前言 緩存可以說是性能優化中簡單

瀏覽器緩存

com 策略 無法 時間 瀏覽器 其中 機器 ctrl+ 需要 針對靜態文件，動態文件需要 web server解析 瀏覽器緩存有強緩存，協商緩存和啟發式緩存三種。 請求的基本過程，瀏覽器會先檢查cache-control和expires，看資源是否緩存過期，不過期，直接使

瀏覽器緩存清理最全圖文教程

定時清除 target height span 保留 ont 菜單欄 工具 史記 　瀏覽器是每個使用電腦的人都會用的，瀏覽器的功能就是可以瀏覽任何網頁，每瀏覽一個網頁，瀏覽器都會默認加載下載一些緩存文件，瀏覽的網頁越多，瀏覽器緩存就越多，導致時間久了，瀏覽器的反應就越來越慢

緩存機制與局部性原理

緩存命中 存儲 讀寫 依賴 速度 網絡 表現 二維數組 文件 http://www.cnblogs.com/jqctop1/p/4714116.html 1. 局部性原理 局部性原理是指計算機在執行某個程序時，傾向於使用最近使用的數據。局部性原理有兩種表現形式：時間局部

Hibernate 緩存機制淺析

sa1. 為什麽要用 Hibernate 緩存？ Hibernate是一個持久層框架，經常訪問物理數據庫。 為了降低應用程序對物理數據源訪問的頻次，從而提高應用程序的運行性能。 緩存內的數據是對物理數據源中的數據的復制，應用程序在運行時從緩存讀寫數據，在特定的時刻或事件會同步緩存和物理數據源的數據

利用gulp解決微信瀏覽器緩存問題

緩存 js文件 資源 瀏覽器中 清除 cat alt style ima 做了好多項目，這次終於要解決微信瀏覽器緩存這個令人頭疼的問題了。每次上傳新的文件，在微信瀏覽器中訪問時，總要先清除微信的緩存，實在麻煩，在網上搜羅了很多解決辦法，終於找到了方法：利用gulp解決緩存問

【轉載】瀏覽器緩存詳解：expires cache-control last-modified

導致 lang -c csdn 判斷 屬性 lan -m load 最近在對CDN進行優化，對瀏覽器緩存深入研究了一下，記錄一下，方便後來者 畫了一個草圖： 每個狀態的詳細說明如下： 1、Last-Modified 在瀏覽器第一次請求某一個URL時，服務器端的返回

mybatis 之緩存機制

二級緩存 一級緩存 mybatis 緩存機制 cache標簽 sqlsession 級別的緩存 1、緩存機制的簡單介紹： a、MyBatis 包含一個非常強大的查詢緩存特性，它可以非常方便地配置和定制。緩存可以極大的提升查詢效率。 b、MyBatis 系統中默認定義了兩

Android性能優化之ListView緩存機制

ner data b2c 模式 ret hold ren state err 要想優化ListView首先要了解它的工作原理，列表的顯示須要三個元素：ListView、Adapter、顯示的數據。 這裏的Adapter就是用到了適配器模式，無論傳入的是什麽View在Li

Bitmap緩存機制

mean set wake instance ads images obj hat 內存大小 Bitmap緩存機制 載入一個bitmap到UI裏面比較簡單直接。可是，假設我們一次載入大量的bitmap數據的時候就變得復雜了。很多情況下（比方這些組件：ListVIe

大規模網站架構的緩存機制

這樣的 實踐 未來 time 部署 star 命中率 手機瀏覽 產生 【問底】徐漢彬：大規模網站架構的緩存機制和幾何分形學 發表於16小時前|1796次閱讀| 來源CSDN|10 條評論| 作者徐漢彬 問底CDN緩存徐漢彬 摘要：緩存機制簡單總結可以說是空間換時間，被用於

瀏覽器緩存信息（Autocomplete ）

官網 html 詳細 搜索功能 需求 設置 field attribute plugin Autocomplete HTML Attribute Not Disabled for Password Field 漏洞詳細Web系統被識別到支持自動完成功能，這樣通過瀏覽器可

Shiro學習（11）緩存機制

values next() app uri 如果 itl apache 依賴 nag Shiro提供了類似於spring的Cache抽象，即Shiro本身不實現Cache，但是對Cache進行了又抽象，方便更換不同的底層Cache實現。對於Cache的一些概念可以參考我的《