互聯(lián)網(wǎng)/程序員/技術(shù)/資料共享?
https://www.mwcxs.top/page/565.html瀏覽器的緩存機制也就是我們說的HTTP緩存機制,其機制是根據(jù)HTTP報文的緩存標識進行的,所以在分析瀏覽器緩存機制之前,我們先使用圖文簡單介紹一下HTTP報文。HTTP報文分為兩種:HTTP請求(Request)報文,報文格式為:請求行 – HTTP頭(通用信息頭,請求頭,實體頭) – 請求報文主體(只有POST才有報文主體),如下圖
HTTP響應(Response)報文,報文格式為:狀態(tài)行 – 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頭。以上的概念在這里我們不做多講解,只簡單介紹,有興趣的童鞋可以自行研究。緩存過程分析
瀏覽器與服務器通信的方式為應答模式,即是:瀏覽器發(fā)起HTTP請求 – 服務器響應該請求。那么瀏覽器第一次向服務器發(fā)起該請求后拿到請求結(jié)果,會根據(jù)響應報文中HTTP頭的緩存標識,決定是否緩存結(jié)果,是則將請求結(jié)果和緩存標識存入瀏覽器緩存中,簡單的過程如下圖:
瀏覽器每次發(fā)起請求,都會先在瀏覽器緩存中查找該請求的結(jié)果以及緩存標識
瀏覽器每次拿到返回的請求結(jié)果都會將該結(jié)果和緩存標識存入瀏覽器緩存中
以上兩點結(jié)論就是瀏覽器緩存機制的關(guān)鍵,他確保了每個請求的緩存存入與讀取,只要我們再理解瀏覽器緩存的使用規(guī)則,那么所有的問題就迎刃而解了,本文也將圍繞著這點進行詳細分析。為了方便大家理解,這里我們根據(jù)是否需要向服務器重新發(fā)起HTTP請求將緩存過程分為兩個部分,分別是強制緩存和協(xié)商緩存。強制緩存
強制緩存就是向瀏覽器緩存查找該請求結(jié)果,并根據(jù)該結(jié)果的緩存規(guī)則來決定是否使用該緩存結(jié)果的過程,強制緩存的情況主要有三種(暫不分析協(xié)商緩存過程),如下:不存在該緩存結(jié)果和緩存標識,強制緩存失效,則直接向服務器發(fā)起請求(跟第一次發(fā)起請求一致),如下圖:
存在該緩存結(jié)果和緩存標識,但該結(jié)果已失效,強制緩存失效,則使用協(xié)商緩存(暫不分析),如下圖
存在該緩存結(jié)果和緩存標識,且該結(jié)果尚未失效,強制緩存生效,直接返回該結(jié)果,如下圖
當瀏覽器向服務器發(fā)起請求時,服務器會將緩存規(guī)則放入HTTP響應報文的HTTP頭中和請求結(jié)果一起返回給瀏覽器,控制強制緩存的字段分別是Expires和Cache-Control,其中Cache-Control優(yōu)先級比Expires高。Expires
Expires是HTTP/1.0控制網(wǎng)頁緩存的字段,其值為服務器返回該請求結(jié)果緩存的到期時間,即再次發(fā)起該請求時,如果客戶端的時間小于Expires的值時,直接使用緩存結(jié)果。Expires是HTTP/1.0的字段,但是現(xiàn)在瀏覽器默認使用的是HTTP/1.1,那么在HTTP/1.1中網(wǎng)頁緩存還是否由Expires控制?
到了HTTP/1.1,Expire已經(jīng)被Cache-Control替代,原因在于Expires控制緩存的原理是使用客戶端的時間與服務端返回的時間做對比,那么如果客戶端與服務端的時間因為某些原因(例如時區(qū)不同;客戶端和服務端有一方的時間不準確)發(fā)生誤差,那么強制緩存則會直接失效,這樣的話強制緩存的存在則毫無意義,那么Cache-Control又是如何控制的呢?Cache-Control
在HTTP/1.1中,Cache-Control是最重要的規(guī)則,主要用于控制網(wǎng)頁緩存,主要取值為:public:所有內(nèi)容都將被緩存(客戶端和代理服務器都可緩存)
private:所有內(nèi)容只有客戶端可以緩存,Cache-Control的默認取值
no-cache:客戶端緩存內(nèi)容,但是是否使用緩存則需要經(jīng)過協(xié)商緩存來驗證決定
no-store:所有內(nèi)容都不會被緩存,即不使用強制緩存,也不使用協(xié)商緩存
max-age=xxx (xxx is numeric):緩存內(nèi)容將在xxx秒后失效

HTTP響應報文中expires的時間值,是一個絕對值
HTTP響應報文中Cache-Control為max-age=600,是相對值
由于Cache-Control的優(yōu)先級比expires,那么直接根據(jù)Cache-Control的值進行緩存,意思就是說在600秒內(nèi)再次發(fā)起該請求,則會直接使用緩存結(jié)果,強制緩存生效。注:在無法確定客戶端的時間是否與服務端的時間同步的情況下,Cache-Control相比于expires是更好的選擇,所以同時存在時,只有Cache-Control生效。瀏覽器的緩存存放在哪里,如何在瀏覽器中判斷強制緩存是否生效?
這里我們以博客的請求為例,狀態(tài)碼為灰色的請求則代表使用了強制緩存,請求對應的Size值則代表該緩存存放的位置,分別為from memory cache 和 from disk cache。那么from memory cache 和 from disk cache又分別代表的是什么呢?什么時候會使用from disk cache,什么時候會使用from memory cache呢?
from memory cache代表使用內(nèi)存中的緩存,from disk cache則代表使用的是硬盤中的緩存,瀏覽器讀取緩存的順序為memory –> disk。雖然我已經(jīng)直接把結(jié)論說出來了,但是相信有不少人對此不能理解,那么接下來我們一起詳細分析一下緩存讀取問題,這里仍讓以我的博客為例進行分析:訪問https://heyingye.github.io/–> 200 –> 關(guān)閉博客的標簽頁 –> 重新打開https://heyingye.github.io/–> 200(from disk cache) –> 刷新 –> 200(from memory cache)過程如下:訪問https://heyingye.github.io/

重新打開https://heyingye.github.io/

刷新

看到這里可能有人小伙伴問了,最后一個步驟刷新的時候,不是同時存在著from disk cache和from memory cache嗎?
對于這個問題,我們需要了解內(nèi)存緩存(from memory cache)和硬盤緩存(from disk cache),如下:內(nèi)存緩存(from memory cache):內(nèi)存緩存具有兩個特點,分別是快速讀取和時效性:
快速讀取:內(nèi)存緩存會將編譯解析后的文件,直接存入該進程的內(nèi)存中,占據(jù)該進程一定的內(nèi)存資源,以方便下次運行使用時的快速讀取。
時效性:一旦該進程關(guān)閉,則該進程的內(nèi)存則會清空。
硬盤緩存(from disk cache):硬盤緩存則是直接將緩存寫入硬盤文件中,讀取緩存需要對該緩存存放的硬盤文件進行I/O操作,然后重新解析該緩存內(nèi)容,讀取復雜,速度比內(nèi)存緩存慢。
在瀏覽器中,瀏覽器會在js和圖片等文件解析執(zhí)行后直接存入內(nèi)存緩存中,那么當刷新頁面時只需直接從內(nèi)存緩存中讀取(from memory cache);而css文件則會存入硬盤文件中,所以每次渲染頁面都需要從硬盤讀取緩存(from disk cache)。協(xié)商緩存
協(xié)商緩存就是強制緩存失效后,瀏覽器攜帶緩存標識向服務器發(fā)起請求,由服務器根據(jù)緩存標識決定是否使用緩存的過程,主要有以下兩種情況:協(xié)商緩存生效,返回304,如下
協(xié)商緩存失效,返回200和請求結(jié)果結(jié)果,如下
同樣,協(xié)商緩存的標識也是在響應報文的HTTP頭中和請求結(jié)果一起返回給瀏覽器的,控制協(xié)商緩存的字段分別有:Last-Modified / If-Modified-Since和Etag / If-None-Match,其中Etag / If-None-Match的優(yōu)先級比Last-Modified / If-Modified-Since高。Last-Modified / If-Modified-Since
Last-Modified是服務器響應請求時,返回該資源文件在服務器最后被修改的時間,如下。
If-Modified-Since則是客戶端再次發(fā)起該請求時,攜帶上次請求返回的Last-Modified值,通過此字段值告訴服務器該資源上次請求返回的最后被修改時間。服務器收到該請求,發(fā)現(xiàn)請求頭含有If-Modified-Since字段,則會根據(jù)If-Modified-Since的字段值與該資源在服務器的最后被修改時間做對比,若服務器的資源最后被修改時間大于If-Modified-Since的字段值,則重新返回資源,狀態(tài)碼為200;否則則返回304,代表資源無更新,可繼續(xù)使用緩存文件,如下。
Etag / If-None-Match
Etag是服務器響應請求時,返回當前資源文件的一個唯一標識(由服務器生成),如下。
If-None-Match是客戶端再次發(fā)起該請求時,攜帶上次請求返回的唯一標識Etag值,通過此字段值告訴服務器該資源上次請求返回的唯一標識值。服務器收到該請求后,發(fā)現(xiàn)該請求頭中含有If-None-Match,則會根據(jù)If-None-Match的字段值與該資源在服務器的Etag值做對比,一致則返回304,代表資源無更新,繼續(xù)使用緩存文件;不一致則重新返回資源文件,狀態(tài)碼為200,如下。
注:Etag / If-None-Match優(yōu)先級高于Last-Modified / If-Modified-Since,同時存在則只有Etag / If-None-Match生效。總結(jié)
強制緩存優(yōu)先于協(xié)商緩存進行,若強制緩存(Expires和Cache-Control)生效則直接使用緩存,若不生效則進行協(xié)商緩存(Last-Modified / If-Modified-Since和Etag / If-None-Match),協(xié)商緩存由服務器決定是否使用緩存,若協(xié)商緩存失效,那么代表該請求的緩存失效,重新獲取請求結(jié)果,再存入瀏覽器緩存中;生效則返回304,繼續(xù)使用緩存,主要過程如下:
推薦閱讀:
一套簡單通用的Java后臺管理系統(tǒng),拿來即用,非常方便(附項目地址)
RabbitMQ簡介以及應用
5T技術(shù)資源大放送!包括但不限于:C/C++,Linux,Python,Java,PHP,人工智能,單片機,樹莓派,等等。在公眾號內(nèi)回復「2048」,即可免費獲取!!微信掃描二維碼,關(guān)注我的公眾號
朕已閱?