徹底理解瀏覽器的快取機制

2022-03-07 02:54:48 字數 4058 閱讀 1671

瀏覽器的快取機制也就是我們說的http快取機制,其機制是根據http報文的快取標識進行的,所以在分析瀏覽器快取機制之前,我們先使用**簡單介紹一下http報文,http報文分為兩種:

注:通用資訊頭指的是請求和響應報文都支援的頭域,分別為cache-control、connection、date、pragma、transfer-encoding、upgrade、via;實體頭則是實體資訊的實體頭域,分別為allow、content-base、content-encoding、content-language、content-length、content-location、content-md5、content-range、content-type、etag、expires、last-modified、extension-header。這裡只是為了方便理解,將通用資訊頭,響應頭/請求頭,實體頭都歸為了http頭。

以上的概念在這裡我們不做多講解,只簡單介紹,有興趣的童鞋可以自行研究。

瀏覽器與伺服器通訊的方式為應答模式,即是:瀏覽器發起http請求 – 伺服器響應該請求。那麼瀏覽器第一次向伺服器發起該請求後拿到請求結果,會根據響應報文中http頭的快取標識,決定是否快取結果,是則將請求結果和快取標識存入瀏覽器快取中,簡單的過程如下圖:

由上圖我們可以知道:

以上兩點結論就是瀏覽器快取機制的關鍵,他確保了每個請求的快取存入與讀取,只要我們再理解瀏覽器快取的使用規則,那麼所有的問題就迎刃而解了,本文也將圍繞著這點進行詳細分析。為了方便大家理解,這裡我們根據是否需要向伺服器重新發起http請求將快取過程分為兩個部分,分別是強制快取協商快取

強制快取就是向瀏覽器快取查詢該請求結果,並根據該結果的快取規則來決定是否使用該快取結果的過程,強制快取的情況主要有三種(暫不分析協商快取過程),如下:

那麼強制快取的快取規則是什麼?

當瀏覽器向伺服器發起請求時,伺服器會將快取規則放入http響應報文的http頭中和請求結果一起返回給瀏覽器,控制強制快取的字段分別是expirescache-control,其中cache-control優先順序比expires高。

expires

expires是http/1.0控制網頁快取的字段,其值為伺服器返回該請求結果快取的到期時間,即再次發起該請求時,如果客戶端的時間小於expires的值時,直接使用快取結果。

expires是http/1.0的字段,但是現在瀏覽器預設使用的是http/1.1,那麼在http/1.1中網頁快取還是否由expires控制?

到了http/1.1,expire已經被cache-control替代,原因在於expires控制快取的原理是使用客戶端的時間與服務端返回的時間做對比,那麼如果客戶端與服務端的時間因為某些原因(例如時區不同;客戶端和服務端有一方的時間不準確)發生誤差,那麼強制快取則會直接失效,這樣的話強制快取的存在則毫無意義,那麼cache-control又是如何控制的呢?

cache-control

在http/1.1中,cache-control是最重要的規則,主要用於控制網頁快取,主要取值為:

接下來,我們直接看乙個例子,如下:

由上面的例子我們可以知道:

由於cache-control的優先順序比expires,那麼直接根據cache-control的值進行快取,意思就是說在600秒內再次發起該請求,則會直接使用快取結果,強制快取生效。

注:在無法確定客戶端的時間是否與服務端的時間同步的情況下,cache-control相比於expires是更好的選擇,所以同時存在時,只有cache-control生效。

了解強制快取的過程後,我們拓展性的思考一下:

瀏覽器的快取存放在**,如何在瀏覽器中判斷強制快取是否生效?

這裡我們以部落格的請求為例,狀態碼為灰色的請求則代表使用了強制快取,請求對應的size值則代表該快取存放的位置,分別為from memory cachefrom disk cache

那麼from memory cache 和 from disk cache又分別代表的是什麼呢?什麼時候會使用from disk cache,什麼時候會使用from memory cache呢?

from memory cache代表使用記憶體中的快取,from disk cache則代表使用的是硬碟中的快取,瀏覽器讀取快取的順序為memory –> disk。

雖然我已經直接把結論說出來了,但是相信有不少人對此不能理解,那麼接下來我們一起詳細分析一下快取讀取問題,這裡仍讓以我的部落格為例進行分析:

訪問 –> 200 –> 關閉部落格的標籤頁 –> 重新開啟 –> 200(from disk cache) –> 重新整理 –> 200(from memory cache)

過程如下:

看到這裡可能有人小夥伴問了,最後乙個步驟重新整理的時候,不是同時存在著from disk cache和from memory cache嗎?

對於這個問題,我們需要了解記憶體快取(from memory cache)和硬碟快取(from disk cache),如下:

硬碟快取(from disk cache):硬碟快取則是直接將快取寫入硬碟檔案中,讀取快取需要對該快取存放的硬碟檔案進行i/o操作,然後重新解析該快取內容,讀取複雜,速度比記憶體快取慢。

在瀏覽器中,瀏覽器會在js和等檔案解析執行後直接存入記憶體快取中,那麼當重新整理頁面時只需直接從記憶體快取中讀取(from memory cache);而css檔案則會存入硬碟檔案中,所以每次渲染頁面都需要從硬碟讀取快取(from disk cache)。

協商快取就是強制快取失效後,瀏覽器攜帶快取標識向伺服器發起請求,由伺服器根據快取標識決定是否使用快取的過程,主要有以下兩種情況:

同樣,協商快取的標識也是在響應報文的http頭中和請求結果一起返回給瀏覽器的,控制協商快取的字段分別有:last-modified / if-modified-since和etag / if-none-match,其中etag / if-none-match的優先順序比last-modified / if-modified-since高。

last-modified / if-modified-since

etag / if-none-match

注:etag / if-none-match優先順序高於last-modified / if-modified-since,同時存在則只有etag / if-none-match生效。

強制快取優先於協商快取進行,若強制快取(expires和cache-control)生效則直接使用快取,若不生效則進行協商快取(last-modified / if-modified-since和etag / if-none-match),協商快取由伺服器決定是否使用快取,若協商快取失效,那麼代表該請求的快取失效,重新獲取請求結果,再存入瀏覽器快取中;生效則返回304,繼續使用快取,主要過程如下:

**[徹底理解瀏覽器的快取機制](2018/04/16/%e5%bd%bb%e5%ba%95%e7%90%86%e8%a7%a3%e6%b5%8f%e8%a7%88%e5%99%a8%e7%9a%84%e7%bc%93%e5%ad%98%e6%9c%ba%e5%88%b6/)

徹底理解瀏覽器的快取機制

瀏覽器的快取機制也就是我們說的http快取機制,其機制是根據http報文的快取標識進行的,所以在分析瀏覽器快取機制之前,我們先使用 簡單介紹一下http報文,http報文分為兩種 注 通用資訊頭指的是請求和響應報文都支援的頭域,分別為cache control connection date pra...

瀏覽器快取機制個人理解

瀏覽器快取究竟有什麼作用呢?在這裡我將瀏覽器快取的作用簡單地歸結為以下幾點。加快頁面開啟速度 降低伺服器壓力 減少網路損耗 瀏覽器快取有 html meta 標籤控制 一般不用,所以本文不介紹 與 http 頭資訊控制兩種。快取標識字段便是expires和cache control。expires ...

瀏覽器快取機制

最近在準備優化日誌請求時遇到了一些令人疑惑的問題,比如為什麼響應頭里出現了兩個 cache control 為什麼明明設定了 no cache 卻還是發請求,為什麼多次訪問時有時請求裡帶了 etag,有時又沒有帶?等等。後來查了一些資料以及同事親自驗證,總算對這些問題有了個清晰的理解,現在整理出來以...