本文首發於我的部落格https://lanjianguo.github.io/blog/
為什麼要有快取機制
瀏覽器快取是將檔案儲存在客戶端，好的快取策略可以減少對網路頻寬的佔用，可以提高訪問速度，提高使用者的體驗，還可以減輕伺服器的負擔。對於經常用瀏覽器來瀏覽資訊的使用者來說並不十分陌生。使用者也許在用瀏覽器瀏覽資訊時，經常使用"返回"和"後退"的瀏覽功能，呼叫你以前閱讀過的頁面，這時，你會發現顯示速度是很快的，其實這些你剛調出來的內容就放在計算機的快取中，而不需要再次從Internet上重新傳輸資料，這樣就會給使用者造成了一種訪問速度被提高的錯覺。 快取一直是前端優化的主戰場, 利用好快取就成功了一半. 本文從快取型別，快取過程等方面，帶你深入理解瀏覽器等快取機制。
認識瀏覽器快取
瀏覽器快取分為強快取和協商快取。
- 強快取 客戶端第一次向服務端傳送請求，伺服器丟還給客戶端所請求的這個資源同時，告訴客戶端將這個資源儲存在本地，並且在未來的某個時點之前如果還需要這個資源，直接從客戶端快取中獲取，不傳送請求到伺服器，不與伺服器發生互動行為。通過這種方式快取下來的資源稱為「強快取」。
- 協商快取 客戶端第一次向伺服器傳送請求，伺服器丟還給客戶端所請求的這個資源同時，將該資源的一些資訊（檔案摘要、或者最後修改時間）也返回給客戶端，告訴客戶端將這個資源快取在本地。當客戶端下一次需要這個資源時，將請求以及相關資訊（檔案摘要、或者最後修改時間）一併傳送給伺服器，由伺服器來判斷客戶端快取的資源是否需要更新：如不需要更新，就直接告訴客戶端獲取本地快取資源；如需要更新，則將最新的資源連同相應的資訊一併返回給客戶端。這種方式快取下來的資源稱為「協商快取」。
那麼這二者有什麼相同與不同點呢？
- 兩者共同點：客戶端獲得的資料最後都是從客戶端快取中獲得。
- 兩者的區別：強快取不與伺服器互動，而協商快取則需要與伺服器互動。
瞭解HTTP報文
瀏覽器的快取機制也就是HTTP快取機制，其機制是根據HTTP報文的快取標識進行的，所以在分析瀏覽器快取機制之前，我們先使用簡單瞭解一下HTTP報文，HTTP報文分為兩種：
-
HTTP請求(Request)報文，報文格式為：請求行 – HTTP頭(通用資訊頭，請求頭，實體頭) – 請求報文主體(只有POST才有報文主體)
-
HTTP響應(Response)報文，報文格式為：狀態行 – HTTP頭(通用資訊頭，響應頭，實體頭) – 響應報文主體
快取過程分析
借用大牛一張圖來說明快取過程。 客戶端第一次向伺服器發起請求後，拿到請求的結果會根據響應報文中HTTP頭的快取標識，決定是否快取結果，如果是，則將請求結果和快取標識存入瀏覽器快取中。
接下來我們分別講解上面提到的兩種快取方式
強快取
當瀏覽器向伺服器發起請求時，伺服器會將快取規則放入HTTP響應報文的HTTP頭中和請求結果一起返回給瀏覽器，控制強制快取的欄位分別是Expires和Cache-Control。其中Cache-Control優先順序比Expires高。
Expires Expires是HTTP/1.0控制網頁快取的欄位，其值為伺服器返回該請求結果快取的到期時間，即再次發起該請求時，如果客戶端的時間小於Expires的值時，直接使用快取結果。到了HTTP/1.1，Expire已經被Cache-Control替代，原因在於Expires控制快取的原理是使用客戶端的時間與服務端返回的時間做對比，那麼如果客戶端與服務端的時間因為某些原因發生誤差，那麼強制快取則會直接失效，這樣的話強制快取的存在則毫無意義。
Cache-Control 在HTTP/1.1中，Cache-Control是最重要的規則，主要用於控制網頁快取，主要取值為：
public：所有內容都將被快取，客戶端和代理伺服器都可快取
private：所有內容只有客戶端可以快取，Cache-Control的預設取值
no-cache：客戶端快取內容，但是是否使用快取則需要經過協商快取來驗證決定
no-store：所有內容都不會被快取，即不使用強制快取，也不使用協商快取
max-age=xxx (xxx is numeric)：快取內容將在xxx秒後失效
舉個栗子
由於Cache-Control的優先順序比expires，那麼直接根據Cache-Control的值進行快取，意思就是說在600秒內再次發起該請求，則會直接使用快取結果，強制快取生效。 expires的時間值，是一個絕對值，而Cache-Control為max-age=600，是相對值。
注：在無法確定客戶端的時間是否與服務端的時間同步的情況下，Cache-Control相比於expires是更好的選擇，所以同時存在時，只有Cache-Control生效。
瀏覽器的快取存放在哪裡，如何在瀏覽器中判斷強制快取是否生效？
狀態碼為灰色的請求則代表使用了強制快取，請求對應的Size值則代表該快取存放的位置，分別為from memory cache 和 from disk cache。
from memory cache代表使用記憶體中的快取，from disk cache則代表使用的是硬碟中的快取，瀏覽器讀取快取的順序為memory –> disk。
以我的部落格為例進行分析： 訪問https://lanjianguo.github.io/blog/–> 200 –> 關閉部落格的標籤頁 –> 重新開啟https://lanjianguo.github.io/blog/ –> 200(from disk cache) –> 重新整理 –> 200(from memory cache)
- 訪問https://lanjianguo.github.io/blog/
- 關閉部落格的標籤頁
- 重新開啟https://lanjianguo.github.io/blog/
- 重新整理
在瀏覽器中，瀏覽器會在js和圖片等檔案解析執行後直接存入記憶體快取中，那麼當重新整理頁面時只需直接從記憶體快取中讀取(from memory cache)；而css檔案則會存入硬碟檔案中，所以每次渲染頁面都需要從硬碟讀取快取(from disk cache)。
記憶體快取(from memory cache)：記憶體快取具有兩個特點，分別是快速讀取和時效性：
快速讀取：記憶體快取會將編譯解析後的檔案，直接存入該程式的記憶體中，佔據該程式一定的記憶體資源，以方便下次執行使用時的快速讀取。
時效性：一旦該程式關閉，則該程式的記憶體則會清空。
硬碟快取(from disk cache)：硬碟快取則是直接將快取寫入硬碟檔案中，讀取快取需要對該快取存放的硬碟檔案進行I/O操作，然後重新解析該快取內容，讀取複雜，速度比記憶體快取慢。
協商快取
協商快取就是強制快取失效後，瀏覽器攜帶快取標識向伺服器發起請求，由伺服器根據快取標識決定是否使用快取的過程，主要有以下兩種情況：
-
協商快取生效，返回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，繼續使用快取，主要過程如下：
