瀏覽器靜態資源的緩存機制（http強緩存 協商緩存）

瀏覽器緩存的都是派生資源。

 

Webkit資源分紅兩類，

一類是主資源，好比HTML頁面，或者下載項，

一類是派生資源，好比HTML頁面中內嵌的圖片或者腳本、樣式表連接，

資源加載失敗的處理，主資源下載失敗會有報錯提示，而派生資源如圖片下載失敗，每每只顯示一個佔位符。

WebKit派生資源包含的類型主要以下：

Javascript腳本（CachedScript）；

CSS樣式文本（CachedCSSStyleSheet）；

圖片（CachedImage）；

字體（CachedFont）；

XSL樣式表（CachedXSLStyleSheet）；

能夠說除了主資源剩下的網絡資源都是派生資源。

 

客戶端緩存就是指用戶設備中的本地資源。

不一樣操做系統不一樣瀏覽器緩存文件的地址也不盡相同。

本人用的mac，實在是沒搞懂這個地址在哪裏。

就以別人的舊圖，windows chrome爲例來查看下瀏覽器緩存文件的地址。

1）首先在chrome中輸入：chrome://chrome-urls/，看到一堆列表,裏面隱藏了許多瀏覽器的奧祕，有興趣的能夠本身深扒。

2）找到 chrome://cache（固然也能夠直接輸入這個地址）

打開一個css緩存文件連接，以下圖pic-1

在圖中能夠看到，客戶端保留了一個服務器端的response header。

header中有不少的字段，舉例說幾個。

Date字段表示這次緩存時服務器的時間。

expires字段表示過時時間，Thu, 28 Sep 2017 06:38:37GMT。

Cache-control: max-age 能夠控制緩存時間。

Last-Modified和ETag也會出如今裏面。

Cache-Control 是 Http1.1 中的標準，能夠當作是 expires 的補充，使用的是相對時間的概念。

也就是說，強緩存和協商緩存用到的字段都在裏面。

 

也能夠得出結論，瀏覽器斷定是否有緩存，就是瀏覽器去判斷本地緩存目錄下是否有該對應的請求

 

下面，咱們根據瀏覽器請求流程來分析瀏覽器靜態資源的緩存機制

 

1️⃣瀏覽器請求，判斷無緩存時（如何判斷緩存上文已講明再也不贅述）：

 

在這個階段（通常爲第一次請求），客戶端判斷本地無緩存時，直接向服務器請求資源。

服務器通常會將Cache-control、expires 、last-modified、date、etag 等字段在response header 中返回，便於下次緩存。固然具體的場景，也是看服務器的約定規則設定。

 

2️⃣瀏覽器請求，判斷有緩存時：

當客戶端判斷本地有緩存時，緊接着要判斷當前緩存資源是否過時。

3️⃣判斷當前緩存是否過時，就是判斷是否命中強緩存的過程

 

強緩存

用戶發送的請求，直接從客戶端緩存中獲取，不發送請求到服務器，不與服務器發生交互行爲。

協商緩存

用戶發送的請求，發送到服務器後，由服務器斷定是否從緩存中獲取資源。

二者共同點：客戶端得到的數據最後都是從客戶端緩存中得到。

 

在介紹如何判斷緩存是否過時前，先簡單介紹下強緩存相關的header字段

expires：這是http1.0時的規範；它的值爲一個絕對時間的GMT格式的時間字符串，如Mon, 10 Jun 2015 21:31:12 GMT，若是發送請求的時間在expires以前，那麼本地緩存始終有效，不然就會發送請求到服務器來獲取資源

cache-control：max-age=number：這是http1.1時出現的header信息，主要是利用該字段的max-age值來進行判斷

Cache-Control的屬性設置：

1）max-age: 設置緩存的最大的有效時間，單位爲秒（s）。max-age會覆蓋掉Expires

2) s-maxage: 只用於共享緩存，好比CDN緩存（s -> share）。

與max-age 的區別是：max-age用於普通緩存，而s-maxage用於代理緩存。若是存在s-maxage,則會覆蓋max-age 和 Expires.

3) public：響應會被緩存，而且在多用戶間共享。默認是public。

4) private: 響應只做爲私有的緩存，不能在用戶間共享。若是要求HTTP認證，響應會自動設置爲private。

5）no-cache: 指定不緩存響應，代表資源不進行緩存。

可是設置了no-cache以後並不表明瀏覽器不緩存，而是須要使用緩存協商，在緩存前要向服務器確認資源是否被更改。所以有的時候只設置no-cache防止緩存仍是不夠保險，還能夠加上private指令，將過時時間設爲過去的時間。

6）no-store: 絕對禁止緩存。

7）must-revalidate: 若是頁面過時，則去服務器進行獲取。

 

以下圖，瀏覽器在請求某一資源時，會先獲取該資源緩存的header信息，判斷是否命中強緩存（cache-control和expires信息）。

 

1）查看是否有cache-control 的max-age / s-maxage , 若是有，則用服務器時間date值 + max-age/s-maxage 的秒數計算出新的過時時間，將當前時間與過時時間進行比較，判斷是否過時

2）查看是否有cache-control 的max-age / s-maxage，若是沒有，則用expires 做爲過時時間比較

 

根據所講的判斷方式，按照上面的流程圖，若是緩存沒有過時，則返回的response狀態爲200 from memory cache或者200 from disk cache，從而直接從緩存獲取資源，包括緩存header信息，不發送請求到服務器。

 

200 from memory cache 

不訪問服務器，直接讀緩存，從內存中讀取緩存。此時的數據時緩存到內存中的，當kill進程後，也就是瀏覽器關閉之後，數據將不存在。可是這種方式只能緩存派生資源

200 from disk cache 不訪問服務器，直接讀緩存，從磁盤中讀取緩存，當kill進程時，數據仍是存在。這種方式也只能緩存派生資源

通常瀏覽圖片，以下流程：

訪問-> 200 -> 退出瀏覽器

再進來-> 200(from disk cache) -> 刷新 -> 200(from memory cache)

 

若是緩存過時了，即沒有命中強緩存，則判斷是否命中協商緩存。

 

Last-modified: 代表請求的資源上次的修改時間。

If-Modified-Since：客戶端保留的資源上次的修改時間。

Etag：資源的內容標識。（不惟一，一般爲文件的md5或者一段hash值，只要保證寫入和驗證時的方法一致便可）

If-None-Match：客戶端保留的資源內容標識。

 

協商緩存都是由服務器來肯定緩存資源是否可用的，因此客戶端與服務器端要經過某種標識來進行通訊，從而讓服務器判斷請求資源是否能夠緩存訪問，這主要涉及到下面兩組header字段，這兩組搭檔都是成對出現的，即第一次請求的響應頭帶上某個字段（Last-Modified或者Etag），則後續請求則會帶上對應的請求字段（If-Modified-Since或者If-None-Match），若響應頭沒有Last-Modified或者Etag字段，則請求頭也不會有對應的字段。

 

1）比對Last-Modified/If-Modified-Since：

 

瀏覽器會發送請求到服務器，請求會攜帶第一次或者上一次請求返回的有關緩存的header字段信息（Last-Modified/If-Modified-Since），服務器再次收到資源請求時，根據瀏覽器傳過來If-Modified-Since和資源在服務器上的最後修改時間判斷資源是否有變化。

 

若是沒有變化，則返回304 Not Modified，可是不會返回資源內容。response header中不會再添加Last-Modified的header，由於既然資源沒有變化，那麼Last-Modified也就不會改變。

 

304 Not Modified 訪問服務器，發現數據沒有更新，服務器返回此狀態碼。而後從緩存中讀取數據。

 

若是有變化，就正常返回資源內容。瀏覽器直接從服務器加載資源時，Last-Modified的Header在從新加載的時候會被更新，下次請求時，If-Modified-Since會啓用上次返回的Last-Modified值

 

2）比對Etag/If-None-Match：

 

這兩個值是由服務器生成的每一個資源的惟一標識字符串，只要資源有變化就這個值就會改變，其判斷過程與Last-Modified/If-Modified-Since相似。

與Last-Modified不同的是，當服務器返回304 Not Modified的響應時，因爲ETag從新生成過，response header中還會把這個ETag返回，即便這個ETag跟以前的沒有變化。

 

HTTP1.1中Etag的出現主要是爲了解決幾個Last-Modified比較難解決的問題：

• 一些文件也許會週期性的更改，可是他的內容並不改變(僅僅改變的修改時間)，這個時候咱們並不但願客戶端認爲這個文件被修改了，而從新GET；
• 某些文件修改很是頻繁，好比在秒如下的時間內進行修改，(比方說1s內修改了N次)，If-Modified-Since能檢查到的粒度是s級的，這種修改沒法判斷(或者說UNIX記錄MTIME只能精確到秒)；
• 某些服務器不能精確的獲得文件的最後修改時間。

這時，利用Etag可以更加準確的控制緩存，由於Etag是服務器自動生成或者由開發者生成的對應資源在服務器端的惟

一標識符。

 

Last-Modified與ETag是能夠一塊兒使用的，服務器會優先驗證ETag，一致的狀況下，纔會繼續比對Last-Modified，最後才決定是否返回304。

 

4️⃣若是沒有命中協商緩存，則直接從服務器獲取數據，返回200

 

 

上面的搞懂了，下面就是個小總結

 

三級緩存原理

1️⃣先去內存看，若是有，直接加載

2️⃣若是內存沒有，擇取硬盤獲取，若是有直接加載

3️⃣若是硬盤也沒有，那麼就進行網絡請求

4️⃣加載到的資源緩存到硬盤和內存

 

用戶行爲

附上一張，用戶行爲影響瀏覽器的緩存行爲。