强缓存
HTTP/1.0 使用的是 Expires 字段，HTTP/1.1 使用的是 Cache-Control 字段。
-
Expires即过期时间，时间是相对于服务器的时间而言的，存在于服务端返回的响应头中，在这个过期时间之前可以直接从缓存里面获取数据，无需再次请求。但这种方式存在一个问题：无需再次请求服务器的时间和浏览器的时间可能并不一致。 - 在 HTTP 1.1 中，使用的是
Cache-Control字段，这个字段采用的时间是过期时长，对应的字段是max-age=*。
以下是使用 Node 模拟的简单示例：
const http = require('http')
const fs = require('fs')
const server = http.createServer((req, res) => {
const time = new Date()
time.setTime(time.getTime() + 100 * 1000) // 时间戳计算后 10s
const expires = time.toUTCString() // GMT（格林尼治标准时间）时间格式
res.setHeader('Expires', expires)
// 优先级高于 Expires
res.setHeader('Cache-Control', 'max-age=30')
const html = fs.readFileSync('./src/index.html', 'utf8')
res.end(html)
})
server.listen(3000)
当 Expires 和 Cache-Control 同时存在时，优先考虑 Cache-Control 字段。当缓存资源失效了，也就是没有命中强缓存，接下来就进入协商缓存。
协商缓存
如果缓存过期了，我们就可以使用协商缓存来解决问题。协商缓存需要请求，如果缓存有效会返回 304。协商缓存需要客户端和服务端共同实现，和强缓存⼀样，也有两种实现方式 Last-Modified 和 ETag
Last-Modified
Last-Modified 表示本地文件最后修改时间，If-Modified-Since 会将 Last-Modified 的值发送给服务器，询问服务器在该时间后资源是否有更新，有更新的话就会将新的资源发送回来。
以下是使用 Node 模拟的简单示例：
const http = require('http')
const fs = require('fs')
const server = http.createServer((req, res) => {
const reqModified = req.headers['if-modified-since']
const info = fs.statSync('./src/index.html')
const lastModified = info.mtime.toUTCString() // GTM
if (reqModified && reqModified === lastModified) {
console.log('浏览器走缓存')
res.statusCode = 304
res.end()
return
}
res.setHeader('Last-Modified', lastModified)
const html = fs.readFileSync('./src/index.html', 'utf8')
res.end(html)
})
server.listen(3000)
但是如果在本地打开缓存文件，就会造成 Last-Modified 被修改，所以在 HTTP/1.1 出现了 ETag。
ETag
ETag 类似于文件指纹，If-None-Match 会将当前 ETag 发送给服务器，询问该资源 ETag 是否变动，有变动的话就将新的资源发送回来。并且 ETag 优先级⽐ Last-Modified 高。
const http = require('http')
const fs = require('fs')
const crypto = require('crypto')
const server = http.createServer((req, res) => {
const buffer = fs.readFileSync('./src/index.html') // 二进制文件流
const hashTool = crypto.createHash('md5') // 使用 md5 加密算法
hashTool.update(buffer, 'utf8') // 注入二进制
const md5 = hashTool.digest('hex') // 生成 md5 加密的唯一标识 hash
const reqETag = req.headers['if-none-match']
if (reqETag && reqETag === md5) {
console.log('ETag 缓存')
res.statusCode = 304
res.end()
return
}
const reqModified = req.headers['if-modified-since']
const info = fs.statSync('./src/index.html')
const lastModified = info.mtime.toUTCString() // GTM
if (reqModified && reqModified === lastModified) {
console.log('modified 缓存')
res.statusCode = 304
res.end()
return
}
res.setHeader('Last-Modified', lastModified)
res.setHeader('ETag', md5)
const html = fs.readFileSync('./src/index.html', 'utf8')
res.end(html)
})
server.listen(3000)
注意：以上使用 Node 进行模拟的示例，真实情况具体如何要看服务器那边如何配置。
Last-Modified 与 ETag 的对比
- 性能上，
Last-Modified优于ETag，Last-Modified记录的是时间点，而Etag需要根据文件的 MD5 算法生成对应的 hash 值。 - 精度上，
ETag优于Last-Modified。ETag按照内容给资源带上标识，能准确感知资源变化，Last-Modified在某些场景并不能准确感知变化。
如果两者都存在，优先判断 If-None-Match 进行 ETag 协商缓存。
缓存位置
当命中强缓存和协商缓存返回 304 时，浏览器会从缓存中获取资源。
浏览器中的缓存位置一共有四种，按优先级从高到低排列分别是：
- Service Worker — 其借鉴了 Web Worker 思路，主要功能有：离线缓存、消息推送和网络代理，其中离线缓存就是
Service Worker Cache。 - Memory Cache — 内存缓存，从效率上讲它是最快的，从存活时间来讲又是最短的，当渲染进程结束后，内存缓存也就不存在了。
- Disk Cache — 存储在磁盘中的缓存，从存取效率上讲是比内存缓存慢的，优势在于存储容量和存储时长。
- Push Cache — 推送缓存，它浏览器缓存的最后一道防线，它是
HTTP/2的内容，详细内容可以查看 HTTP/2 push is tougher than I thought
浏览器在选择 Disk Cache 与 Memory Cache 的存储上：内容使用率高的，文件优先进入磁盘。比较大的 JS、CSS 文件会直接放入磁盘，反之放入内存。
强缓存与协商缓存区别
- 强缓存 — 浏览器不会与服务端协商，而是直接获取浏览器缓存。
- 协商缓存 — 浏览器会先向服务器确认资源的有效性后，才决定是从缓存中获取资源还是重新获取资源。
- 强缓存在浏览器进行判断，而协商缓存在服务端进行判断
总结
首先检查 Cache-Control，验证强缓存是否可用
- 如果可用的话，直接使用
- 否则进入协商缓存，发送 HTTP 请求，服务器通过请求头中的
If-Modified-Since或者If-None-Match字段检查资源是否更新- 资源更新，返回资源和 200 状态码。
- 否则，返回 304，告诉浏览器直接从缓存中获取资源。
本文首发 blog，如果喜欢或者有所启发，欢迎 Star，对作者也是一种鼓励。
