HTTP Cache 淺析

本文轉載至

深刻理解瀏覽器的緩存機制

HTTP Cache 爲何讓人很困惑

查看栗子：

基於http協議講解緩存頭Cache-Control在服務中的應用

1、Private browser caches 和 Shared proxy caches

緩衝這塊並不怎麼好理解，網上查閱的資料，都講的比較模糊，就好比：Private browser caches 和 Shared proxy caches。

瀏覽器緩存的服務架構多是這樣的：瀏覽器（Cache）<=>服務器。
代理服務器緩存架構多是這樣的：瀏覽器 <=> CDN（Cache）<=>源服務器。
複製代碼

不一樣的 HTTP Cache 解決的問題和使用的場景是不同的。我的理解瀏覽器緩存主要是爲了不沒必要要的請求和大量的網絡傳輸，而代理服務器緩存主要是爲了讓服務離用戶更近更有效率（固然也解決了請求和網絡傳輸）。

對於 Web 開發者來講，可能常常遇到的仍是瀏覽器緩存，當咱們訪問一個網站的時候，會進行緩衝，當咱們下一次訪問的時候，可能看到的就是緩衝中加載的頁面。這樣能夠大大加快訪問速度。

2、正確理解 Cache-Control 指令

這個指令是一個通用首部字段，就是說這個指令可以做爲請求和響應指令，同時這個指令的參數也有多個，好比說其參數 max-age = 0 在請求和響應指令中分別表明什麼？在理解的時候必定要分辨清楚。

3、進一步理解 Cache-Control 指令

它有三個含義：

（1）可否緩存（針對響應來講）

private：表示它只應該存在與瀏覽器緩存。
public：表示它能夠緩存在瀏覽器或者 CDN 上。
no-cache：這個詞很迷惑，不是表明不能使用緩存，而是表明在使用前必須到服務器上確認。
no-store：表示不容許被緩存。
複製代碼

（2）緩存多久（針對響應來講）

max-age= 秒，告知瀏覽器這個緩存的有效時間多少。
複製代碼

（3）revalidation（針對響應來講，就是條件檢查）

must-revalidate：
表示瀏覽器必須檢查服務器，確認本地緩存是否有效，這個參數和請求參數 max-age = 0 有些相似。
複製代碼

這個指令形象的告訴瀏覽器，你是否是能夠緩存這個對象，這個對象緩存時間是多少，是否在每次使用緩存的時候先確認下。

一張圖描述的很清晰：

• 這個資源是否容許緩存？
• 客戶端每次使用緩存的時候須要去服務器校驗嗎？
• 這個緩存是 Public 的仍是 Private？
• 緩存時間多少？
• 資源標識符是什麼（Etag）？

4、Expires和Cache-Control二者對比

其實這二者差異不大，區別就在於 Expires 是http1.0的產物，Cache-Control是http1.1的產物，二者同時存在的話，Cache-Control優先級高於Expires；在某些不支持HTTP1.1的環境下，Expires就會發揮用處。因此Expires實際上是過期的產物，現階段它的存在只是一種兼容性的寫法。

5、協商緩衝

協商緩存就是強制緩存失效後，瀏覽器攜帶緩存標識向服務器發起請求，由服務器根據緩存標識決定是否使用緩存的過程，主要有如下兩種狀況：

• 協商緩存生效，返回304和Not Modified

• 協商緩存生效 ,返回200和請求結果

協商緩存能夠經過設置兩種 HTTP Header 實現：Last-Modified 和 ETag 。

1.Last-Modified和If-Modified-Since

瀏覽器在第一次訪問資源時，服務器返回資源的同時，在response header中添加 Last-Modified的header，值是這個資源在服務器上的最後修改時間，瀏覽器接收後緩存文件和header

Last-Modified: Fri, 22 Jul 2016 01:47:00 GMT
複製代碼

瀏覽器下一次請求這個資源，瀏覽器檢測到有 Last-Modified這個header，因而添加If-Modified-Since這個header，值就是Last-Modified中的值；服務器再次收到這個資源請求，會根據 If-Modified-Since 中的值與服務器中這個資源的最後修改時間對比，若是沒有變化，返回304和空的響應體，直接從緩存讀取，若是If-Modified-Since的時間小於服務器中這個資源的最後修改時間，說明文件有更新，因而返回新的資源文件和200

可是 Last-Modified 存在一些弊端：

若是本地打開緩存文件，即便沒有對文件進行修改，但仍是會形成 Last-Modified 被修改，服務端不能命中緩存致使發送相同的資源 由於 Last-Modified 只能以秒計時，若是在不可感知的時間內修改完成文件，那麼服務端會認爲資源仍是命中了，不會返回正確的資源

既然根據文件修改時間來決定是否緩存尚有不足，可否能夠直接根據文件內容是否修改來決定緩存策略？因此在 HTTP / 1.1 出現了 ETag 和If-None-Match

2.ETag和If-None-Match

Etag是服務器響應請求時，返回當前資源文件的一個惟一標識(由服務器生成)，只要資源有變化，Etag就會從新生成。瀏覽器在下一次加載資源向服務器發送請求時，會將上一次返回的Etag值放到request header裏的If-None-Match裏，服務器只須要比較客戶端傳來的If-None-Match跟本身服務器上該資源的ETag是否一致，就能很好地判斷資源相對客戶端而言是否被修改過了。若是服務器發現ETag匹配不上，那麼直接以常規GET 200回包形式將新的資源（固然也包括了新的ETag）發給客戶端；若是ETag是一致的，則直接返回304知會客戶端直接使用本地緩存便可。

3.二者之間對比：

• 首先在精確度上，Etag要優於Last-Modified。

Last-Modified的時間單位是秒，若是某個文件在1秒內改變了屢次，那麼他們的Last-Modified其實並無體現出來修改，可是Etag每次都會改變確保了精度；若是是負載均衡的服務器，各個服務器生成的Last-Modified也有可能不一致。

• 第二在性能上，Etag要遜於Last-Modified，畢竟Last-Modified只須要記錄時間，而Etag須要服務器經過算法來計算出一個hash值。
• 第三在優先級上，服務器校驗優先考慮Etag

6、緩存機制

一般瀏覽器緩存策略分爲兩種：強緩存和協商緩存。若是緩存過時了，咱們就可使用協商緩存來解決問題。協商緩存須要請求，若是緩存有效會返回 304。

7、實際場景應用緩存策略

頻繁變更的資源

Cache-Control: no-cache
複製代碼

對於頻繁變更的資源，首先須要使用Cache-Control: no-cache 使瀏覽器每次都請求服務器，而後配合 ETag 或者 Last-Modified 來驗證資源是否有效。這樣的作法雖然不能節省請求數量，可是能顯著減小響應數據大小。

不常變化的資源

Cache-Control: max-age=31536000
複製代碼

一般在處理這類資源時，給它們的 Cache-Control 配置一個很大的max-age=31536000 (一年)，這樣瀏覽器以後請求相同的 URL 會命中強制緩存。

而爲了解決更新的問題，就須要在文件名(或者路徑)中添加hash， 版本號等動態字符，以後更改動態字符，從而達到更改引用 URL 的目的，讓以前的強制緩存失效 (其實並未當即失效，只是再也不使用了而已)。 在線提供的類庫 (如 jquery-3.3.1.min.js, lodash.min.js 等) 均採用這個模式。

8、用戶行爲對瀏覽器緩存的影響

所謂用戶行爲對瀏覽器緩存的影響，指的就是用戶在瀏覽器如何操做時，會觸發怎樣的緩存策略。主要有 3 種：

• 打開網頁，地址欄輸入地址： 查找 disk cache 中是否有匹配。若有則使用；如沒有則發送網絡請求。

• 普通刷新 (F5)：由於 TAB 並無關閉，所以 memory cache 是可用的，會被優先使用(若是匹配的話)。其次纔是 disk cache。

• 強制刷新 (Ctrl + F5)：瀏覽器不使用緩存，所以發送的請求頭部均帶有 Cache-control: no-cache(爲了兼容，還帶了 Pragma: no-cache),服務器直接返回 200 和最新內容。