深刻現代瀏覽器的HTTP緩存機制

前言

寫這篇文章的緣由是最近在研究PWA如何在項目中落地實施，這就無可避免的須要接觸到瀏覽器緩存的相關知識，所以特地寫下這篇文章鞏固下本身對瀏覽器緩存的認識。

什麼是HTTP緩存

緩存是一種保存資源副本並在下次請求時直接使用該副本的技術。當web緩存發現請求的資源已經被存儲，它會攔截請求，返回該資源的拷貝，而不會去源服務器從新下載。這樣帶來的好處有：緩解服務器端壓力，提高性能(獲取資源的耗時更短了)。

HTTP緩存的做用

咱們都知道瀏覽器是基於HTTP協議和服務端進行通訊的，一個網站一旦同時請求過多或者請求過大就容易形成頁面渲染時長過長等性能問題，並且並不是全部資源都須要實時更新的，將長久或一段時間內的資源進行緩存，能很大的緩解服務器壓力和提高網站性能。
絕不誇張的說，HTTP緩存是達到高性能的重要組成部分。

注意：緩存須要合理配置，由於並非全部資源都是永久不變的：重要的是對一個資源的緩存應截止到其下一次發生改變（即不能緩存過時的資源）。

HTTP頭緩存相關字段及優先級

強緩存：Expires: Date/Cache-Control：max-age=N
協商緩存：Last-Modified：Date和Etag：String

經過查詢標準咱們知道Cache-Control和Etag屬於HTTP1.1版本，Expires和Last-Modified屬於HTTP1.0版本，因此得出如下優先級：
強緩存：Cache-Control > Expires
協商緩存：Etag > Last-Modified

注意：
Expires存在的缺陷是返回的到期時間是服務器端的時間，可能與客戶端的時間有較大的時間差，因此在HTTP1.1版開始使用Cache-Control: max-age=秒替代
Last-Modified的缺陷：因爲只能精確到秒，若是一個文件在1秒內屢次修改，這時客戶端沒法識別，所以HTTP1.1版本使用Etag標識資源內容是否有變動來確認資源是否須要更新，相對來講更加精確

強緩存與協商緩存

強緩存：資源一旦被強緩存，在緩存時間內，瀏覽器發起二次請求時會直接讀取本地緩存，不與服務器進行通信。 強緩存時間過時的，瀏覽器會判斷資源的響應頭是否有Last-Modified和Etag字段，有的話執行協商緩存策略

協商緩存：若是響應頭中的包括有Etag和Last-Modified字段，則客戶端將If-None-Match：Etag的值和If-Modified-Since：Last-Modified的值添加到請求頭髮送給服務器，由源服務器校驗，若是資源未過時則返回304狀態碼，瀏覽器直接使用緩存，不然返回200OK狀態碼和新資源。

當兩種狀況都存在時，強緩存優先級要高於協商緩存。

Chrome瀏覽器的三種緩存策略

選擇Chrome是由於它是如今最流行的網頁調試工具也是最多人用的瀏覽器。 Chrome瀏覽器返回緩存http狀態碼總共有如下三個 一、200 from memory cache 客戶端不與服務器通信，直接從內存中讀取緩存。此時的數據時緩存到內存中的，當關閉瀏覽器後，數據天然就被當垃圾回收清空。

二、200 from disk cache 客戶端不與服務器通信，直接從磁盤中讀取緩存，由於數據存在磁盤中，就算關閉瀏覽器數據仍是存在，下次打開只要數據不過時就能夠直接讀取。

三、304 Not Modified 客戶端與服務器通信，服務器驗證資源是否須要更新，若是不須要更新服務器返回304狀態碼，而後客戶端直接從緩存中讀取數據

注意：通過測試，我發現Safari和Firefox都有三種緩存策略，IE和其餘瀏覽器你們能夠各自測試一下

瀏覽器三種緩存示例圖

Chrome和Safari彷佛沒有辦法在瀏覽器中直接查看緩存狀況，所以只能實踐中查看。 Chrome示例圖: 狀態碼：200 OK

狀態碼： 200 from memeory cache

狀態碼： 200 from disk cache

狀態碼： 304 Not Modified

)

Safari示例圖： 響應頭：

狀態碼：200 OK

狀態碼：200 內存

狀態碼：200 磁盤

Firefox：在url上輸入about:cache 能夠看到對應的緩存狀況，你們能夠試一下

從截圖中能夠看到Firefox也分爲內存緩存和磁盤緩存，304Not Modified天然也是有的。

資源被強緩存後狀態碼依然是200 OK，不過會在傳輸列下顯示已緩存，可是沒法看出是內存緩存仍是磁盤緩存。

Firefox的304與Chrome和Safari差異不大。

三種緩存策略實際執行的條件

我在網上看到有人寫文章說 js、圖片和字體保存在內存中而css則保存在磁盤，很明顯，只要本身稍微測試一下就知道這種說法是站不住腳的，那麼這三種狀況到底是怎樣的呢？

通過簡單的測試之後我發現這三種策略並不複雜，默認配置狀況下，Chrome第一次請求資源後，若是資源的響應頭有Cache-Control或者Expires且有效期大於如今，則加載數據後將強緩存資源到內存和磁盤。
刷新頁面，Chrome發起整個頁面的二次請求後，經過開發者工具能夠看到強緩存資源都會從內存進行讀取，這就是200 from memory cache的狀況。

示例：
這時關閉瀏覽器後，從新打開瀏覽器並打開關閉前的頁面，經過開發者工具能夠看到以前強緩存資源都會從磁盤中讀取，這是由於關閉了瀏覽器後系統回收了內存資源，所以內存沒有了以前的強緩存資源，須要從磁盤中讀取，這就是200 from disk cache的狀況。

示例：
若是這時使用ctrl + f5強刷頁面則會發現所有資源都是200 OK狀態要從服務器中獲取新數據。

304 Not Modified的狀況則徹底不一樣，若是資源的響應頭是Last-Modified或Etag，第一次請求資源後緩存到本地磁盤，但第二次也必須發起請求到服務器進行查詢該資源是否過時或被修改過，當服務器驗證資源沒有過時後纔會返回304 Not Modified狀態碼，同時響應體爲空，這樣能夠節省流量並提升響應速度，客戶端接收到304狀態碼後從本地讀取數據，所以304比200 from cache響應速度要慢，但比200 OK快得多。

Chrome瀏覽器緩存機制流程圖

上述說法均爲我的想法，若有不對，敬請指出，謝謝你們的閱讀!