徹底理解瀏覽器的緩存機制(http緩存機制)

學習HTTP緩存時看到一篇不錯的文章,推薦大家閱讀:

原文地址:https://www.cnblogs.com/chengxs/p/10396066.html

一、概述

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

1、HTTP請求(Request)報文,報文格式爲:請求行 – HTTP頭(通用信息頭,請求頭,實體頭) – 請求報文主體(只有POST纔有報文主體),如下圖

 

 

HTTP響應(Response)報文,報文格式爲:狀態行 – 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頭的緩存標識,決定是否緩存結果,是則將請求結果和緩存標識存入瀏覽器緩存中,簡單的過程如下圖:

由上圖我們可以知道

1、瀏覽器每次發起請求,都會先在瀏覽器緩存中查找該請求的結果以及緩存標識

2、瀏覽器每次拿到返回的請求結果都會將該結果和緩存標識存入瀏覽器緩存中

以上兩點結論就是瀏覽器緩存機制的關鍵,他確保了每個請求的緩存存入與讀取,只要我們再理解瀏覽器緩存的使用規則,那麼所有的問題就迎刃而解了,本文也將圍繞着這點進行詳細分析。

爲了方便大家理解,這裏我們根據是否需要向服務器重新發起HTTP請求將緩存過程分爲兩個部分,分別是強制緩存協商緩存 

2.1強制緩存

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

(1)不存在該緩存結果和緩存標識,強制緩存失效,則直接向服務器發起請求(跟第一次發起請求一致),如下圖:

(2)存在該緩存結果和緩存標識,但是結果已經失效,強制緩存失效,則使用協商緩存(暫不分析),如下圖

(3)存在該緩存結果和緩存標識,且該結果沒有還沒有失效,強制緩存生效,直接返回該結果,如下圖:

那麼強制緩存的緩存規則是什麼?

答:當瀏覽器向服務器發送請求的時候,服務器會將緩存規則放入HTTP響應的報文的HTTP頭中和請求結果一起返回給瀏覽器,控制強制緩存的字段分別是Expires和Cache-Control,其中Cache-Conctrol的優先級比Expires高。

 

2.1.1Expires

Expires是HTTP/1.0控制網頁緩存的字段,其值爲服務器返回該請求的結果緩存的到期時間,即再次發送請求時,如果客戶端的時間小於Expires的值時,直接使用緩存結果。

Expires是HTTP/1.0的字段,但是現在瀏覽器的默認使用的是HTTP/1.1,那麼在HTTP/1.1中網頁緩存還是否由Expires控制?

到了HTTP/1.1,Expires已經被Cache-Control替代,原因在於Expires控制緩存的原理是使用客戶端的時間服務端返回的時間做對比,如果客戶端與服務端的時間由於某些原因(時區不同;客戶端和服務端有一方的時間不準確)發生誤差,那麼強制緩存直接失效,那麼強制緩存存在的意義就毫無意義。、

那麼Cache-Control又是如何進行控制的?

 

2.1.2Cache-Control

在HTTP/1.1中,Cache-Control是最重要的規則,主要用於控制網頁緩存,主要取值爲:

(1)public:所有內容都將被緩存(客戶端和代理服務器都可緩存)

(2)private:所有內容只有客戶端可以緩存,Cache-Control的默認取值

(3)no-cache:客戶端緩存內容,但是是否使用緩存則需要經過協商緩存來驗證決定

(4)no-store:所有內容都不會被緩存,即不使用強制緩存,也不使用協商緩存

(5)max-age=xxx (xxx is numeric):緩存內容將在xxx秒後失效

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

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

(1)HTTP響應報文中expires的時間值,是一個絕對值

(2)HTTP響應報文中Cache-Control爲max-age=600,是相對值

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

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

 

瞭解強制緩存的過程後,我們拓展性的思考一下:

瀏覽器的緩存存放在哪裏,如何在瀏覽器中判斷強制緩存是否生效?

這裏我們以博客的請求爲例,狀態碼爲灰色的請求則代表使用了強制緩存,請求對應的Size值則代表該緩存存放的位置,分別爲from memory cache 和 from disk cache

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

from memory cache代表使用內存中的緩存,from disk cache則代表使用的是硬盤中的緩存,瀏覽器讀取緩存的順序爲memory –> disk。

雖然我已經直接把結論說出來了,但是相信有不少人對此不能理解,那麼接下來我們一起詳細分析一下緩存讀取問題,這裏仍讓以我的博客爲例進行分析:
訪問https://heyingye.github.io/ –> 200 –> 關閉博客的標籤頁 –> 重新打開https://heyingye.github.io/ –> 200(from disk cache) –> 刷新 –> 200(from memory cache)

 

過程如下:

(1)訪問博客網站

(2)關閉博客的標籤頁

(3)重新打開博客

(4)刷新

 

看到這裏可能有人小夥伴問了,最後一個步驟刷新的時候,不是同時存在着from disk cache和from memory cache嗎?

對於這個問題,我們需要了解內存緩存(from memory cache)和硬盤緩存(from disk cache),如下:

(1)內存緩存(from memory cache):內存緩存具有兩個特點,分別是快速讀取時效性

1、快速讀取:內存緩存會將編譯解析後的文件,直接存入該進程的內存中,佔據該進程一定的內存資源,以方便下次運行使用時的快速讀取。

2、時效性:一旦該進程關閉,則該進程的內存則會清空。

(2)硬盤緩存(from disk cache):硬盤緩存則是直接將緩存寫入硬盤文件中,讀取緩存需要對該緩存存放的硬盤文件進行I/O操作,然後重新解析該緩存內容,讀取複雜,速度比內存緩存慢。

 

在瀏覽器中,瀏覽器會在js和圖片等文件解析執行後直接存入內存緩存中,那麼當刷新頁面時只需直接從內存緩存中讀取(from memory cache);而css文件則會存入硬盤文件中,所以每次渲染頁面都需要從硬盤讀取緩存(from disk cache)。

 

2.2協商緩存

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

(1)協商緩存生效,返回304,如下

(2)協商緩存失敗,返回200和請求結果,如下

同樣,協商緩存的標識也是在響應報文的HTTP頭中和請求結果一起返回給瀏覽器的,控制協商緩存的字段分別有:Last-Modified / If-Modified-Since和Etag / If-None-Match,其中Etag / If-None-Match的優先級比Last-Modified / If-Modified-Since高。

 

2.2.1Last-Modified / If-Modified-Since

(1)Last-Modified是服務器響應請求時,返回該資源文件在服務器最後被修改的時間,如下:

(2)If-Modified-Since則是客戶端再次發起該請求時,攜帶上次請求返回的Last-Modified值,通過此字段值告訴服務器該資源上次請求返回的最後被修改時間。服務器收到該請求,發現請求頭含有If-Modified-Since字段,則會根據If-Modified-Since的字段值與該資源在服務器的最後被修改時間做對比,若服務器的資源最後被修改時間大於If-Modified-Since的字段值,則重新返回資源,狀態碼爲200;否則則返回304,代表資源無更新,可繼續使用緩存文件,如下。

 

2.2.2Etag / If-None-Match

(1)Etag是服務器響應請求時,返回當前資源文件的一個唯一標識(由服務器生成),如下:

(2)If-None-Match是客戶端再次發起該請求時,攜帶上次請求返回的唯一標識Etag值,通過此字段值告訴服務器該資源上次請求返回的唯一標識值。服務器收到該請求後,發現該請求頭中含有If-None-Match,則會根據If-None-Match的字段值與該資源在服務器的Etag值做對比,一致則返回304,代表資源無更新,繼續使用緩存文件;不一致則重新返回資源文件,狀態碼爲200,如下。

注: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,繼續使用緩存,主要過程如下:

以上便是瀏覽器緩存的過程

 

發佈了98 篇原創文章 · 獲贊 43 · 訪問量 20萬+
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章