HTTP 缓存

强缓存

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，对作者也是一种鼓励。