瀏覽器緩存，是瀏覽器端保存數據，用於快速讀取或避免重複資源請求的優化機制，有效的緩存使用可以避免重複的網絡請求和加快頁面速度,從而提高用戶體驗。
一 強緩存
1.1 區分Expires和Cache-Control
以一個接口返回的響應頭爲例：
這裏我畫了張思維導圖，對Expires和Cache-Control做比較：
具體介紹Expires和Cache-Control：
Expires:
(1)Expires是HTTP1.0的東西，現在默認瀏覽器均默認使用HTTP 1.1，所以它的作用基本忽略；
(2)Expires規定了緩存失效時間（Date爲當前時間），是絕對時間。由於Expires返回的是一個絕對時間，在服務器時間與客戶端時間相差較大的時候，緩存命中不準確；
Cache-Control：
(1)Cache-Control是HTTP1.1的
(2)Cache-Control的max-age規定了緩存有效時間（2552s)，是相對時間；
(3)若響應頭Expires和Cache-Control同時存在，Cache-Control優先級高於Expires
Cache-Control的常用指令：
no-cache：不使用本地緩存，需要使用協商緩存，也就是先與服務器確認緩存是否可用。
no-store：禁用緩存。用於防止重要的信息被無意的發佈。在請求消息中發送將使得請求和響應消息都不使用緩存。
public：其他用戶也可使用緩存，適用於公共緩存服務器的情況。
private：只有特定用戶才能使用緩存，適用於公共緩存服務器的情況。
不怎麼常用的指令：
max-age：客戶機可以接收生存期不大於指定時間（以秒爲單位）的響應。
min-fresh客戶機可以接收響應時間小於當前時間加上指定時間的響應。
max-stale指示客戶機可以接收超出超時期間的響應消息。如果指定max-stale消息的值，那麼客戶機可以接收超出超時期指定值之內的響應消息。
注意：no-cache指令並不是不緩存，no-cache的意思是可以緩存，但每次用應該去向服務器驗證緩存是否可用。no-store纔是不緩存內容。
1.2 強緩存的過程
強緩存：瀏覽器直接從本地緩存中獲取數據，不與服務器進行交互。
· 瀏覽器第一次跟服務器請求一個資源，服務器在返回這個資源的同時，在response的header會加上Expires/Cache-Control的header；
· 瀏覽器再請求這個資源時，先從緩存中尋找，找到這個資源後，比較Expires或Cache-Control的max-age字段值做比較, 如果在有效期內，則讀取緩存內容；若緩存已過期，則重新向服務器發送請求；
· header在重新加載的時候會被更新
這裏我畫了兩張圖，瀏覽器第一次請求：
瀏覽器再次請求：
對於強緩存，chrome瀏覽器的狀態碼：
200 OK(from disk cache)或是200 OK (from memory cache)
例如：請求某個圖片後，當瀏覽器再次訪問這個圖片時，發現有這個圖片的緩存，且緩存沒過期，所以就使用緩存。
當瀏覽器發現緩存過期後，緩存並不一定不能使用了。比如文件雖然過了有效期，但內容並沒有發生改變，還是可以用緩存數據。所以，這個時候需要與服務器協商，讓服務器判斷本地緩存是否還能使用。那麼又怎麼判斷服務端文件有沒有更新呢？主要有兩種方式：
Last-Modified，If-Modified-since。
二 協商緩存
2.1 區分Last-Modified和If-Modified-Since
以一個返回的接口爲例：
Last-Modified的格式：
Last-Modified: Mon, 17 Sep 2018 12:06:18 GMT
If-Modified-Since的格式：
If-Modified-Since: Mon, 17 Sep 2018 12:06:18 GMT
2.2 Etag是什麼
web服務器響應請求時，告訴瀏覽器當前資源在服務器的唯一標識（生成規則由服務器決定）。Apache中，ETag的值默認是對文件的索引節（INode），大小（Size）和最後修改時間（MTime）進行Hash後得到的。
2.3 協商緩存的過程
瀏覽器第一次請求：
瀏覽器再一次請求：
Last-Modified：
· 瀏覽器第一次向服務器請求一個資源，服務器在返回這個資源的同時，在respone的header加上Last-Modified字段，表示該資源在服務器上的最後修改時間；
· 瀏覽器再次向服務器請求這個資源時，在request的header上加上If-Modified-Since字段，這個值就是上一次請求時返回的Last-Modified的值;
·服務器收到資源請求時，比較If-Modified-Since字段值和被請求資源的最後修改時間，若資源最後修改時間較舊，則說明文件沒有修改，返回304 Not Modified, 瀏覽器從緩存中加載資源；若不相同，說明文件被更新，瀏覽器直接從服務器加載資源, 返回200；
·重新加載資源時更新Last-Modified Header
If-Modified-Since
· 瀏覽器第一次向服務器請求一個資源，服務器在返回這個資源的同時，在respone的header加上ETag字段；
·瀏覽器再次跟服務器請求這個資源時，在request的header上加上If-None-Match，這個值就是上一次請求時返回的ETag的值；
·服務器再次收到資源請求時，再根據資源生成一個新的ETag，與瀏覽器傳過來If-None-Match比較，如果這兩個值相同，則說明資源沒有變化，返回304 Not Modified, 瀏覽器從緩存中加載資源，否則返回200 資源內容。與Last-Modified不一樣的是，當服務器返回304 Not Modified的響應時，由於ETag重新生成過，response header中還會把這個ETag返回，即使這個ETag跟之前的沒有變化
2.4 爲什麼有了Last-Modified，還要用Etag呢？
HTTP1.1中ETag的出現主要是爲了解決幾個Last-Modified比較難解決的問題：
·一些文件也許會週期性的更改，但是他的內容並不改變(僅僅改變的修改時間)，這個時候我們並不希望客戶端認爲這個文件被修改了，而重新GET；
·某些文件修改非常頻繁，比如在秒以下的時間內進行修改，(比方說1s內修改了N次)，If-Modified-Since能檢查到的粒度是s級的，這種修改無法判斷(或者說UNIX記錄MTIME只能精確到秒)；
·某些服務器不能精確的得到文件的最後修改時間。
對於上述情景，利用ETag能夠更加準確的控制緩存，因爲ETag是服務器自動生成的資源在服務器端的唯一標識符，資源每次變動，都會生成新的ETag值。Last-Modified與ETag是可以一起使用的，但服務器會優先驗證ETag。
2.5 比較強緩存和協商緩存
基於上文對強緩存和協商緩存過程的解釋，這裏我把強緩存和協商緩存繪製在一張圖裏，方便比較，具體過程可以參照上文：
三 小結
本文主要通過圖解介紹了http的緩存，具體包括強緩存和協商緩存。如有問題，歡迎指正。