讓我們學(xué)習(xí)了解瀏覽器的緩存,提高頁面的流暢度

瀏覽器的緩存機(jī)制也就是我們說的HTTP緩存機(jī)制蒙幻,其機(jī)制是根據(jù)HTTP報(bào)文的緩存標(biāo)識進(jìn)行的胆筒,所以在分析瀏覽器緩存機(jī)制之前,我們先使用圖文簡單介紹一下HTTP報(bào)文抒和,HTTP報(bào)文分為兩種:

  • HTTP請求(Request)報(bào)文彤蔽,報(bào)文格式為:請求行 – HTTP頭(通用信息頭顿痪,請求頭油够,實(shí)體頭) – 請求報(bào)文主體(只有POST才有報(bào)文主體)石咬,如下圖

    Request

    Request
  • HTTP響應(yīng)(Response)報(bào)文鬼悠,報(bào)文格式為:狀態(tài)行 – HTTP頭(通用信息頭亏娜,響應(yīng)頭,實(shí)體頭) – 響應(yīng)報(bào)文主體袜啃,如下圖

    Response

    Response

注:通用信息頭指的是請求和響應(yīng)報(bào)文都支持的頭域群发,分別為Cache-Control熟妓、Connection、Date栏尚、Pragma、Transfer-Encoding译仗、Upgrade、Via阐污;實(shí)體頭則是實(shí)體信息的實(shí)體頭域笛辟,分別為Allow序苏、Content-Base忱详、Content-Encoding围来、Content-Language、Content-Length、Content-Location监透、Content-MD5钦铁、Content-Range、Content-Type才漆、Etag、Expires佛点、Last-Modified醇滥、extension-header。這里只是為了方便理解超营,將通用信息頭鸳玩,響應(yīng)頭/請求頭,實(shí)體頭都?xì)w為了HTTP頭演闭。

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

緩存過程分析

瀏覽器與服務(wù)器通信的方式為應(yīng)答模式虐译,即是:瀏覽器發(fā)起HTTP請求 – 服務(wù)器響應(yīng)該請求。那么瀏覽器第一次向服務(wù)器發(fā)起該請求后拿到請求結(jié)果厢拭,會根據(jù)響應(yīng)報(bào)文中HTTP頭的緩存標(biāo)識供鸠,決定是否緩存結(jié)果,是則將請求結(jié)果和緩存標(biāo)識存入瀏覽器緩存中,簡單的過程如下圖:

cache

由上圖我們可以知道:

  • 瀏覽器每次發(fā)起請求鼻忠,都會先在瀏覽器緩存中查找該請求的結(jié)果以及緩存標(biāo)識

  • 瀏覽器每次拿到返回的請求結(jié)果都會將該結(jié)果和緩存標(biāo)識存入瀏覽器緩存中

以上兩點(diǎn)結(jié)論就是瀏覽器緩存機(jī)制的關(guān)鍵,他確保了每個(gè)請求的緩存存入與讀取澈侠,只要我們再理解瀏覽器緩存的使用規(guī)則,那么所有的問題就迎刃而解了拳球,本文也將圍繞著這點(diǎn)進(jìn)行詳細(xì)分析。為了方便大家理解莱找,這里我們根據(jù)是否需要向服務(wù)器重新發(fā)起HTTP請求將緩存過程分為兩個(gè)部分,分別是強(qiáng)制緩存和**協(xié)商緩存 **。

強(qiáng)制緩存

強(qiáng)制緩存就是向?yàn)g覽器緩存查找該請求結(jié)果壶唤,并根據(jù)該結(jié)果的緩存規(guī)則來決定是否使用該緩存結(jié)果的過程,強(qiáng)制緩存的情況主要有三種(暫不分析協(xié)商緩存過程)迎吵,如下:

  • 不存在該緩存結(jié)果和緩存標(biāo)識桦他,強(qiáng)制緩存失效圆仔,則直接向服務(wù)器發(fā)起請求(跟第一次發(fā)起請求一致)个从,如下圖:


    cache
  • 存在該緩存結(jié)果和緩存標(biāo)識,但該結(jié)果已失效豆瘫,強(qiáng)制緩存失效育灸,則使用協(xié)商緩存(暫不分析)瓦哎,如下圖


    cache
  • 存在該緩存結(jié)果和緩存標(biāo)識,且該結(jié)果尚未失效癣漆,強(qiáng)制緩存生效,直接返回該結(jié)果,如下圖


    cache

那么強(qiáng)制緩存的緩存規(guī)則是什么?

當(dāng)瀏覽器向服務(wù)器發(fā)起請求時(shí)永毅,服務(wù)器會將緩存規(guī)則放入HTTP響應(yīng)報(bào)文的HTTP頭中和請求結(jié)果一起返回給瀏覽器,控制強(qiáng)制緩存的字段分別是ExpiresCache-Control意蛀,其中Cache-Control優(yōu)先級比Expires高。

Expires

Expires是HTTP/1.0控制網(wǎng)頁緩存的字段,其值為服務(wù)器返回該請求結(jié)果緩存的到期時(shí)間谴麦,即再次發(fā)起該請求時(shí)匾效,如果客戶端的時(shí)間小于Expires的值時(shí)精绎,直接使用緩存結(jié)果搁吓。

Expires是HTTP/1.0的字段摩骨,但是現(xiàn)在瀏覽器默認(rèn)使用的是HTTP/1.1,那么在HTTP/1.1中網(wǎng)頁緩存還是否由Expires控制?

到了HTTP/1.1,Expire已經(jīng)被Cache-Control替代,原因在于Expires控制緩存的原理是使用客戶端的時(shí)間與服務(wù)端返回的時(shí)間做對比,那么如果客戶端與服務(wù)端的時(shí)間因?yàn)槟承┰颍ɡ鐣r(shí)區(qū)不同娄帖;客戶端和服務(wù)端有一方的時(shí)間不準(zhǔn)確)發(fā)生誤差削葱,那么強(qiáng)制緩存則會直接失效,這樣的話強(qiáng)制緩存的存在則毫無意義,那么Cache-Control又是如何控制的呢?

Cache-Control

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

  • public:所有內(nèi)容都將被緩存(客戶端和代理服務(wù)器都可緩存)

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

  • no-cache:客戶端緩存內(nèi)容,但是是否使用緩存則需要經(jīng)過協(xié)商緩存來驗(yàn)證決定

  • no-store:所有內(nèi)容都不會被緩存,即不使用強(qiáng)制緩存,也不使用協(xié)商緩存

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

接下來据忘,我們直接看一個(gè)例子汉规,如下:


example

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

  • HTTP響應(yīng)報(bào)文中expires的時(shí)間值坝辫,是一個(gè)絕對值

  • HTTP響應(yīng)報(bào)文中Cache-Control為max-age=600及舍,是相對值

由于Cache-Control的優(yōu)先級比expires拙友,那么直接根據(jù)Cache-Control的值進(jìn)行緩存,意思就是說在600秒內(nèi)再次發(fā)起該請求遗契,則會直接使用緩存結(jié)果,強(qiáng)制緩存生效鲫竞。

注:在無法確定客戶端的時(shí)間是否與服務(wù)端的時(shí)間同步的情況下,Cache-Control相比于expires是更好的選擇妖泄,所以同時(shí)存在時(shí)罚渐,只有Cache-Control生效。

了解強(qiáng)制緩存的過程后缘屹,我們拓展性的思考一下:

瀏覽器的緩存存放在哪里胳挎,如何在瀏覽器中判斷強(qiáng)制緩存是否生效溺森?

disk

這里我們以博客的請求為例慕爬,狀態(tài)碼為灰色的請求則代表使用了強(qiáng)制緩存,請求對應(yīng)的Size值則代表該緩存存放的位置屏积,分別為from memory cachefrom disk cache医窿。

那么from memory cache 和 from disk cache又分別代表的是什么呢?什么時(shí)候會使用from disk cache炊林,什么時(shí)候會使用from memory cache呢姥卢?

from memory cache代表使用內(nèi)存中的緩存,from disk cache則代表使用的是硬盤中的緩存渣聚,瀏覽器讀取緩存的順序?yàn)閙emory –> disk独榴。

過程如下:

看到這里可能有人小伙伴問了,最后一個(gè)步驟刷新的時(shí)候奕枝,不是同時(shí)存在著from disk cache和from memory cache嗎棺榔?

對于這個(gè)問題,我們需要了解內(nèi)存緩存(from memory cache)和硬盤緩存(from disk cache)隘道,如下:

  • 內(nèi)存緩存(from memory cache):內(nèi)存緩存具有兩個(gè)特點(diǎn)症歇,分別是快速讀取時(shí)效性

    • 快速讀取:內(nèi)存緩存會將編譯解析后的文件,直接存入該進(jìn)程的內(nèi)存中谭梗,占據(jù)該進(jìn)程一定的內(nèi)存資源忘晤,以方便下次運(yùn)行使用時(shí)的快速讀取。

    • 時(shí)效性:一旦該進(jìn)程關(guān)閉激捏,則該進(jìn)程的內(nèi)存則會清空设塔。

  • 硬盤緩存(from disk cache):硬盤緩存則是直接將緩存寫入硬盤文件中,讀取緩存需要對該緩存存放的硬盤文件進(jìn)行I/O操作远舅,然后重新解析該緩存內(nèi)容闰蛔,讀取復(fù)雜竞思,速度比內(nèi)存緩存慢。

在瀏覽器中钞护,瀏覽器會在js和圖片等文件解析執(zhí)行后直接存入內(nèi)存緩存中盖喷,那么當(dāng)刷新頁面時(shí)只需直接從內(nèi)存緩存中讀取(from memory cache);而css文件則會存入硬盤文件中难咕,所以每次渲染頁面都需要從硬盤讀取緩存(from disk cache)课梳。

協(xié)商緩存

協(xié)商緩存就是強(qiáng)制緩存失效后,瀏覽器攜帶緩存標(biāo)識向服務(wù)器發(fā)起請求余佃,由服務(wù)器根據(jù)緩存標(biāo)識決定是否使用緩存的過程暮刃,主要有以下兩種情況:

  • 協(xié)商緩存生效,返回304爆土,如下


    304
  • 協(xié)商緩存失效椭懊,返回200和請求結(jié)果結(jié)果,如下


    200

同樣步势,協(xié)商緩存的標(biāo)識也是在響應(yīng)報(bào)文的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是服務(wù)器響應(yīng)請求時(shí)盅抚,返回該資源文件在服務(wù)器最后被修改的時(shí)間,如下倔矾。


    last-modify
  • If-Modified-Since則是客戶端再次發(fā)起該請求時(shí)妄均,攜帶上次請求返回的Last-Modified值,通過此字段值告訴服務(wù)器該資源上次請求返回的最后被修改時(shí)間哪自。服務(wù)器收到該請求丰包,發(fā)現(xiàn)請求頭含有If-Modified-Since字段,則會根據(jù)If-Modified-Since的字段值與該資源在服務(wù)器的最后被修改時(shí)間做對比壤巷,若服務(wù)器的資源最后被修改時(shí)間大于If-Modified-Since的字段值邑彪,則重新返回資源,狀態(tài)碼為200隙笆;否則則返回304锌蓄,代表資源無更新升筏,可繼續(xù)使用緩存文件撑柔,如下。


    since

Etag / If-None-Match

  • Etag是服務(wù)器響應(yīng)請求時(shí)您访,返回當(dāng)前資源文件的一個(gè)唯一標(biāo)識(由服務(wù)器生成)铅忿,如下。


    Etag
  • If-None-Match是客戶端再次發(fā)起該請求時(shí)灵汪,攜帶上次請求返回的唯一標(biāo)識Etag值檀训,通過此字段值告訴服務(wù)器該資源上次請求返回的唯一標(biāo)識值柑潦。服務(wù)器收到該請求后,發(fā)現(xiàn)該請求頭中含有If-None-Match峻凫,則會根據(jù)If-None-Match的字段值與該資源在服務(wù)器的Etag值做對比渗鬼,一致則返回304,代表資源無更新荧琼,繼續(xù)使用緩存文件譬胎;不一致則重新返回資源文件,狀態(tài)碼為200命锄,如下堰乔。


    Etag-match

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

總結(jié)

強(qiáng)制緩存優(yōu)先于協(xié)商緩存進(jìn)行镐侯,若強(qiáng)制緩存(Expires和Cache-Control)生效則直接使用緩存,若不生效則進(jìn)行協(xié)商緩存(Last-Modified / If-Modified-Since和Etag / If-None-Match)驶冒,協(xié)商緩存由服務(wù)器決定是否使用緩存苟翻,若協(xié)商緩存失效,那么代表該請求的緩存失效骗污,重新獲取請求結(jié)果袜瞬,再存入瀏覽器緩存中;生效則返回304身堡,繼續(xù)使用緩存邓尤,主要過程如下:


all

以上便是瀏覽器緩存的過程,若有錯(cuò)誤之處贴谎,敬請指正汞扎。

最后編輯于
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
  • 序言:七十年代末,一起剝皮案震驚了整個(gè)濱河市擅这,隨后出現(xiàn)的幾起案子澈魄,更是在濱河造成了極大的恐慌,老刑警劉巖仲翎,帶你破解...
    沈念sama閱讀 216,402評論 6 499
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件痹扇,死亡現(xiàn)場離奇詭異,居然都是意外死亡溯香,警方通過查閱死者的電腦和手機(jī)鲫构,發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 92,377評論 3 392
  • 文/潘曉璐 我一進(jìn)店門,熙熙樓的掌柜王于貴愁眉苦臉地迎上來玫坛,“玉大人结笨,你說我怎么就攤上這事。” “怎么了炕吸?”我有些...
    開封第一講書人閱讀 162,483評論 0 353
  • 文/不壞的土叔 我叫張陵伐憾,是天一觀的道長。 經(jīng)常有香客問我赫模,道長树肃,這世上最難降的妖魔是什么? 我笑而不...
    開封第一講書人閱讀 58,165評論 1 292
  • 正文 為了忘掉前任瀑罗,我火速辦了婚禮扫外,結(jié)果婚禮上,老公的妹妹穿的比我還像新娘廓脆。我一直安慰自己筛谚,他們只是感情好,可當(dāng)我...
    茶點(diǎn)故事閱讀 67,176評論 6 388
  • 文/花漫 我一把揭開白布停忿。 她就那樣靜靜地躺著驾讲,像睡著了一般。 火紅的嫁衣襯著肌膚如雪席赂。 梳的紋絲不亂的頭發(fā)上吮铭,一...
    開封第一講書人閱讀 51,146評論 1 297
  • 那天,我揣著相機(jī)與錄音颅停,去河邊找鬼谓晌。 笑死,一個(gè)胖子當(dāng)著我的面吹牛癞揉,可吹牛的內(nèi)容都是我干的纸肉。 我是一名探鬼主播,決...
    沈念sama閱讀 40,032評論 3 417
  • 文/蒼蘭香墨 我猛地睜開眼喊熟,長吁一口氣:“原來是場噩夢啊……” “哼柏肪!你這毒婦竟也來了?” 一聲冷哼從身側(cè)響起芥牌,我...
    開封第一講書人閱讀 38,896評論 0 274
  • 序言:老撾萬榮一對情侶失蹤烦味,失蹤者是張志新(化名)和其女友劉穎,沒想到半個(gè)月后壁拉,有當(dāng)?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體谬俄,經(jīng)...
    沈念sama閱讀 45,311評論 1 310
  • 正文 獨(dú)居荒郊野嶺守林人離奇死亡,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點(diǎn)故事閱讀 37,536評論 2 332
  • 正文 我和宋清朗相戀三年弃理,在試婚紗的時(shí)候發(fā)現(xiàn)自己被綠了溃论。 大學(xué)時(shí)的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片。...
    茶點(diǎn)故事閱讀 39,696評論 1 348
  • 序言:一個(gè)原本活蹦亂跳的男人離奇死亡案铺,死狀恐怖蔬芥,靈堂內(nèi)的尸體忽然破棺而出梆靖,到底是詐尸還是另有隱情控汉,我是刑警寧澤笔诵,帶...
    沈念sama閱讀 35,413評論 5 343
  • 正文 年R本政府宣布,位于F島的核電站姑子,受9級特大地震影響乎婿,放射性物質(zhì)發(fā)生泄漏。R本人自食惡果不足惜街佑,卻給世界環(huán)境...
    茶點(diǎn)故事閱讀 41,008評論 3 325
  • 文/蒙蒙 一谢翎、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧沐旨,春花似錦森逮、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 31,659評論 0 22
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至谊迄,卻和暖如春闷供,著一層夾襖步出監(jiān)牢的瞬間,已是汗流浹背统诺。 一陣腳步聲響...
    開封第一講書人閱讀 32,815評論 1 269
  • 我被黑心中介騙來泰國打工歪脏, 沒想到剛下飛機(jī)就差點(diǎn)兒被人妖公主榨干…… 1. 我叫王不留,地道東北人粮呢。 一個(gè)月前我還...
    沈念sama閱讀 47,698評論 2 368
  • 正文 我出身青樓婿失,卻偏偏與公主長得像,于是被迫代替她去往敵國和親啄寡。 傳聞我的和親對象是個(gè)殘疾皇子移怯,可洞房花燭夜當(dāng)晚...
    茶點(diǎn)故事閱讀 44,592評論 2 353