實踐這一次徹底搞懂瀏覽器緩存機制

刖百

［實踐系列］主要是讓我們通過實踐去加深對一些原理的理解。

實踐系列-前端路由

實踐系列-Babel原理

實踐系列-Promises/A+規(guī)范

有興趣的同學(xué)可以關(guān)注實踐系列。求star求follow-

如果覺得自己已經(jīng)掌握瀏覽器緩存機制知識的同學(xué)，可以直接看實踐部分哈~

目錄

DNS緩存//雖說跟標(biāo)題關(guān)系不大，了解一下也不錯

2.CDN緩存//雖說跟標(biāo)題關(guān)系不大，了解一下也不錯

3.瀏覽器緩存//本文將重點介紹并實踐

DNS緩存

什么是DNS

全稱DomainNameSystem，即域名系統(tǒng)。

萬維網(wǎng)上作為域名和IP地址相互映射的一個分布式數(shù)據(jù)庫，能夠

使用戶更方便的訪問互聯(lián)網(wǎng)，而不用去記住能夠被機器直接讀取的

IP數(shù)串。DNS協(xié)議運行在UDP協(xié)議之上，使用端口號53。

DNS解析

簡單的說，通過域名，最終得到該域名對應(yīng)的IP地址的過程叫做域名解析（或主機

名解析）。

wwwd八scackc.cona（域名）-DNS解析-〉工工.222J3.444（IP地址）

DNS緩存

有dns的地方，就有緩存。瀏覽器、操作系統(tǒng)、LocalDNS、根域名服務(wù)器，它們

都會對DNS結(jié)果做一定程度的緩存。

DNS查詢過程如下：

1.首先搜索瀏覽器自身的DNS緩存，如果存在，則域名解析到此完成。

2.如果瀏覽器自身的緩存里面沒有找到對應(yīng)的條目，那么會嘗試讀取操作系

統(tǒng)的hosts文件看是否存在對應(yīng)的映射關(guān)系，如果存在，則域名解析到此完

成。

3.如果本地hosts文件不存在映射關(guān)系，則查找本地DNS服務(wù)器（ISP服務(wù)

器,或者自己手動設(shè)置的DNS服務(wù)器），如果存在,域名到此解析完成。

4.如果本地DNS服務(wù)器還沒找到的話，它就會向根服務(wù)器發(fā)出請求,進行遞

歸查詢。

戳此處詳細了解DNS解析過程

CDN緩存

什么是CDN

全稱ContentDeliveryNetwork,即內(nèi)容分發(fā)網(wǎng)絡(luò)。

摘錄一個形象的比喻，來理解CDN是什么。

10年前，還沒有火車票代售點一說，12306.cn更是無從說起。那

時候火車票還只能在火車站的售票大廳購買，而我所在的小縣城并

不通火車，火車票都要去市里的火車站購買，而從我家到縣城再到

市里，來回就是4個小時車程，簡直就是浪費生命。后來就好了，

小縣城里出現(xiàn)了火車票代售點，甚至鄉(xiāng)鎮(zhèn)上也有了代售點，可以直

接在代售點購買火車票，方便了不少，全市人民再也不用在一個點

苦逼的排隊買票了。

簡單的理解CDN就是這些代售點（緩存服務(wù)器）的承包商，他為買票者提供了便利,

幫助他們在最近的地方（最近的CDN節(jié)點）用最短的時間（最短的請求時間）買到票

（拿到資源），這樣去火車站售票大廳排隊的人也就少了。也就減輕了售票大廳的壓

力（起到分流作用，減輕服務(wù)器負載壓力）。

用戶在瀏覽網(wǎng)站的時候，CDN會選擇一個離用戶最近的CDN邊緣節(jié)點來響應(yīng)用

戶的請求，這樣海南移動用戶的請求就不會千里迢迢跑到北京電信機房的服務(wù)器

（假設(shè)源站部署在北京電信機房）上了。

CDN緩存

關(guān)于CDN緩存，在瀏覽器本地緩存失效后，瀏覽器會向CDN邊緣節(jié)點發(fā)起請求。

類似瀏覽器緩存,CDN邊緣節(jié)點也存在著一套緩存機制。CDN邊緣節(jié)點緩存策略

因服務(wù)商不同而不同，但一般都會遵循h(huán)ttp標(biāo)準(zhǔn)協(xié)議，通過http響應(yīng)頭中的

Cache-control://后面會提到

的字段來設(shè)置CDN邊緣節(jié)點數(shù)據(jù)緩存時間。

當(dāng)瀏覽器向CDN節(jié)點請求數(shù)據(jù)時，CDN節(jié)點會判斷緩存數(shù)據(jù)是否過期，若緩存

數(shù)據(jù)并沒有過期，則直接將緩存數(shù)據(jù)返回給客戶端；否則，CDN節(jié)點就會向服

務(wù)器發(fā)出回源請求，從服務(wù)器拉取最新數(shù)據(jù)，更新本地緩存，并將最新數(shù)據(jù)返回

給客戶端。CDN服務(wù)商一般會提供基于文件后綴、目錄多個維度來指定CDN

緩存時間，為用戶提供更精細化的緩存管理。

CDN優(yōu)勢

1.CDN節(jié)點解決了跨運營商和跨地域訪問的問題，訪問延時大大降低。

2.大部分請求在CDN邊緣節(jié)點完成，CDN起到了分流作用，減輕了

源服務(wù)器的負載。

戳此處詳細了解CDN工作過程

3.

瀏覽器緩存（http緩存）

對著這張圖先發(fā)呆30秒~

什么是瀏覽器緩存

資源緩存到本地將來使用

簡單來說，瀏覽器緩存其實就是瀏覽器保存通過HTTP獲取的所有資源，是瀏覽器

將網(wǎng)絡(luò)資源存儲在本地的一種行為。

緩存的資源去哪里了？

你可能會有疑問，瀏覽器存儲了資源，那它把資源存儲在哪里呢？

memorycache

MemoryCache顧名思義，就是將資源緩存到內(nèi)存中，等待下次訪

問時不需要重新下載資源，而直接從內(nèi)存中獲取。Webkit早已支

持memoryCacheo

目前Webkit資源分成兩類，一類是主資源，比如HTML頁面，或

者下載項，一類是派生資源，比如HTML頁面中內(nèi)嵌的圖片或者

腳本鏈接，分別對應(yīng)代碼中兩個類：MainResourceLoader和

雖然支持但是也只

SubresourceLoaderoWebkitmemoryCache,

是針對派生資源，它對應(yīng)的類為CachedResource,用于保存原始

數(shù)據(jù)（比如CSS,JS等），以及解碼過的圖片數(shù)據(jù)。

diskcache

DiskCache顧名思義，就是將資源緩存到磁盤中，等待下次訪問時

不需要重新下載資源，而直接從磁盤中獲取，它的直接操作對象為

CurlCacheManagero

?jmemorycache|diskcache

相同點只能存儲一些派生類資源文件只能存儲一些派生類資源文件

不同點退出進程時數(shù)據(jù)會被清除退出進程時數(shù)據(jù)不會被清除

存儲資源一般腳本、字體、圖片會存在內(nèi)存當(dāng)中一般非腳本會存在內(nèi)存當(dāng)中，如CS

因為CSS文件加載一次就可渲染出來，我們不會頻繁讀取它，所以它不適合緩存

到內(nèi)存中，但是js之類的腳本卻隨時可能會執(zhí)行,如果腳本在磁盤當(dāng)中，我們在執(zhí)

行腳本的時候需要從磁盤取到內(nèi)存中來，這樣IO開銷就很大了，有可能導(dǎo)致瀏覽

器失去響應(yīng)。

三級緩存原理（訪問緩存優(yōu)先級）

1.先在內(nèi)存中查找,如果有，直接加載。

2.如果內(nèi)存中不存在，則在硬盤中查找，如果有直接加載。

3.如果硬盤中也沒有，那么就進行網(wǎng)絡(luò)請求。

4.請求獲取的資源緩存到硬盤和內(nèi)存。

瀏覽器緩存的分類

1.強緩存

2.協(xié)商緩存

瀏覽器再向服務(wù)器請求資源時，首先判斷是否命中強緩存，再判斷是否命中協(xié)商緩

存！

瀏覽器緩存的優(yōu)點

1.減少了冗余的數(shù)據(jù)傳輸

2.減少了服務(wù)器的負擔(dān)，大大提升了網(wǎng)站的性能

3.加快了客戶端加載網(wǎng)頁的速度

強緩存

瀏覽器在加載資源時，會先根據(jù)本地緩存資源的header中的信息判斷是否命

中強緩存，如果命中則直接使用緩存中的資源不會再向服務(wù)器發(fā)送請求。

這里的header中的信息指的是expires和cahe-control.

Expires

該字段是httpl.O時的規(guī)范，它的值為一個絕對時間的GMT格式的時間字符

串，比如Expires:Mon,18Oct206623:59:59GMT?這個時間代表著這個資源的

失效時間，在此時間之前，即命中緩存。這種方式有一個明顯的缺點，由于失效

時間是一個絕對時間，所以當(dāng)服務(wù)器與客戶端時間偏差較大時，就會導(dǎo)致緩存混

亂。

Cache-Control

Cache-Control是httpl.l時出現(xiàn)的header信息，主要是利用該字段

的max-age值來進行判斷，它是一個相對時間，例如

Cache-Control:max-age=3600,代表著資源的有效期是3600秒。cache-control

除了該字段外，還有下面幾個比較常用的設(shè)置值：

no-cache：需要進行協(xié)商緩存，發(fā)送請求到服務(wù)器確認是否使用緩存。

no-store：禁止使用緩存，每一次都要重新請求數(shù)據(jù)。

public：可以被所有的用戶緩存，包括終端用戶和CDN等中間代理服務(wù)器。

private：只能被終端用戶的瀏覽器緩存，不允許CDN等中繼緩存服務(wù)器對其

緩存。

Cache-Control與Expires可以在服務(wù)端配置同時啟用，同時啟用的時候

Cache-Control優(yōu)先級高。

協(xié)商緩存

當(dāng)強緩存沒有命中的時候，瀏覽器會發(fā)送一個請求到服務(wù)器，服務(wù)器根據(jù)header

中的部分信息來判斷是否命中緩存。如果命中，則返回304,告訴瀏覽器資源

未更新，可使用本地的緩存。

這里的header中的信息指的是Last-Modify/If-Modify-Since和

ETag/If-None-Match.

Last-Modify/If-Modify-Since

瀏覽器第一次請求一個資源的時候，服務(wù)器返回的header中會加上

Last-Modify,Last-modify是一個時間標(biāo)識該資源的最后修改時間。

當(dāng)瀏覽器再次請求該資源時，request的請求頭中會包含If-Modify-Since,該

值為緩存之前返回的Last-Modify。服務(wù)器收到If-Modify-Since后，根據(jù)資源

的最后修改時間判斷是否命中緩存。

如果命中緩存，則返回304,并且不會返回資源內(nèi)容，并且不會返回Last-Modify。

缺點：

短時間內(nèi)資源發(fā)生了改變，Last-Modified并不會發(fā)生變化。

周期性變化。如果這個資源在一個周期內(nèi)修改回原來的樣子了，我們認為是可以

使用緩存的，但是Last-Mod市ed可不這樣認為，因此便有了ETag。

ETag/If-None-Match

與Last-Modify/If-Modify-Since不同的是，Etag/If-None-Match返回的是一個

校驗碼。ETag可以保證每一個資源是唯一的，資源變化都會導(dǎo)致ETag變化。

服務(wù)器根據(jù)瀏覽器上送的If-None-Match值來判斷是否命中緩存。

與Last-Modified不一樣的是，當(dāng)服務(wù)器返回304NotModified的響應(yīng)時，由

于ETag重新生成過，responseheader中還會把這個ETag返回，即使這個

ETag跟之前的沒有變化。

Last-Modified與ETag是可以一起使用的，服務(wù)器會優(yōu)先驗證ETag,一致

的情況下，才會繼續(xù)比對Last-Modified,最后才決定是否返回304。

總結(jié)

當(dāng)瀏覽器再次訪問一個已經(jīng)訪問過的資源時，它會這樣做:

1.看看是否命中強緩存，如果命中，就直接使用緩存了。

2.如果沒有命中強緩存，就發(fā)請求到服務(wù)器檢查是否命中協(xié)商緩存。

3.如果命中協(xié)商緩存，服務(wù)器會返回304告訴瀏覽器使用本地緩存。

4.否則，返回最新的資源。

實踐加深理解

talkischeap,showmethecode□讓我們通過實踐得真知~

在實踐時，注意瀏覽器控制臺Network的65abiecache按鈕不要打鉤。

以下我們只對強緩存的Cache-Control和協(xié)商緩存的ETag進行實踐，其他小伙伴

們可以自己實踐~

package.json

(

"MMC"："webcacke.'^

"version":U^.O.OU,

"description11:

"i八dexjs",

"scripts"：{

"cache"："八。WCHA。八./i八dexjs”

}，

"a(A±hoF:"webfaxplz",

"lice八se〃：“MIT',

“devDepc八de八cies”;{

u^babel/coren:〃人7.2.2",

babel/preset-eiav":"人7.2.3",

“@babcl/regist0F:"八7QQ")

〃kon":〃八262”,

〃koa-static":"八5QQ"

I

“depc八四八cies":{

〃八。血儂。八"："人1.28，"

)

)

.babelrc

(

"presets"：[

[

姐/preset-。八匕

(

"target^1:{

"八。de〃："c〃rrcnt"

)

)

]

]

)

index.js

webcache.js

importKoafrom'koa^iimportpath.FHOKA土欠;//靜態(tài)資源中間件importresourcefrom

(koa-static1;coi^stapp=MWKoa();coiasthost-'localhost'ico^stport=4396;

app,tA$c(r^ource(pathJoik\(_diriaa^\eJ'./static'}));

app.【isten(poH,()=>{

c。八so/cJogCscrvcKislisteni八${人。5玨:${/?0啕');

1)；

index.html

<!DOCTYPEMtm/xMtmllai^g="e^.">

<laead>

<w\etacharset="UTF-S"/>

<met?八〃="viewport"coiate^t=u\A/idth=device-widtla,initial-^cale=^.On/>

<i^etakttp-equiv=nX-UA-Compatible"co^te^t^i^edge'1/>

<title〉前端緩存</ti廿e〉

.web-cache,iw^g{

display:block)

width:16>C>%;

)

</style>

</head>

<body>

<divclass^'web-cack^'xii^gsrc="./web.png"/></div>

</bodyx/h.t^v\l>

我們用koa先起個web服務(wù)器，然后用koa-static這個中間件做靜態(tài)資源配置,

并在static文件夾下放了index.html和web.png。

Ok,接下來我們來啟動服務(wù)。

ApmruKicache

serverislisteninlocalhost:43960

接下來我們打開瀏覽器輸入地址：

/ocafMo$t:43^6

<-->C①localhost:4396

完美~(哈哈，豬仔別噴我，純屬娛樂效果)

Ok!!!接下來我們來實踐下強緩存。~

Cache-Control

webcache.js

importKoafroinn.'koa1;importpathfroMpath，;//靜態(tài)資源中間件importresourcefrom

'koa-static';co^.stapp=newK.oa();co^sthost='localhost';com.stport=4376;

app.us&(async(ctx,next)=>{

//設(shè)置響應(yīng)頭Cache-C。八tr。/設(shè)置資源有效期為30。秒

ctxset([

'Cache-Control1:'^ax-agc-3OO'

1)；

awaitMXt();

})；

1

app.use(resource(pathjoin(__dinaai^eJ^/static)));

app.listeNpoH，0=>{

co八so/e」og(、seKVcrislistenM${host}:${port}');

!)；

G，C①*0C?lhQU439

CwM-t?n*Bk

LMet/i

tet.19J?*MJUXMCKT

3?3?■tot.1?JMM299.9H59CRT

我們刷新頁面可以看到響應(yīng)頭的Cache-Control變成了max-age=300o

我們順便來驗證下三級緩存原理

我們剛進行了網(wǎng)絡(luò)請求，瀏覽器把web.png存進了磁盤和內(nèi)存中。

根據(jù)三級緩存原理，我們會先在內(nèi)存中找資源，我們來刷新頁面。

我們在紅線部分看到了，frommemorycache。nice-

ok,接下來，我們關(guān)掉該頁面，再重新打開。因為內(nèi)存是存在進程中的，所以關(guān)閉該

頁面,內(nèi)存中的資源也被釋放掉了，磁盤中的資源是永久性的，所以還存在。

根據(jù)三級緩存原理，如果在內(nèi)存中沒找到資源，便會去磁盤中尋找!

fromdiskcache!!!ok,以上也就驗證了三級緩存原理，相信你對緩存資源的存儲

也有了更深的理解了。

我們剛對資源設(shè)置的有效期是300秒,我們接下來來驗證緩存是否失效。

300秒后。oo

fSflBtomanttCORMNflQtfOM"tacnFwtMmano*Mvnor

?0?丁QMmrSS、。Wma^narwteg

R?gQMg*A*KHAJSCS5QWMteF

Mas40me

Z^uMtgLnttf://Uc?UiOt<

ftoqunlMMMACO

SU*MC4dK?2MOK

non(nii：4m

ftaiaffwRatey:

(MfMflMMMdarvaouew

CM—ComratMl

Cwvwcimke?9-alive

ComaM-Lanv*；

C4tawtiyp?LMOC/I

DataUt.19Jan2919W:?iS9CRT

U??/■—63.l?*<

我們通過返回值可以看到,緩存失效了。

通過以上實踐，你是否對強緩存有了更深入的理解了呢?

Ok!!!接下來我們來實踐下協(xié)商緩存。~

由于Cache-Control的默認值就是no-cache（需要進行協(xié)商緩存，發(fā)送請求到服

務(wù)器確認是否使用緩存。），所以我們這里不用對Cache-Control進行設(shè)置！

//ETagsupportforKoaresponses“singetag.

upminstallkoa-tag-P//etagworkstogetherwithconditional-get

呻出installkoa-conditional-get-P

我們這里直接使用現(xiàn)成的插件幫我們計算文件的ETag值,站在巨人的肩膀上!

webcache.js

importKoaWOM'koa'jiw^portpathfrompath';//沖態(tài)資源中間件importresourcefrom

'koa-static';ii^portconditionalfrom'koa-conditional-getetagfrom

^oa-etag^constapp=MWK。?);。。八sthost=YocHkos偽c。八stport=43^76;

//etagworkstogetherwithconditional-get

app.usc(coi^ditioK\al());

app.iAse(etag(y);

app.use(resource(path.joi^.(_dir^.a^e,

app.list6^port,0=>{

co^sole.logQserverislisteninf{kosf}：${^ortF);

!)；

oko第一次請求.

<-C(D*OC4lhOM4JM

None■*towe?CMMMTawt^

包—k?JM

Aa^MMiURL:Rtt>i//UcalhO?t：41M/Me*.t**?

1，?■?CCT

S?MMr?CK

IMemrFcAcyM-r?f<rr*rrM?

.AM0MMMMeantvMrWifW

CMIWc—3-y

Cowmcaonh?c?>alkv?

CemwitsRtVk22M9

C4HtaM-9kP*

W.1?J?fiMH”；WCRT

■n*wr744-nmw??

AccacKMMfcAM**.ate/???.g**t7?.〃?;q?

y?0U??na；?ii9.”

Accw?<?RVMaiB

CW*-C**v<f?-<Mh?

dig“f;r*tat??lrw:叫，“IIMQU

CNU&ATAU??*U72)?

HeatlaolMvtlOM

Fraanan?*c?CM

AatMr

Uw^ZantM?JiLU^S.t(|>hone;g6tHI

te?arMW.l

我們發(fā)現(xiàn)返回值里面已經(jīng)有了Etag值。

接下來再請求的時候，瀏覽器將會帶上If-None-Match請求頭，并賦值為上一次返

回頭的Etag值,然后與這次返回值的Etag值進行對比。如果一致則命中協(xié)商緩

存。返回304NotModified。接下來我們來驗證一下~

C?lOCMWMOW

Am*t)?>*(/■???.M??f/????.?M?e,..".：U

“"S._U19,.，5?,H

Etagsslf>None-MatchI*J-??EJCG.，

Ge*M*m.M?^-aU?v

QMM??WK?<SiEM?irw；<R_f

OU3?*nu7WM八X"OIMM?4

NMtteC4l*mt>4>K

?Ut.19J3MHt?>n：4>B

WI”?■■■zawiMKLMn*)l*t<lRMKiM.H.1I.

ok,如圖所示，完美驗證了上面的說法。

接下來我們修改web.png，來驗證是否資源改變時協(xié)商緩存策略也就失效呢？

GfC①togott<3M

Cwvwcemk?t*-aUvf

CMtom-UHVVkS92K

CeatoM-1>p*UBeyt/E

IMKMt.19X，?2CHT

mw”4—

nM；lli2BCRT

資源改變,mg值也隨■改變.

?H09MMIaMaouee