當咱們在談論HTTP緩存時咱們在談論什麼

在瀏覽器衆多緩存中的HTTP緩存可能不少人對這個的概念並無很清晰，每一個人都知道進入一次網頁以後再刷新一次頁面，加載速度會比首次加載快很是多，每一個人都知道這是瀏覽器緩存的magic，可是對此背後的緣由可能不甚瞭解...

當咱們在談論HTTP緩存時咱們在談論什麼:

咱們其實是在談論下面這兩種狀況:

如上圖，瀏覽器對靜態資源的HTTP緩存有兩種狀況，一種是強緩存(本地緩存)，另外一種是弱緩存(協商緩存)。

---

緩存流程：

瀏覽器第一次請求資源時：

瀏覽器第一次請求資源時，必須下載全部的資源，而後根據響應的header內容來決定，如何緩存資源。可能採用的是強緩存，也多是弱緩存

瀏覽器後續請求資源時的匹配流程：

由上圖能夠知道當瀏覽器請求一個靜態資源時的HTTP流程：

1. 強緩存階段：先在本地查找該資源，若是發現該資源，而且其餘限制也沒有問題(好比:緩存有效時間)，就命中強緩存，返回200，直接使用強緩存，而且不會發送請求到服務器
2. 弱緩存階段：在本地緩存中找到該資源，發送一個http請求到服務器，服務器判斷這個資源沒有被改動過，則返回304，讓瀏覽器使用該資源。
3. 緩存失敗階段(從新請求)：當服務器發現該資源被修改過，或者在本地沒有找到該緩存資源，服務器則返回該資源的數據。

強緩存與弱緩存的區別：

獲取資源形式： 都是從緩存中獲取資源的。

狀態碼： 強緩存返回200(from cache),弱緩存返回304狀態碼

請求(最大區別)：

強緩存不發送請求，直接從緩存中取。

弱緩存須要發送一個請求，驗證這個文件是否可使用（有沒有被改動過）。

---

強緩存：

強緩存是利用Expires或者Cache-Control，讓原始服務器爲文件設置一個過時時間，在多長時間內能夠將這些內容視爲最新的。

若時間未過時，則命中強緩存，使用緩存文件不發送請求。

Cache-Control

Cache-Control 是http1.1中爲了彌補Expires的缺陷而加入的，當Expires和Cache-Control同時存在時，Cache-Control優先級高於Expires。

選項：

可緩存性:

public： 服務器端和瀏覽器端都能緩存

private: 只能瀏覽器端緩存

no-cache: 強制瀏覽器在使用cache拷貝以前先提交一個http請求到源服務器進行確認。http請求沒有減小，會減小一個響應體(文件內容),這種個選項相似弱緩存。

only-if-cached: 代表客戶端只接受已緩存的響應，而且不要向原始服務器檢查是否有更新的拷貝。

到期設置：

max-age=60：設置緩存存儲的最大週期，超過這個時間緩存被認爲過時(單位秒)。 這裏是60秒

其餘設置：

no-store: 不緩存，使用協商緩存

must-revalidate: 緩存必須在使用以前驗證舊資源的狀態，而且不可以使用過時資源。

更多設置，移動MDN

// 示例
Cache-Control: no-cache, no-store, must-revalidate
Cache-Control:public, max-age=31536000
Cache-Control: max-age=3600, must-revalidate
複製代碼

http1.0時代的緩存 Expires+Pragma

Expires用於設置緩存到期時間：

指定緩存到期GMT的絕對時間，若是設了max-age，max-age就會覆蓋expires，若是expires到期須要從新請求。

Expires:Sat, 09 Jun 2018 08:13:56 GMT
複製代碼

有一個問題是因爲使用具體時間，若是時間表示出錯或者沒有轉換到正確的時區均可能形成緩存生命週期出錯。

Pragma禁用緩存：

Pragma : no-cache 表示防止客戶端緩存，須要強制從服務器獲取最新的數據；

Pragma : no-cache  //只有這一個用法 禁用緩存，強制從服務器獲取最新的數據； 
複製代碼

強緩存命中 from memory cache & from disk cache

在測試的時候，看到命中強緩存時，有兩種狀態，200 (from memory cache) cache & 200 (from disk cache)，因而去找了一下這二者的區別：

memory cache: 將資源存到內存中，從內存中獲取。

disk cache：將資源緩存到磁盤中，從磁盤中獲取。

兩者最大的區別在於：當退出進程時，內存中的數據會被清空，而磁盤的數據不會。

更詳細的介紹推薦這篇文章

---

弱緩存：

若是強緩存時間過時，或者沒有設置，致使未命中的話。就進入到了弱緩存的階段了，

Last-Modified & if-modified-since:

Last-Modified與If-Modified-Since是一對報文頭，屬於http 1.0。

last-modified是web服務器認爲文件的最後修改時間，last-modified是第一次請求文件的時候，服務器返回的一個屬性。

Last-Modified: Sat, 09 Jun 2018 08:13:56 GMT 
複製代碼

第二次請求這個文件時，瀏覽器把If-Modified-Since發送給服務器，詢問該時間以後文件是否被修改過。

If-Modified-Since: Sat, 09 Jun 2018 08:13:56 GMT // 跟Last-Modified的值同樣
複製代碼

ETag & If-None-Match

ETag與If-None-Match是一對報文，屬於http 1.1。

ETag是一個文件的惟一標誌符。就像一個哈希或者指紋，每一個文件都有一個單獨的標誌，只要這個文件發生了改變，這個標誌就會發生變化。

ETag機制相似於樂觀鎖機制，若是請求報文的ETag與服務器的不一致，則表示該資源已經被修改過來，須要發最新的內容給瀏覽器。

ETag也是首次請求的時候，服務器返回的:

ETag: "8F759D4F67D66A7244638AD249675BE2" // 長這樣
複製代碼

If-None-Match也是瀏覽器發送到服務器驗證，文件是否改變的:

If-None-Match: "8F759D4F67D66A7244638AD249675BE2" // 跟ETag的值同樣
複製代碼

Etag/lastModified過程以下:

1. 客戶端第一次向服務器發起請求,服務器將附加Last-Modified/ETag到所提供的資源上去
2. 當再一次請求資源,若是沒有命中強緩存,在執行在驗證時,將上次請求時服務器返回的Last-Modified/ETag一塊兒傳遞給服務器。
3. 服務器檢查該Last-Modified或ETag，並判斷出該資源頁面自上次客戶端請求以後還未被修改，返回響應304和一個空的響應體。

同時使用兩個報文頭:

同時使用這兩個報文頭，兩個都匹配纔會命中弱緩存，不然將從新請求資源。

Etag 主要爲了解決 Last-Modified 沒法解決的一些問題：

1. 一些文件也許內容並不改變(僅僅改變的修改時間)，這個時候咱們不但願文件從新加載。（Etag值會觸發緩存，Last-Modified不會觸發）
2. If-Modified-Since能檢查到的粒度是秒級的，當修改很是頻繁時，Last-Modified會觸發緩存，而Etag的值不會觸發，從新加載。
3. 某些服務器不能精確的獲得文件的最後修改時間。

---

用戶操做行爲與緩存

F5刷新致使強緩存失效。

ctrl+F5強制刷新頁面強緩存，弱緩存都會失效。

如何設置？

通常是服務器端設置這些請求頭的，我本身試了用阿里雲服務器設置Cache-Control，設置一下很方便的。

---

小結

經過網絡重複請求資源既緩慢，成本又高，緩存和重用之前獲取的資源的能力成爲優化性能很關鍵的一個方面,也是大廠面試時很頻繁出現的內容，掌握好這塊知識點是很是重要的，但願本文能給你帶來些收穫。

文章若有不正確的地方歡迎各位路過的大佬鞭策！喜歡的話，趕忙點波訂閱關注/喜歡。

鼓勵我一下：

以爲還不錯的話，給個人項目點個star吧