完全理解瀏覽器緩存機制

推薦理由：文章思路清晰，鞭辟入裏。

概述

瀏覽器的緩存機制也就是咱們說的 HTTP 緩存機制，其機制是根據 HTTP 報文的緩存標示進行的。

因此在分析瀏覽器緩存以前，咱們先使用圖文簡單介紹一下 HTTP 報文，HTTP 報文分爲兩種：

• HTTP 請求（Request）報文。報文格式爲：

  1. 請求行。
  2. HTTP 頭（通用信息頭，請求頭，實體頭）。
  3. 請求報文主體（只有 POST 纔有報文主體)。

• HTTP 響應（Response）報文，報文格式爲：

  1. 狀態行。
  2. HTTP 頭（通用信息頭，響應頭，實體頭）。
  3. 響應報文主體。

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

以上的概念在這裏咱們不作多講解，只簡單介紹，有興趣的童鞋能夠自行研究。

緩存過程分析

瀏覽器與服務器通訊的方式爲應答模式，即，瀏覽器發起 HTTP 請求 –> 服務器響應該請求。

那麼瀏覽器第一次向服務器發起該請求後拿到請求結果，會根據響應報文中 HTTP 頭的緩存標識，決定是否緩存結果，是則將請求結果和緩存標識存入瀏覽器緩存中，簡單的過程以下圖：

由上圖咱們能夠知道：

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

以上兩點結論就是瀏覽器緩存機制的關鍵，他確保了每一個請求的緩存存入與讀取，只要咱們再理解瀏覽器緩存的使用規則，那麼全部的問題就迎刃而解了，本文也將圍繞着這點進行詳細分析。

爲了方便你們理解，這裏咱們根據是否須要向服務器從新發起 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 秒後失效。

接下來，咱們直接看一個例子，以下：

由上面的例子咱們能夠知道：

HTTP 響應報文中 expires 的時間值，是一個絕對值。

HTTP 響應報文中 Cache-Control 爲 max-age=600，是相對值。

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

注：在沒法肯定客戶端的時間是否與服務端的時間同步的狀況下，Cache-Control 相比於 expires 是更好的選擇，因此同時存在時，只有Cache-Control 生效。

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

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

這裏咱們以博客的請求爲例，狀態碼爲灰色的請求則表明使用了強制緩存，請求對應的 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。

雖然我已經直接把結論說出來了，可是相信有很多人對此不能理解，那麼接下來咱們一塊兒詳細分析一下緩存讀取問題，這裏仍讓以個人博客爲例進行分析：

1. 訪問 https://heyingye.github.io/ –> 200
2. 關閉博客的標籤頁 –> 從新打開 https://heyingye.github.io/ –> 200 (from disk cache)
3. 刷新 –> 200(from memory cache)

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

對於這個問題，咱們須要瞭解內存緩存（from memory cache）和硬盤緩存（from disk cache），以下:

• 內存緩存(from memory cache)：內存緩存具備兩個特色，分別是快速讀取和時效性：

  • 快速讀取：內存緩存會將編譯解析後的文件，直接存入該進程的內存中，佔據該進程必定的內存資源，以方便下次運行使用時的快速讀取。
  • 時效性：一旦該進程關閉，則該進程的內存則會清空。
• 硬盤緩存（from disk cache）：硬盤緩存則是直接將緩存寫入硬盤文件中，讀取緩存須要對該緩存存放的硬盤文件進行 I/O 操做，而後從新解析該緩存內容，讀取複雜，速度比內存緩存慢。

在瀏覽器中，瀏覽器會在 js 和圖片等文件解析執行後直接存入內存緩存中，那麼當刷新頁面時只需直接從內存緩存中讀取；而 css 文件則會存入硬盤文件中，因此每次渲染頁面都須要從硬盤讀取緩存。

協商緩存

協商緩存就是強制緩存失效後，瀏覽器攜帶緩存標識向服務器發起請求，由服務器根據緩存標識決定是否使用緩存的過程。

主要有如下兩種狀況：

• 協商緩存生效，返回 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，繼續使用緩存，主要過程以下：

以上即是瀏覽器緩存的過程，如有錯誤之處，敬請指正。

轉載自 Heying Ye's Personal Website 我的博客。