強快取與協商快取
1）瀏覽器在載入資源時，先根據這個資源的一些http header判斷它是否命中強快取，強快取如果命中，瀏覽器直接從自己的快取中讀取資源，不會發請求到伺服器。 在network中，能抓到請求的情況，強制快取的狀態碼是 status:灰色的200. size : from memory cache
狀態碼灰色兩百，不一定是讀取快取：
2）當強快取沒有命中的時候，瀏覽器一定會傳送一個請求到伺服器，通過伺服器端依據資源的另外一些http header驗證這個資源是否命中協商快取，如果協商快取命中，伺服器會將這個請求返回304，但是不會返回這個資源的資料，而是告訴客戶端可以直接從快取中載入這個資源，於是瀏覽器就又會從自己的快取中去載入這個資源
強快取
expires
-
瀏覽器第一次跟伺服器請求一個資源，伺服器在返回這個資源的同時，在respone的header加上Expires的header
-
瀏覽器在接收到這個資源後，會把這個資源連同所有response header一起快取下來（所以快取命中的請求返回的header並不是來自伺服器，而是來自之前快取的header）；
-
瀏覽器再請求這個資源時，先從快取中尋找，找到這個資源後，拿出它的Expires跟當前的請求時間比較，如果請求時間在Expires指定的時間之前，就能命中快取，否則就不行。
-
如果快取沒有命中，瀏覽器直接從伺服器載入資源時，Expires Header在重新載入的時候會被更新。
cache-Control
Expires是較老的強快取管理header，由於它是伺服器返回的一個絕對時間，在伺服器時間與客戶端時間相差較大時，快取管理容易出現問題，比如隨意修改下客戶端時間，就能影響快取命中的結果。所以在http1.1的時候，提出了一個新的header，就是Cache-Control，這是一個相對時間，在配置快取的時候，以秒為單位，用數值表示，如：Cache-Control:max-age=315360000，它的快取原理是：
- 瀏覽器第一次跟伺服器請求一個資源，伺服器在返回這個資源的同時，在respone的header加上Cache-Control的header
- 瀏覽器在接收到這個資源後，會把這個資源連同所有response header一起快取下來；
- 瀏覽器再請求這個資源時，先從快取中尋找，找到這個資源後，根據它第一次的請求時間和Cache-Control設定的有效期，計算出一個資源過期時間，再拿這個過期時間跟當前的請求時間比較，如果請求時間在過期時間之前，就能命中快取，否則就不行。
- 如果快取沒有命中，瀏覽器直接從伺服器載入資源時，Cache-Control Header在重新載入的時候會被更新。
協商快取
當瀏覽器對某個資源的請求沒有命中強快取，就會發一個請求到伺服器，驗證協商快取是否命中，如果協商快取命中，請求響應返回的http狀態為304並且會顯示一個Not Modified的字串
首次訪問的響應頭
第二次訪問的請求頭
第二次請求響應頭
Last-Modified，If-Modified-Since
- 瀏覽器第一次跟伺服器請求一個資源，伺服器在返回這個資源的同時，在respone的header加上Last-Modified的header，這個header表示這個資源在伺服器上的最後修改時間
- 瀏覽器再次跟伺服器請求這個資源時，在request的header上加上If-Modified-Since的header，這個header的值就是上一次請求時返回的Last-Modified的值
- 伺服器再次收到資源請求時，根據瀏覽器傳過來If-Modified-Since和資源在伺服器上的最後修改時間判斷資源是否有變化，如果沒有變化則返回304 Not Modified，但是不會返回資源內容；如果有變化，就正常返回資源內容。當伺服器返回304 Not Modified的響應時，response header中不會再新增Last-Modified的header，因為既然資源沒有變化，那麼Last-Modified也就不會改變，這是伺服器返回304時的response header；
- 瀏覽器收到304的響應後，就會從快取中載入資源。
- 如果協商快取沒有命中，瀏覽器直接從伺服器載入資源時，Last-Modified Header在重新載入的時候會被更新，下次請求時，If-Modified-Since會啟用上次返回的Last-Modified值。
ETag、If-None-Match
【Last-Modified，If-Modified-Since】都是根據伺服器時間返回的header，一般來說，在沒有調整伺服器時間和篡改客戶端快取的情況下，這兩個header配合起來管理協商快取是非常可靠的，但是有時候也會伺服器上資源其實有變化，但是最後修改時間卻沒有變化的情況，而這種問題又很不容易被定位出來，而當這種情況出現的時候，就會影響協商快取的可靠性。所以就有了另外一對header來管理協商快取，這對header就是【ETag、If-None-Match】。它們的快取管理的方式是：
- 瀏覽器第一次跟伺服器請求一個資源，伺服器在返回這個資源的同時，在respone的header加上ETag的header，這個header是伺服器根據當前請求的資源生成的一個唯一標識，這個唯一標識是一個字串，只要資源有變化這個串就不同，跟最後修改時間沒有關係，所以能很好的補充Last-Modified的問題；
- 瀏覽器再次跟伺服器請求這個資源時，在request的header上加上If-None-Match的header，這個header的值就是上一次請求時返回的ETag的值；
- 伺服器再次收到資源請求時，根據瀏覽器傳過來If-None-Match和然後再根據資源生成一個新的ETag，如果這兩個值相同就說明資源沒有變化，否則就是有變化；如果沒有變化則返回304 Not Modified，但是不會返回資源內容；如果有變化，就正常返回資源內容。與Last-Modified不一樣的是，當伺服器返回304 Not Modified的響應時，由於ETag重新生成過，response header中還會把這個ETag返回，即使這個ETag跟之前的沒有變化
- 瀏覽器收到304的響應後，就會從快取中載入資源。
以下行為可能改變快取的預設處理方式
當ctrl+f5強制重新整理網頁時，直接從伺服器載入，跳過強快取和協商快取；
當f5重新整理網頁時，跳過強快取，但是會檢查協商快取；