徹底理解瀏覽器的緩存機制 2018/04/16 概述瀏覽器的緩存機制也就是我們說的HTTP緩存機制，其機制是根據HTTP報文的緩存標識進行的，所以在分析瀏覽器緩存機制之前，我們先使用圖文簡單介紹一下HTTP報文，HTTP報文分為兩種： HTTP請求(Request)報文，報文格式為：請求行 – H ...

徹底理解瀏覽器的緩存機制

2018/04/16

概述

瀏覽器的緩存機制也就是我們說的HTTP緩存機制，其機制是根據HTTP報文的緩存標識進行的，所以在分析瀏覽器緩存機制之前，我們先使用圖文簡單介紹一下HTTP報文，HTTP報文分為兩種：

HTTP請求(Request)報文，報文格式為：請求行 – HTTP頭(通用信息頭，請求頭，實體頭) – 請求報文主體(只有POST才有報文主體)，如下圖

HTTP響應(Response)報文，報文格式為：狀態行 – HTTP頭(通用信息頭，響應頭，實體頭) – 響應報文主體，如下圖

註：通用信息頭指的是請求和響應報文都支持的頭域，分別為Cache-Control、Connection、Date、Pragma、Transfer-Encoding、Upgrade、Via；實體頭則是實體信息的實體頭域，分別為Allow、Content-Base、Content-Encoding、Content-Language、Content-Length、Content-Location、Content-MD5、Content-Range、Content-Type、Etag、Expires、Last-Modified、extension-header。這裡只是為了方便理解，將通用信息頭，響應頭/請求頭，實體頭都歸為了HTTP頭。

以上的概念在這裡我們不做多講解，只簡單介紹，有興趣的童鞋可以自行研究。

緩存過程分析

瀏覽器與伺服器通信的方式為應答模式，即是：瀏覽器發起HTTP請求 – 伺服器響應該請求。那麼瀏覽器第一次向伺服器發起該請求後拿到請求結果，會根據響應報文中HTTP頭的緩存標識，決定是否緩存結果，是則將請求結果和緩存標識存入瀏覽器緩存中，簡單的過程如下圖：
cache

由上圖我們可以知道：

瀏覽器每次發起請求，都會先在瀏覽器緩存中查找該請求的結果以及緩存標識
瀏覽器每次拿到返回的請求結果都會將該結果和緩存標識存入瀏覽器緩存中

以上兩點結論就是瀏覽器緩存機制的關鍵，他確保了每個請求的緩存存入與讀取，只要我們再理解瀏覽器緩存的使用規則，那麼所有的問題就迎刃而解了，本文也將圍繞著這點進行詳細分析。為了方便大家理解，這裡我們根據是否需要向伺服器重新發起HTTP請求將緩存過程分為兩個部分，分別是強制緩存和協商緩存 。

強制緩存

強制緩存就是向瀏覽器緩存查找該請求結果，並根據該結果的緩存規則來決定是否使用該緩存結果的過程，強制緩存的情況主要有三種(暫不分析協商緩存過程)，如下：

不存在該緩存結果和緩存標識，強制緩存失效，則直接向伺服器發起請求（跟第一次發起請求一致），如下圖：
存在該緩存結果和緩存標識，但該結果已失效，強制緩存失效，則使用協商緩存(暫不分析)，如下圖
存在該緩存結果和緩存標識，且該結果尚未失效，強制緩存生效，直接返回該結果，如下圖

那麼強制緩存的緩存規則是什麼？

當瀏覽器向伺服器發起請求時，伺服器會將緩存規則放入HTTP響應報文的HTTP頭中和請求結果一起返回給瀏覽器，控制強制緩存的欄位分別是Expires和Cache-Control，其中Cache-Control優先順序比Expires高。

Expires

Expires是HTTP/1.0控制網頁緩存的欄位，其值為伺服器返回該請求結果緩存的到期時間，即再次發起該請求時，如果客戶端的時間小於Expires的值時，直接使用緩存結果。

Expires是HTTP/1.0的欄位，但是現在瀏覽器預設使用的是HTTP/1.1，那麼在HTTP/1.1中網頁緩存還是否由Expires控制？

到了HTTP/1.1，Expire已經被Cache-Control替代，原因在於Expires控制緩存的原理是使用客戶端的時間與服務端返回的時間做對比，那麼如果客戶端與服務端的時間因為某些原因（例如時區不同；客戶端和服務端有一方的時間不准確）發生誤差，那麼強制緩存則會直接失效，這樣的話強制緩存的存在則毫無意義，那麼Cache-Control又是如何控制的呢？

Cache-Control

在HTTP/1.1中，Cache-Control是最重要的規則，主要用於控制網頁緩存，主要取值為：

public：所有內容都將被緩存（客戶端和代理伺服器都可緩存）
private：所有內容只有客戶端可以緩存，Cache-Control的預設取值
no-cache：客戶端緩存內容，但是是否使用緩存則需要經過協商緩存來驗證決定
no-store：所有內容都不會被緩存，即不使用強制緩存，也不使用協商緩存
max-age=xxx (xxx is numeric)：緩存內容將在xxx秒後失效

接下來，我們直接看一個例子，如下：
example

由上面的例子我們可以知道：

HTTP響應報文中expires的時間值，是一個絕對值
HTTP響應報文中Cache-Control為max-age=600，是相對值

由於Cache-Control的優先順序比expires，那麼直接根據Cache-Control的值進行緩存，意思就是說在600秒內再次發起該請求，則會直接使用緩存結果，強制緩存生效。

註：在無法確定客戶端的時間是否與服務端的時間同步的情況下，Cache-Control相比於expires是更好的選擇，所以同時存在時，只有Cache-Control生效。

瞭解強制緩存的過程後，我們拓展性的思考一下：

瀏覽器的緩存存放在哪裡，如何在瀏覽器中判斷強制緩存是否生效？

disk
這裡我們以博客的請求為例，狀態碼為灰色的請求則代表使用了強制緩存，請求對應的Size值則代表該緩存存放的位置，分別為from memory cache 和 from disk cache。

那麼from memory cache 和 from disk cache又分別代表的是什麼呢？什麼時候會使用from disk cache，什麼時候會使用from memory cache呢？

from memory cache代表使用記憶體中的緩存，from disk cache則代表使用的是硬碟中的緩存，瀏覽器讀取緩存的順序為memory –> disk。

雖然我已經直接把結論說出來了，但是相信有不少人對此不能理解，那麼接下來我們一起詳細分析一下緩存讀取問題，這裡仍讓以我的博客為例進行分析：
訪問https://heyingye.github.io/ –> 200 –> 關閉博客的標簽頁 –> 重新打開https://heyingye.github.io/ –> 200(from disk cache) –> 刷新 –> 200(from memory cache)

過程如下：

訪問https://heyingye.github.io/
關閉博客的標簽頁
重新打開https://heyingye.github.io/
刷新

看到這裡可能有人小伙伴問了，最後一個步驟刷新的時候，不是同時存在著from disk cache和from memory cache嗎？

對於這個問題，我們需要瞭解記憶體緩存(from memory cache)和硬碟緩存(from disk cache)，如下:

記憶體緩存(from memory cache)：記憶體緩存具有兩個特點，分別是快速讀取和時效性：
- 快速讀取：記憶體緩存會將編譯解析後的文件，直接存入該進程的記憶體中，占據該進程一定的記憶體資源，以方便下次運行使用時的快速讀取。
- 時效性：一旦該進程關閉，則該進程的記憶體則會清空。
硬碟緩存(from disk cache)：硬碟緩存則是直接將緩存寫入硬碟文件中，讀取緩存需要對該緩存存放的硬碟文件進行I/O操作，然後重新解析該緩存內容，讀取複雜，速度比記憶體緩存慢。

在瀏覽器中，瀏覽器會在js和圖片等文件解析執行後直接存入記憶體緩存中，那麼當刷新頁面時只需直接從記憶體緩存中讀取(from memory cache)；而css文件則會存入硬碟文件中，所以每次渲染頁面都需要從硬碟讀取緩存(from disk cache)。

協商緩存

協商緩存就是強制緩存失效後，瀏覽器攜帶緩存標識向伺服器發起請求，由伺服器根據緩存標識決定是否使用緩存的過程，主要有以下兩種情況：

協商緩存生效，返回304，如下
協商緩存失效，返回200和請求結果結果，如下

同樣，協商緩存的標識也是在響應報文的HTTP頭中和請求結果一起返回給瀏覽器的，控制協商緩存的欄位分別有：Last-Modified / If-Modified-Since和Etag / If-None-Match，其中Etag / If-None-Match的優先順序比Last-Modified / If-Modified-Since高。

Last-Modified / If-Modified-Since

Last-Modified是伺服器響應請求時，返回該資源文件在伺服器最後被修改的時間，如下。
If-Modified-Since則是客戶端再次發起該請求時，攜帶上次請求返回的Last-Modified值，通過此欄位值告訴伺服器該資源上次請求返回的最後被修改時間。伺服器收到該請求，發現請求頭含有If-Modified-Since欄位，則會根據If-Modified-Since的欄位值與該資源在伺服器的最後被修改時間做對比，若伺服器的資源最後被修改時間大於If-Modified-Since的欄位值，則重新返回資源，狀態碼為200；否則則返回304，代表資源無更新，可繼續使用緩存文件，如下。

Etag / If-None-Match

Etag是伺服器響應請求時，返回當前資源文件的一個唯一標識(由伺服器生成)，如下。
If-None-Match是客戶端再次發起該請求時，攜帶上次請求返回的唯一標識Etag值，通過此欄位值告訴伺服器該資源上次請求返回的唯一標識值。伺服器收到該請求後，發現該請求頭中含有If-None-Match，則會根據If-None-Match的欄位值與該資源在伺服器的Etag值做對比，一致則返回304，代表資源無更新，繼續使用緩存文件；不一致則重新返回資源文件，狀態碼為200，如下。

註：Etag / If-None-Match優先順序高於Last-Modified / If-Modified-Since，同時存在則只有Etag / If-None-Match生效。

總結

強制緩存優先於協商緩存進行，若強制緩存(Expires和Cache-Control)生效則直接使用緩存，若不生效則進行協商緩存(Last-Modified / If-Modified-Since和Etag / If-None-Match)，協商緩存由伺服器決定是否使用緩存，若協商緩存失效，那麼代表該請求的緩存失效，重新獲取請求結果，再存入瀏覽器緩存中；生效則返回304，繼續使用緩存，主要過程如下：
all

轉自[徹底理解瀏覽器的緩存機制](https://heyingye.github.io/2018/04/16/%E5%BD%BB%E5%BA%95%E7%90%86%E8%A7%A3%E6%B5%8F%E8%A7%88%E5%99%A8%E7%9A%84%E7%BC%93%E5%AD%98%E6%9C%BA%E5%88%B6/)

(轉載)徹底理解瀏覽器的緩存機制