前端要懂Http缓存机制

最近在看面试题的时候总会看到有一些关于Http缓存的题目，但是总是一知半解，不甚理解；尤其是Http头信息中有一大堆的字段，什么if-modified-since，什么if-none-match，真是令人头疼。后来突然想到，要是能通过自己构建一个服务器，自己添加头信息，然后看实现的效果，不就更好了么。说干就干，在网上各种找资料，然后再使用expressjs添加各种头信息，就能够很好的理解Http缓存了。 Http简介 浏览器和服务器之间通信是通过HTTP协议，HTTP协议永远都是客户端发起请求，服务器回送响应。模型如下： image HTTP报文就是浏览器和服务器间通信时发送及响应的数据块。浏览器向服务器请求数据，发送请求(request)报文；服务器向浏览器返回数据，返回响应(response)报文。报文信息主要分为两部分： 报文头部：一些附加信息（cookie，缓存信息等），与缓存相关的规则信息，均包含在头部中 数据主体部分：HTTP请求真正想要传输的数据内容 本文用到的一些报文头如下： image.png Http缓存的分类 Http缓存可以分为两大类，强制缓存（也称强缓存）和协商缓存。两类缓存规则不同，强制缓存在缓存数据未失效的情况下，不需要再和服务器发生交互；而协商缓存，顾名思义，需要进行比较判断是否可以使用缓存。 两类缓存规则可以同时存在，强制缓存优先级高于协商缓存，也就是说，当执行强制缓存的规则时，如果缓存生效，直接使用缓存，不再执行协商缓存规则。 原始模型 我们先简单搭建一个Express的服务器，不加任何缓存信息头。 const express = require('express'); const app = express(); const port = 8080; const fs = require('fs'); const path = require('path'); app.get('/',(req,res) => { res.send(` Http Cache Demo `) }) app.get('/demo.js',(req, res)=>{ let jsPath = path.resolve(__dirname,'./static/js/demo.js'); let cont = fs.readFileSync(jsPath); res.end(cont) }) app.listen(port,()=>{ console.log(`listen on ${port}`) }) 我们可以看到请求结果如下： image 请求过程如下： 浏览器请求静态资源demo.js 服务器读取磁盘文件demo.js，返给浏览器 浏览器再次请求，服务器又重新读取磁盘文件 a.js，返给浏览器。 循环请求。。 看得出来这种请求方式的流量与请求次数有关，同时，缺点也很明显： 浪费用户流量 浪费服务器资源，服务器要读磁盘文件，然后发送文件到浏览器 浏览器要等待js下载并且执行后才能渲染页面，影响用户体验 接下来我们开始在头信息中添加缓存信息。 一、强制缓存 强制缓存分为两种情况，Expires和Cache-Control。 Expires Expires的值是服务器告诉浏览器的缓存过期时间（值为GMT时间，即格林尼治时间），即下一次请求时，如果浏览器端的当前时间还没有到达过期时间，则直接使用缓存数据。下面通过我们的Express服务器来设置一下Expires响应头信息。 //其他代码... const moment = require('moment'); app.get('/demo.js',(req, res)=>{ let jsPath = path.resolve(__dirname,'./static/js/demo.js'); let cont = fs.readFileSync(jsPath); res.setHeader('Expires', getGLNZ()) //2分钟 res.end(cont) }) function getGLNZ(){ return moment().utc().add(2,'m').format('ddd, DD MMM YYYY HH:mm:ss')+' GMT'; } //其他代码... 我们在demo.js中添加了一个Expires响应头，不过由于是格林尼治时间，所以通过momentjs转换一下。第一次请求的时候还是会向服务器发起请求，同时会把过期时间和文件一起返回给我们；但是当我们刷新的时候，才是见证奇迹的时刻： image 可以看出文件是直接从缓存（memory cache）中读取的，并没有发起请求。我们在这边设置过期时间为两分钟，两分钟过后可以刷新一下页面看到浏览器再次发送请求了。 虽然这种方式添加了缓存控制，节省流量，但是还是有以下几个问题的： 由于浏览器时间和服务器时间不同步，如果浏览器设置了一个很后的时间，过期时间一直没有用 缓存过期后，不管文件有没有发生变化，服务器都会再次读取文件返回给浏览器 不过Expires 是HTTP 1.0的东西，现在默认浏览器均默认使用HTTP 1.1，所以它的作用基本忽略。 Cache-Control 针对浏览器和服务器时间不同步，加入了新的缓存方案；这次服务器不是直接告诉浏览器过期时间，而是告诉一个相对时间Cache-Control=10秒，意思是10秒内，直接使用浏览器缓存。 app.get('/demo.js',(req, res)=>{ let jsPath = path.resolve(__dirname,'./static/js/demo.js'); let cont = fs.readFileSync(jsPath); res.setHeader('Cache-Control', 'public,max-age=120') //2分钟 res.end(cont) }) image 二、协商缓存 强制缓存的弊端很明显，即每次都是根据时间来判断缓存是否过期；但是当到达过期时间后，如果文件没有改动，再次去获取文件就有点浪费服务器的资源了。协商缓存有两组报文结合使用： Last-Modified和If-Modified-Since ETag和If-None-Match image Last-Modified 为了节省服务器的资源，再次改进方案。浏览器和服务器协商，服务器每次返回文件的同时，告诉浏览器文件在服务器上最近的修改时间。请求过程如下： 浏览器请求静态资源demo.js 服务器读取磁盘文件demo.js，返给浏览器，同时带上文件上次修改时间 Last-Modified（GMT标准格式） 当浏览器上的缓存文件过期时，浏览器带上请求头If-Modified-Since（等于上一次请求的Last-Modified）请求服务器 服务器比较请求头里的If-Modified-Since和文件的上次修改时间。如果果一致就继续使用本地缓存（304），如果不一致就再次返回文件内容和Last-Modified。 循环请求。。 代码实现过程如下： app.get('/demo.js',(req, res)=>{ let jsPath = path.resolve(__dirname,'./static/js/demo.js') let cont = fs.readFileSync(jsPath); let status = fs.statSync(jsPath) let lastModified = status.mtime.toUTCString() if(lastModified === req.headers['if-modified-since']){ res.writeHead(304, 'Not Modified') res.end() } else { res.setHeader('Cache-Control', 'public,max-age=5') res.setHeader('Last-Modified', lastModified) res.writeHead(200, 'OK') res.end(cont) } }) 我们多次刷新页面，可以看到请求结果如下： image 虽然这个方案比前面三个方案有了进一步的优化，浏览器检测文件是否有修改，如果没有变化就不再发送文件；但是还是有以下缺点： 由于Last-Modified修改时间是GMT时间，只能精确到秒，如果文件在1秒内有多次改动，服务器并不知道文件有改动，浏览器拿不到最新的文件 如果服务器上文件被多次修改了但是内容却没有发生改变，服务器需要再次重新返回文件。 ETag 为了解决文件修改时间不精确带来的问题，服务器和浏览器再次协商，这次不返回时间，返回文件的唯一标识ETag。只有当文件内容改变时，ETag才改变。请求过程如下： 浏览器请求静态资源demo.js 服务器读取磁盘文件demo.js，返给浏览器，同时带上文件的唯一标识ETag 当浏览器上的缓存文件过期时，浏览器带上请求头If-None-Match（等于上一次请求的ETag）请求服务器 服务器比较请求头里的If-None-Match和文件的ETag。如果一致就继续使用本地缓存（304），如果不一致就再次返回文件内容和ETag。 循环请求。。 const md5 = require('md5'); app.get('/demo.js',(req, res)=>{ let jsPath = path.resolve(__dirname,'./static/js/demo.js'); let cont = fs.readFileSync(jsPath); let etag = md5(cont); if(req.headers['if-none-match'] === etag){ res.writeHead(304, 'Not Modified'); res.end(); } else { res.setHeader('ETag', etag); res.writeHead(200, 'OK'); res.end(cont); } }) 请求结果如下： image 一些额外的东西 在报文头的表格中我们可以看到有一个字段叫Pragma，这是一段尘封的历史.... image 在“遥远的”http1.0时代，给客户端设定缓存方式可通过两个字段--Pragma和Expires。虽然这两个字段早可抛弃，但为了做http协议的向下兼容，你还是可以看到很多网站依旧会带上这两个字段。 关于Pragma 当该字段值为no-cache的时候，会告诉浏览器不要对该资源缓存，即每次都得向服务器发一次请求才行。 res.setHeader('Pragma', 'no-cache') //禁止缓存 res.setHeader('Cache-Control', 'public,max-age=120') //2分钟 通过Pragma来禁止缓存，通过Cache-Control设置两分钟缓存，但是重新访问我们会发现浏览器会再次发起一次请求，说明了Pragma的优先级高于Cache-Control 关于Cache-Control 我们看到Cache-Control中有一个属性是public，那么这代表了什么意思呢？其实Cache-Control不光有max-age，它常见的取值private、public、no-cache、max-age，no-store，默认值为private，各个取值的含义如下： private: 客户端可以缓存 public: 客户端和代理服务器都可缓存 max-age=xxx: 缓存的内容将在 xxx 秒后失效 no-cache: 需要使用对比缓存来验证缓存数据 no-store: 所有内容都不会缓存，强制缓存，对比缓存都不会触发 所以我们在刷新页面的时候，如果只按F5只是单纯的发送请求，按Ctrl+F5会发现请求头上多了两个字段Pragma: no-cache和Cache-Control: no-cache。 缓存的优先级 上面我们说过强制缓存的优先级高于协商缓存，Pragma的优先级高于Cache-Control，那么其他缓存的优先级顺序怎么样呢？网上查阅了资料得出以下顺序（PS：有兴趣的童鞋可以验证一下正确性告诉我）： Pragma > Cache-Control > Expires > ETag > Last-Modified

本文章由javascript技术分享原创和收集