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

轉載地址:(https://www.cnblogs.com/chengxs/p/10396066.html)

一、概述

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

同步sau交流學習社區(qū)(首發(fā)):https://www.mwcxs.top/page/565.html

1、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ā)起該請求后拿到請求結果泼诱,會根據響應報文中HTTP頭的緩存標識,決定是否緩存結果赊锚,是則將請求結果和緩存標識存入瀏覽器緩存中治筒,簡單的過程如下圖:




由上圖我們可以知道

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

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

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

為了方便大家理解胰锌,這里我們根據是否需要向服務器重新發(fā)起HTTP請求將緩存過程分為兩個部分,分別是強制緩存協(xié)商緩存?藐窄。

2.1強制緩存

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

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



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



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


那么強制緩存的緩存規(guī)則是什么岳守?

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


2.1.1Expires

Expires是HTTP/1.0控制網頁緩存的字段扑庞,其值為服務器返回該請求的結果緩存的到期時間譬重,即再次發(fā)送請求時拒逮,如果客戶端的時間小于Expires的值時,直接使用緩存結果臀规。

Expires是HTTP/1.0的字段滩援,但是現(xiàn)在瀏覽器的默認使用的是HTTP/1.1,那么在HTTP/1.1中網頁緩存還是否由Expires控制以现?

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

那么Cache-Control又是如何進行控制的纪吮?


2.1.2Cache-Control

在HTTP/1.1中俩檬,Cache-Control是最重要的規(guī)則,主要用于控制網頁緩存碾盟,主要取值為:

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

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

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

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

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

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



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

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

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

由于Cache-Control的優(yōu)先級比expires检痰,那么直接根據Cache-Control的值進行緩存包归,意思就是說在600秒內再次發(fā)起該請求,則會直接使用緩存結果铅歼,強制緩存生效公壤。

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


了解強制緩存的過程后俭识,我們拓展性的思考一下:

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



這里我們以博客的請求為例,狀態(tài)碼為灰色的請求則代表使用了強制緩存缚态,請求對應的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。

雖然我已經直接把結論說出來了老虫,但是相信有不少人對此不能理解叶骨,那么接下來我們一起詳細分析一下緩存讀取問題,這里仍讓以我的博客為例進行分析:

訪問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和圖片等文件解析執(zhí)行后直接存入內存緩存中谴餐,那么當刷新頁面時只需直接從內存緩存中讀取(from memory cache)姻政;而css文件則會存入硬盤文件中,所以每次渲染頁面都需要從硬盤讀取緩存(from disk cache)岂嗓。


2.2協(xié)商緩存

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

(1)協(xié)商緩存生效食绿,返回304侈咕,如下


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


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


2.2.1Last-Modified / If-Modified-Since

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


(2)If-Modified-Since則是客戶端再次發(fā)起該請求時狰住,攜帶上次請求返回的Last-Modified值,通過此字段值告訴服務器該資源上次請求返回的最后被修改時間。服務器收到該請求搂誉,發(fā)現(xiàn)請求頭含有If-Modified-Since字段沪斟,則會根據If-Modified-Since的字段值與該資源在服務器的最后被修改時間做對比,若服務器的資源最后被修改時間大于If-Modified-Since的字段值查邢,則重新返回資源,狀態(tài)碼為200酵幕;否則則返回304扰藕,代表資源無更新,可繼續(xù)使用緩存文件芳撒,如下邓深。




2.2.2Etag / If-None-Match

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




2)If-None-Match是客戶端再次發(fā)起該請求時芥备,攜帶上次請求返回的唯一標識Etag值,通過此字段值告訴服務器該資源上次請求返回的唯一標識值舌菜。服務器收到該請求后萌壳,發(fā)現(xiàn)該請求頭中含有If-None-Match,則會根據If-None-Match的字段值與該資源在服務器的Etag值做對比日月,一致則返回304袱瓮,代表資源無更新,繼續(xù)使用緩存文件爱咬;不一致則重新返回資源文件尺借,狀態(tài)碼為200,如下精拟。



注:Etag / If-None-Match優(yōu)先級高于Last-Modified / If-Modified-Since燎斩,同時存在則只有Etag / If-None-Match生效虱歪。

三、總結

強制緩存優(yōu)先于協(xié)商緩存進行瘫里,若強制緩存(Expires和Cache-Control)生效則直接使用緩存实蔽,若不生效則進行協(xié)商緩存(Last-Modified / If-Modified-Since和Etag / If-None-Match),協(xié)商緩存由服務器決定是否使用緩存谨读,若協(xié)商緩存失效局装,那么代表該請求的緩存失效,重新獲取請求結果劳殖,再存入瀏覽器緩存中铐尚;生效則返回304,繼續(xù)使用緩存哆姻,主要過程如下:


?著作權歸作者所有,轉載或內容合作請聯(lián)系作者
  • 序言:七十年代末宣增,一起剝皮案震驚了整個濱河市,隨后出現(xiàn)的幾起案子矛缨,更是在濱河造成了極大的恐慌爹脾,老刑警劉巖,帶你破解...
    沈念sama閱讀 218,036評論 6 506
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件箕昭,死亡現(xiàn)場離奇詭異灵妨,居然都是意外死亡,警方通過查閱死者的電腦和手機落竹,發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 93,046評論 3 395
  • 文/潘曉璐 我一進店門泌霍,熙熙樓的掌柜王于貴愁眉苦臉地迎上來,“玉大人述召,你說我怎么就攤上這事朱转。” “怎么了积暖?”我有些...
    開封第一講書人閱讀 164,411評論 0 354
  • 文/不壞的土叔 我叫張陵藤为,是天一觀的道長。 經常有香客問我夺刑,道長凉蜂,這世上最難降的妖魔是什么? 我笑而不...
    開封第一講書人閱讀 58,622評論 1 293
  • 正文 為了忘掉前任性誉,我火速辦了婚禮,結果婚禮上茎杂,老公的妹妹穿的比我還像新娘错览。我一直安慰自己,他們只是感情好煌往,可當我...
    茶點故事閱讀 67,661評論 6 392
  • 文/花漫 我一把揭開白布倾哺。 她就那樣靜靜地躺著轧邪,像睡著了一般。 火紅的嫁衣襯著肌膚如雪羞海。 梳的紋絲不亂的頭發(fā)上忌愚,一...
    開封第一講書人閱讀 51,521評論 1 304
  • 那天却邓,我揣著相機與錄音硕糊,去河邊找鬼。 笑死腊徙,一個胖子當著我的面吹牛简十,可吹牛的內容都是我干的。 我是一名探鬼主播撬腾,決...
    沈念sama閱讀 40,288評論 3 418
  • 文/蒼蘭香墨 我猛地睜開眼螟蝙,長吁一口氣:“原來是場噩夢啊……” “哼!你這毒婦竟也來了民傻?” 一聲冷哼從身側響起胰默,我...
    開封第一講書人閱讀 39,200評論 0 276
  • 序言:老撾萬榮一對情侶失蹤,失蹤者是張志新(化名)和其女友劉穎漓踢,沒想到半個月后牵署,有當?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體,經...
    沈念sama閱讀 45,644評論 1 314
  • 正文 獨居荒郊野嶺守林人離奇死亡彭雾,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內容為張勛視角 年9月15日...
    茶點故事閱讀 37,837評論 3 336
  • 正文 我和宋清朗相戀三年碟刺,在試婚紗的時候發(fā)現(xiàn)自己被綠了。 大學時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片薯酝。...
    茶點故事閱讀 39,953評論 1 348
  • 序言:一個原本活蹦亂跳的男人離奇死亡半沽,死狀恐怖,靈堂內的尸體忽然破棺而出吴菠,到底是詐尸還是另有隱情者填,我是刑警寧澤,帶...
    沈念sama閱讀 35,673評論 5 346
  • 正文 年R本政府宣布做葵,位于F島的核電站占哟,受9級特大地震影響,放射性物質發(fā)生泄漏酿矢。R本人自食惡果不足惜榨乎,卻給世界環(huán)境...
    茶點故事閱讀 41,281評論 3 329
  • 文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望瘫筐。 院中可真熱鬧蜜暑,春花似錦、人聲如沸策肝。這莊子的主人今日做“春日...
    開封第一講書人閱讀 31,889評論 0 22
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至拙毫,卻和暖如春依许,著一層夾襖步出監(jiān)牢的瞬間,已是汗流浹背缀蹄。 一陣腳步聲響...
    開封第一講書人閱讀 33,011評論 1 269
  • 我被黑心中介騙來泰國打工峭跳, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留,地道東北人袍患。 一個月前我還...
    沈念sama閱讀 48,119評論 3 370
  • 正文 我出身青樓坦康,卻偏偏與公主長得像,于是被迫代替她去往敵國和親诡延。 傳聞我的和親對象是個殘疾皇子滞欠,可洞房花燭夜當晚...
    茶點故事閱讀 44,901評論 2 355

推薦閱讀更多精彩內容