[TOC]

簡介

用戶獲取網絡資源，需要通過非常長的網絡去服務器上請求資源,另外服務端為了應對大量的用戶請求而不斷的提升硬件性能與帶寬。這對用戶與服務端都非常的不友好。而緩存就是為了解決用戶請求速度與釋放服務器壓力而生的。

為什么我會寫Http緩存，因為下面介紹的緩存都是通過Http定義的。瀏覽器緩存則是另外的如:SessionStorage,LocalStorage(個人見解)。

緩存的判斷規則

1. 過期機制

過期機制就是瀏覽器根據緩存的有效期進行判斷，如果在有效期內就使用緩存，否則就拋棄這個緩存。

一個緩存副本必須滿足以下條件，瀏覽器會認為它是有效的，足夠新的：

　　　　1. 含有完整的過期時間控制頭信息（HTTP協議報頭），并且仍在有效期內；

　　　　2. 瀏覽器已經使用過這個緩存副本，并且在一個會話中已經檢查過新鮮度；

2. 驗證機制

瀏覽器帶上本地緩存副本的驗證信息提交給服務器(Last-Modified,ETag)，由服務器決定是否采用這個緩存。

客戶端請求的時候帶上Last-Modified，服務器進行驗證返回If-Modified-Since來確定資源是否是有效緩存。
另外在控制頭信息帶上這個資源的實體標簽Etag（Entity Tag），它可以用來作為瀏覽器再次請求過程的校驗標識。如過發現校驗標識不匹配，說明資源已經被修改或過期，瀏覽器需求重新獲取資源內容。

緩存來源

1. from disk cache

此資源是從磁盤當中取出的，也是在已經在之前的某個時間加載過該資源，不會請求服務器但是此資源不會隨著該頁面的關閉而釋放掉，因為是存在硬盤當中的，下次打開仍會from disk cache。

2. from memory cache

字面理解是從內存中，其實也是字面的含義，這個資源是直接從內存中拿到的，不會請求服務器一般已經加載過該資源且緩存在了內存當中，當關閉該頁面時，此資源就被內存釋放掉了，再次重新打開相同頁面時不會出現from memory cache的情況。

3. 請求來源

當http狀態為200是實實在在從瀏覽器獲取的資源，當http狀態為304時該數字是與服務端通信報文的大小，并不是該資源本身的大小，該資源是從本地獲取的。

緩存類型

強緩存

1. Expires

服務器發送給客戶端一個UTC時間(如 expires: Thu, 19 Nov 2019 08:52:00 GMT)，瀏覽器接收到了這個頭，就會為這個資源標記一個過期時間，在下次的請求時候判斷未過期會直接使用這個資源緩存。來源會標記為from disk cache。

瀏覽器在取到這個緩存資源的時候，會用客戶機的時間與之對比，如果還在有效期內，則直接使用這個緩存，不進行網絡請求。否則會進入其他緩存依據判斷。

而這個機制會有一個問題，就是，緩存資源是否過期依賴客戶機時間。客戶機可以通過修改當前時間來使這個緩存資源失效。

2. Cache-Control

HTTP/1.1定義的 Cache-Control 頭用來區分對緩存機制的支持情況， 請求頭和響應頭都支持這個屬性。通過它提供的不同的值來定義緩存策略。

2.1 max-age

示例:

Cache-Control: max-age=100

這個示例表示，這個緩存資源在本次請求后的100秒之后都有效。瀏覽器會直接返回from disk cache，不進行網絡資源請求。

2.2 no-cache

示例:

Cache-Control: no-cache

這個示例表示，這個緩存資源不進行強緩存校驗，需要通過服務端的協商緩存判斷是否啟用。

協商緩存

1. Last-Modified,If-Modified-Since

當客戶端訪問資源時，服務器會將資源最后修改時間通過 Last-Modified 標識由服務器發往客戶端，客戶端記錄修改時間，再次請求本地存在的緩存資源時，客戶端會通過 If-Modified-Since 頭將先前服務器端發過來的最后修改時間戳發送回去，服務器端通過這個時間戳判斷客戶端的頁面是否是最新的，如果不是最新的，則返回新的內容，如果是最新的，則返回304告訴客戶端其本地緩存資源是最新的。

2. ETag

服務器為一個資源生成一個唯一的id值，一旦資源在服務端發生了改變則會重新生成一個tag，客戶端請求資源時，帶上了這個etag，如果不一致，服務端將會發送最新的資源給用戶，否則重定向304直接使用緩存資源。

瀏覽器緩存判斷流程

參考文章

https://www.yodfz.com/detail/...
https://www.cnblogs.com/slly/...
https://blog.csdn.net/qq_3205...
https://blog.csdn.net/charlen...
https://segmentfault.com/a/11...
http://www.cnblogs.com/li0803...
https://developer.mozilla.org...
https://blog.csdn.net/alan199...