輕鬆學會HTTP緩存（強緩存，協商緩存）

若讀者對「強緩存」，「協商緩存」字眼很是熟悉，但又不知道他們具體是什麼，亦或有讀者還不瞭解HTTP緩存，那麼本文將爲讀者一一講解。

歡迎Star和訂閱 個人博客。

HTTP緩存流程

在介紹什麼是強緩存、協商緩存前，讓咱們先了解HTTP緩存的流程，由於強緩存、協商緩存只是其中2步。

強緩存

「檢查緩存是否過時」一步即強緩存。若緩存未過時，直接使用瀏覽器本地緩存，不用請求服務器。

檢查緩存是否過時依據請求報文中的2種首部：過時時間Expires和有效時間Cache-Control:max-age。例子：

• Expires: Fri, 05, Jul, 2020, 05:00:00 GMT
• Cache-Control: max-age=60000

前者爲緩存具體的過時時間，後者爲緩存有效期。Cache-Control: max-age的優先級高於Expires。

協商緩存

「協商緩存」能夠理解爲一個動做：「與服務器協商是否更新緩存」。

當檢查到緩存已過時，緩存端須要與服務器協商是否更新緩存。在請求報文中，用於協商的條件類首部也有2種，時間再驗證If-Modified-Since和實體標籤再驗證If-No-Matched。若條件爲真，服務器會返回新文檔給緩存。不然，服務器返回304(Not Modified)。它們的格式爲:

• If-Modified-Since: <date>
• If-None-Matched: <tags>

日期再驗證If-Modified-Since從字面便可理解：如何從某個時間以後文檔被修改過。

實體標籤再驗證If-None-Matched一樣可理解爲：若緩存端的實體標籤Etag(Entity Tag)與服務器不匹配。

實體標籤是什麼？ 這裏要從既然有了日期再驗證爲什麼還須要實體標籤驗證提及。

考慮一種特殊狀況，若驗證時，發現服務器上的文檔被重寫過文件修改時間，但內容不變，那這個時候日期再驗證不經過，但實際並無必要更新文檔。因此引入了實體標籤驗證。實體標籤Etag是爲文檔提供的特殊標籤，格式爲字符串，可看做惟一id。

若實體標籤再驗證不經過，服務器會返回新文檔和新的Etag給緩存。

實體標籤再驗證的優先級高於日期再驗證。

客戶端刷新和重載

那麼客戶端的刷新和重載如何影響HTTP緩存？事實上，每一個瀏覽器都由本身的一套處理機制。通常來講，普通刷新不會影響緩存，但強制刷新（重載）會讓緩存失效，從新向請求服務器文檔。

實踐

光有理論沒有實踐驗證確定不夠。此處使用一個案例體驗協商緩存。

新建一個文件夾，新建index.html, 內容爲「Test Cache」。使用serve將該文件夾靜態服務化。打開Chrome，新建標籤頁，打開開發人員工具，切換到網絡模塊，而後打開服務化後的地址: http://localhost:5000。

可看到服務返回狀態爲200。
接下來刷新頁面。

服務器返回狀態變爲304(Not Modified)。

請求首部用的是實體標籤再驗證If-None-Match:<tag>。

響應首部返回的Etag與請求中的Etag相同。

總結

HTTP緩存的2個要點就是：

1. 檢查緩存是否過時（強緩存）
2. 若緩存過時，與服務器協商是否更新緩存（協商緩存）。

而這2點每一個都包含相關的2個報文請求首部：

• 強緩存：過時時間Expires 和有效期Cache-Control: max-age
• 協商緩存：日期再驗證If-Modified-Since和實體標籤再驗證If-Not-Matched

參考資料

• 《HTTP權威指南》 > 第7章 > 緩存
• 強緩存和協商緩存區別和過程

感謝你花時間閱讀這篇文章。若是你喜歡這篇文章，歡迎點贊、收藏和分享，讓更多的人看到這篇文章，這也是對我最大的鼓勵和支持！

歡迎經過微信（掃描下方二維碼）或Github訂閱個人博客。