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

刖百

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

實踐系列-前端路由

實踐系列-Babel原理

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

有興趣的同學可以關注實踐系列。求star求follow-

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

目錄

DNS緩存//雖說跟標題關系不大，了解一下也不錯

2.CDN緩存//雖說跟標題關系不大，了解一下也不錯

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

DNS緩存

什么是DNS

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

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

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

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

DNS解析

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

名解析）。

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

DNS緩存

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

都會對DNS結果做一定程度的緩存。

DNS查詢過程如下：

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

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

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

成。

3.如果本地hosts文件不存在映射關系，則查找本地DNS服務器（ISP服務

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

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

歸查詢。

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

CDN緩存

什么是CDN

全稱ContentDeliveryNetwork,即內容分發(fā)網絡。

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

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

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

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

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

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

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

苦逼的排隊買票了。

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

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

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

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

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

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

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

CDN緩存

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

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

因服務商不同而不同，但一般都會遵循h(huán)ttp標準協(xié)議，通過http響應頭中的

Cache-control://后面會提到

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

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

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

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

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

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

CDN優(yōu)勢

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

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

源服務器的負載。

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

3.

瀏覽器緩存（http緩存）

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

什么是瀏覽器緩存

資源緩存到本地將來使用

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

將網絡資源存儲在本地的一種行為。

緩存的資源去哪里了？

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

memorycache

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

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

持memoryCacheo

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

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

腳本鏈接，分別對應代碼中兩個類：MainResourceLoader和

雖然支持但是也只

SubresourceLoaderoWebkitmemoryCache,

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

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

diskcache

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

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

CurlCacheManagero

?jmemorycache|diskcache

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

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

存儲資源一般腳本、字體、圖片會存在內存當中一般非腳本會存在內存當中，如CS

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

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

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

器失去響應。

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

1.先在內存中查找,如果有，直接加載。

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

3.如果硬盤中也沒有，那么就進行網絡請求。

4.請求獲取的資源緩存到硬盤和內存。

瀏覽器緩存的分類

1.強緩存

2.協(xié)商緩存

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

存！

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

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

2.減少了服務器的負擔，大大提升了網站的性能

3.加快了客戶端加載網頁的速度

強緩存

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

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

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

Expires

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

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

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

時間是一個絕對時間，所以當服務器與客戶端時間偏差較大時，就會導致緩存混

亂。

Cache-Control

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

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

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

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

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

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

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

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

緩存。

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

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

協(xié)商緩存

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

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

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

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

ETag/If-None-Match.

Last-Modify/If-Modify-Since

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

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

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

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

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

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

缺點：

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

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

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

ETag/If-None-Match

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

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

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

與Last-Modified不一樣的是，當服務器返回304NotModified的響應時，由

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

ETag跟之前的沒有變化。

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

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

總結

當瀏覽器再次訪問一個已經訪問過的資源時，它會這樣做:

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

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

3.如果命中協(xié)商緩存，服務器會返回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服務器，然后用koa-static這個中間件做靜態(tài)資源配置,

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

Ok,接下來我們來啟動服務。

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)=>{

//設置響應頭Cache-C。八tr。/設置資源有效期為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

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

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

我們剛進行了網絡請求，瀏覽器把web.png存進了磁盤和內存中。

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

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

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

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

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

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

也有了更深的理解了。

我們剛對資源設置的有效期是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ā)送請求到服

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

//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)返回值里面已經有了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