通過(guò) Node.js 小示例學(xué)習(xí)瀏覽器緩存策略
今日文章由 “Nodejs技術(shù)棧@五月君” 授權(quán)分享，正文從下面開始～
在后端為了加速服務(wù)的訪問(wèn)速度，通常可以使用 Memcached、Redis 做數(shù)據(jù)緩存，那么在瀏覽器端又有哪些緩存策略呢？
一、瀏覽器緩存幾個(gè)階段
1. 強(qiáng)緩存策略
瀏覽器端發(fā)起請(qǐng)求之后不會(huì)直接向服務(wù)器請(qǐng)求數(shù)據(jù)，直接先到達(dá)強(qiáng)緩存階段，如果強(qiáng)緩存命中直接返回，如果沒(méi)有命中進(jìn)入下一階段協(xié)商緩存策略。
2. 協(xié)商緩存策略
協(xié)商緩存是當(dāng)強(qiáng)緩存沒(méi)有命中的情況或者按下 F5 鍵刷新頁(yè)面會(huì)觸發(fā)，它每次都會(huì)攜帶標(biāo)識(shí)與服務(wù)器進(jìn)行校驗(yàn)，符合則返回 304 標(biāo)識(shí)，表示資源沒(méi)有更新，如果協(xié)商緩存也失效了，進(jìn)入下一個(gè)階段獲取最新數(shù)據(jù)，并返回且狀態(tài)碼為 200。
3. 存儲(chǔ)策略
當(dāng)強(qiáng)緩存->協(xié)商緩存都未命中，請(qǐng)求會(huì)直接到達(dá)服務(wù)器，獲取最新資源設(shè)置緩存策略，進(jìn)行返回。
二、強(qiáng)緩存
強(qiáng)緩存的實(shí)現(xiàn)分為 Expires、Cache-Control 兩個(gè)。
Expires
Expires 屬于 HTTP 1.0 時(shí)期的產(chǎn)物，在響應(yīng)中進(jìn)行設(shè)置，示例如下：
response.writeHead(200,?{
????'Content-Type':?'text/javascript',
????'Expires':?new?Date('2020-03-25?11:19:00'),
});
設(shè)置成功運(yùn)行 node expires.js 在 Response Headers 里可以看到如下信息：
Expires:?Wed?Mar?25?2020?11:19:00?GMT+0800?(GMT+08:00)
刷新兩次頁(yè)面，可以看到第二次 size 一欄返回了?memory cache?此時(shí) Expires 緩存命中。
Expires 是參考的本地時(shí)間，如果修改本地時(shí)間，可能就會(huì)造成緩存失效。
Cache-Control
Cache-Control 屬于 HTTP 1.1 時(shí)代的產(chǎn)物，可以再請(qǐng)求頭或者響應(yīng)頭中設(shè)置，它的取值包含如下選項(xiàng)：
可緩存性
public：http 經(jīng)過(guò)的任何地方都可以進(jìn)行緩存（代理服務(wù)器也可緩存） private：只有發(fā)起請(qǐng)求的這個(gè)瀏覽器才可以進(jìn)行緩存，如果設(shè)置了代理緩存，那么代理緩存是不會(huì)生效的 no-cache：任何一個(gè)節(jié)點(diǎn)都不可以緩存（繞過(guò)強(qiáng)緩存，但是還會(huì)經(jīng)過(guò)協(xié)商緩存） 到期
max-age= ：設(shè)置緩存到多少秒過(guò)期 s-maxage= ：會(huì)代替 max-age，只有在代理服務(wù)器（nginx 代理服務(wù)器）才會(huì)生效 max-stale= ：是發(fā)起請(qǐng)求方主動(dòng)帶起的一個(gè)頭，是代表即便緩存過(guò)期，但是在 max-stale 這個(gè)時(shí)間內(nèi)還可以使用過(guò)期的緩存，而不需要向服務(wù)器請(qǐng)求新的內(nèi)容 重新驗(yàn)證
must-revalidate：如果 max-age 設(shè)置的內(nèi)容過(guò)期，必須要向服務(wù)器請(qǐng)求重新獲取數(shù)據(jù)驗(yàn)證內(nèi)容是否過(guò)期 proxy-revalidate：主要用在緩存服務(wù)器，指定緩存服務(wù)器在過(guò)期后重新從原服務(wù)器獲取，不能從本地獲取 其它
no-store：本地和代理服務(wù)器都不可以存儲(chǔ)這個(gè)緩存，永遠(yuǎn)都要從服務(wù)器拿 body 新的內(nèi)容使用（強(qiáng)緩存、協(xié)商緩存都不會(huì)經(jīng)過(guò)） no-transform：主要用于 proxy 服務(wù)器，告訴代理服務(wù)器不要隨意改動(dòng)返回的內(nèi)容
Cache-Control 示例
先思考兩個(gè)問(wèn)題?
在頁(yè)面中引入靜態(tài)資源文件，為什么靜態(tài)資源文件改變后，再次發(fā)起請(qǐng)求還是之前的內(nèi)容，沒(méi)有變化呢？ 在使用webpack等一些打包工具時(shí)，為什么要加上一串hash碼？
cache-control.html
<html>
????<head>
????????<meta?charset="utf-8"?/>
????????<title>cache-controltitle>
????head>
????<body>
????????<script?src="/script.js">script>
????body>
html>
cache-control.js
瀏覽器輸入 http://localhost:3010/ 加載 cache-control.html 文件，該文件會(huì)請(qǐng)求 http://localhost:3010/script.js 如果 url 等于 /script.js 設(shè)置 cache-control 的 max-age 進(jìn)行瀏覽器緩存。
const?http?=?require('http');
const?fs?=?require('fs');
const?port?=?3010;
http.createServer((request,?response)?=>?{
????console.log('request?url:?',?request.url);
????if?(request.url?===?'/')?{
????????const?html?=?fs.readFileSync('./example/cache/cache-control.html',?'utf-8');
????
????????response.writeHead(200,?{
????????????'Content-Type':?'text/html',
????????});
????????response.end(html);
????}?else?if?(request.url?===?'/script.js')?{
????????response.writeHead(200,?{
????????????'Content-Type':?'text/javascript',
????????????'Cache-Control':?'max-age=200'
????????});
????????response.end("console.log('script?load')");
????}
}).listen(port);
console.log('server?listening?on?port?',?port);
第一次運(yùn)行
瀏覽器運(yùn)行結(jié)果,沒(méi)有什么問(wèn)題，正常響應(yīng)
控制臺(tái)運(yùn)行結(jié)果
修改 cache-control.js 返回值
...
response.writeHead(200,?{
????'Content-Type':?'text/javascript',
????'Cache-Control':?'max-age=200'
});
response.end("console.log('script load ?。?！')");
...
中斷上次程序，第二次運(yùn)行
瀏覽器運(yùn)行結(jié)果
第二次運(yùn)行，從 memory cahce 讀取，瀏覽器控制臺(tái)并沒(méi)有打印修改過(guò)的內(nèi)容
控制臺(tái)運(yùn)營(yíng)結(jié)果
只請(qǐng)求了?/?并沒(méi)有請(qǐng)求?/script.js
源碼參考：github.com/Q-Angelo/http-protocol/blob/master/example/cache/cache-control.js
以上結(jié)果瀏覽器并沒(méi)有返回給我們服務(wù)端修改的結(jié)果，這是為什么呢？
先回答第一個(gè)問(wèn)題
在頁(yè)面中引入靜態(tài)資源文件，為什么靜態(tài)資源文件改變后，再次發(fā)起請(qǐng)求還是之前的內(nèi)容，沒(méi)有變化呢？
是因?yàn)槲覀冋?qǐng)求的 url?/script.js?沒(méi)有變，那么瀏覽器就不會(huì)經(jīng)過(guò)服務(wù)端的驗(yàn)證，會(huì)直接從客戶端緩存去讀，就會(huì)導(dǎo)致一個(gè)問(wèn)題，我們的js靜態(tài)資源更新之后，不會(huì)立即更新到我們的客戶端，這也是前端開發(fā)中常見(jiàn)的一個(gè)問(wèn)題，我們是希望瀏覽器去緩存我們的靜態(tài)資源文件（js、css、img等）我們也不希望服務(wù)端內(nèi)容更新了之后客戶端還是請(qǐng)求的緩存的資源，
回答第二個(gè)問(wèn)題
在使用webpack等一些打包工具時(shí)，為什么要加上一串hash碼？
解決辦法也就是我們?cè)谧?js 構(gòu)建流程時(shí)，把打包完成的 js 文件名上根據(jù)它內(nèi)容 hash 值加上一串 hash 碼，這樣你的 js 文件或者 css 文件等內(nèi)容不變，這樣生成的 hash 碼就不會(huì)變，反映到頁(yè)面上就是你的 url 沒(méi)有變，如果你的文件內(nèi)容有變化那么嵌入到頁(yè)面的文件 url 就會(huì)發(fā)生變化，這樣就可以達(dá)到一個(gè)更新緩存的目的，這也是目前前端來(lái)說(shuō)比較常見(jiàn)的一個(gè)靜態(tài)資源方案。
Expires 與 Cache-Control 對(duì)比
HTTP 協(xié)議對(duì)比：Expires 屬于 HTTP 1.0 時(shí)代的產(chǎn)物，Cache-Control 屬于 HTTP 1.1 時(shí)代的產(chǎn)物 優(yōu)先級(jí)對(duì)比：如果同時(shí)使用 Cache-Control 的 max-age 與 Expires，則 max-age 優(yōu)先級(jí)會(huì)更高，會(huì)忽略掉 Expires 緩存單位：Expires 與 Cache-Control 兩者的緩存單位都是以時(shí)間為維度，如果我要根據(jù)文件的內(nèi)容變化來(lái)判斷緩存是否失效怎么辦呢？就需要用到下面的協(xié)商緩存了。
三、協(xié)商緩存
如果強(qiáng)緩存未命中或用戶按下 F5 強(qiáng)制刷新后進(jìn)入?yún)f(xié)商緩存，服務(wù)器則根據(jù)瀏覽器請(qǐng)求時(shí)的標(biāo)識(shí)進(jìn)行判斷，如果協(xié)商緩存生效返回 304 否則返回 200。協(xié)商緩存的實(shí)現(xiàn)也是基于兩點(diǎn) Last-Modified、ETag 這個(gè)需要在 HTTP Headers 中設(shè)置。
Last-Modified/If-Modified-Since
Last-Modified 是在服務(wù)端設(shè)置進(jìn)行響應(yīng)，If-Modified-Since 是在瀏覽器端根據(jù)服務(wù)端上次在 Response Headers 中設(shè)置的 Last-Modified 取其值，如果存在請(qǐng)求時(shí)設(shè)置其 Request Headers 值 If-Modified-Since 傳到服務(wù)器，服務(wù)器也是拿到這個(gè)值進(jìn)行比對(duì)，下面為核心實(shí)現(xiàn)。
if?(request.url?===?'/script.js')?{
????const?filePath?=?path.join(__dirname,?request.url);?//?拼接當(dāng)前腳本文件地址
????const?stat?=?fs.statSync(filePath);?//?獲取當(dāng)前腳本狀態(tài)
????const?mtime?=?stat.mtime.toGMTString()?//?文件的最后修改時(shí)間
????const?requestMtime?=?request.headers['if-modified-since'];?//?來(lái)自瀏覽器傳遞的值
????console.log(stat);
????console.log(mtime,?requestMtime);
????//?走協(xié)商緩存
????if?(mtime?===?requestMtime)?{
????????response.statusCode?=?304;
????????response.end();
????????return;
????}
????//?協(xié)商緩存失效，重新讀取數(shù)據(jù)設(shè)置?Last-Modified?響應(yīng)頭
????console.log('協(xié)商緩存?Last-Modified?失效');
????response.writeHead(200,?{
????????'Content-Type':?'text/javascript',
????????'Last-Modified':?mtime,
????});
????const?readStream?=?fs.createReadStream(filePath);
????readStream.pipe(response);
}
執(zhí)行 node last-modified.js 啟動(dòng)程序，瀏覽器執(zhí)行 http://localhost:3010/ 打開頁(yè)面，我多次調(diào)用發(fā)現(xiàn)第一次是從服務(wù)器拿的數(shù)據(jù)且狀態(tài)為 200，之后每次都是 memory cache 為什么不是 304 呢？
源碼地址 github.com/Q-Angelo/http-protocol/tree/master/example/cache/last-modified
顯然是強(qiáng)緩存生效了，你可能會(huì)想我沒(méi)有設(shè)置強(qiáng)緩存哦?
這是因?yàn)闉g覽器默認(rèn)啟用了一個(gè)啟發(fā)式緩存，這在設(shè)置了 Last-Modified 響應(yīng)頭且沒(méi)有設(shè)置 Cache-Control: max-age/s-maxage 或 Expires 時(shí)會(huì)觸發(fā)，它的一個(gè)緩存時(shí)間是用 Date - Last-Modified 的值的 10% 作為緩存時(shí)間。
現(xiàn)在我們要達(dá)到 304 的效果，不走強(qiáng)緩存直接走協(xié)商緩存，修改我們的響應(yīng)，設(shè)置 Cache-Control=max-age=0 修改如下：
response.writeHead(200,?{
????'Content-Type':?'text/javascript',
????'Last-Modified':?mtime,
????'Cache-Control':?'max-age=0',?//?修改地方
});
再次運(yùn)行我們的程序，控制臺(tái)執(zhí)行 node last-modified-max-age.js 再次重新打開頁(yè)面查看效果，第二次直接走的協(xié)商緩存且 Request Headers 攜帶了 If-Modified-Since: Wed, 25 Mar 2020 12:31:58 GMT
源碼地址 https://github.com/Q-Angelo/http-protocol/tree/master/example/cache/last-modified-max-age
ETag 和 If-None-Match
Last-Modified 是以文件的修改時(shí)間來(lái)判斷，Etag 是根據(jù)文件的內(nèi)容是否修改來(lái)判斷，如果 Etag 有修改重新獲取新的資源返回，如果未修改返回 304 通知客戶端使用本地緩存。
Etag 的判斷主要也是在服務(wù)端通過(guò)一種 Hash 算法實(shí)現(xiàn)，核心實(shí)現(xiàn)如下：
if?(request.url?===?'/script.js')?{
????const?filePath?=?path.join(__dirname,?request.url);?//?拼接當(dāng)前腳本文件地址
????const?buffer?=?fs.readFileSync(filePath);?//?獲取當(dāng)前腳本狀態(tài)
????const?fileMd5?=?md5(buffer);?//?文件的?md5?值
????const?noneMatch?=?request.headers['if-none-match'];?//?來(lái)自瀏覽器端傳遞的值
????if?(noneMatch?===?fileMd5)?{
????????response.statusCode?=?304;
????????response.end();
????????return;
????}
????console.log('Etag?緩存失效');
????response.writeHead(200,?{
????????'Content-Type':?'text/javascript',
????????'Cache-Control':?'max-age=0',
????????'ETag':?fileMd5,
????});
????const?readStream?=?fs.createReadStream(filePath);
????readStream.pipe(response);
}
源碼地址 github.com/Q-Angelo/http-protocol/tree/master/example/cache/etag
node etag.js 運(yùn)行我們程序，打開我們的頁(yè)面多次訪問(wèn)，第二次會(huì)看到瀏覽器會(huì)攜帶一個(gè) If-None-Match 的 Header 頭傳遞到服務(wù)端進(jìn)行校驗(yàn)，當(dāng)前協(xié)商緩存命中了所以響應(yīng)狀態(tài)為 304
Last-Modified 與 Etag 對(duì)比
精確度：Last-Modified 以時(shí)間（秒）為單位，如果出現(xiàn) 1 秒內(nèi)文件多次修改，在 Last-Modified 緩存策略下也不會(huì)失效，Etag 是對(duì)內(nèi)容進(jìn)行 Hash 比較，只要內(nèi)容變動(dòng) Etag 就會(huì)發(fā)生變化，精確度更高。 分布式部署問(wèn)題：分布式部署必然涉及到負(fù)載均衡，造成的一種現(xiàn)象是 Last-Modified 的時(shí)間可能還不太一致，而 Etag 只要保證每臺(tái)機(jī)器的 Hash 算法是一致的就可保證一致性。 性能消耗：Etag 需要讀取文件做 Hash 計(jì)算，相比 Last-Modified 性能上是有損耗的。 優(yōu)先級(jí)：如果 Last-Modified/Etag 同時(shí)設(shè)置，Etag 的優(yōu)先級(jí)會(huì)更高些。 相同點(diǎn)：校驗(yàn)通過(guò)返回 304 通知客戶端使用本地緩存，校驗(yàn)不通過(guò)重新獲取最新資源，設(shè)置 Last-Modified/Etag 響應(yīng)頭，返回狀態(tài)碼 200 。
疑問(wèn)？
POST 可以緩存嗎？
GET 是一個(gè)冪等操作，通常用于緩存，POST 是一個(gè)非冪等的操作，每次創(chuàng)建新的資源，也不會(huì)自動(dòng)處理 POST 請(qǐng)求進(jìn)行緩存，參考?rfc2616-sec9.html#sec9.1
Reference
http://verymuch.site/2018/10/09/web-browser-cache-strategy/
文章來(lái)源：Node.js技術(shù)棧，作者@五月君，原文中示例可通過(guò) “閱讀原文” 在 Github 查看
??愛(ài)心三連擊
1.看到這里了就點(diǎn)個(gè)在看支持下吧，你的「點(diǎn)贊，在看」是我創(chuàng)作的動(dòng)力。
2.關(guān)注公眾號(hào)
程序員成長(zhǎng)指北，回復(fù)「1」加入Node進(jìn)階交流群！「在這里有好多 Node 開發(fā)者，會(huì)討論 Node 知識(shí)，互相學(xué)習(xí)」！3.也可添加微信【ikoala520】，一起成長(zhǎng)。
“在看轉(zhuǎn)發(fā)”是最大的支持