理论篇 | 浏览器缓存机制

这是我参与8月更文挑战的第4天，活动详情查看：8月更文挑战

前言

网络层面的性能优化，使用缓存是一个最直接有效的方案。使用缓存能够减小网络 IO 消耗，提升访问速度，效果显著。所以，认识一下浏览器的缓存机制颇有必要。

上图 Network 面板的截图中，咱们能够看到 size 列能够看到缓存的获取来源。

浏览器缓存机制有四个方面，它们按请求的优先级依次排列以下：

1. Memory Cache
2. Service Worker Cache
3. HTTP Cache
4. Push Cache

Chrome 官方的缓存决策流程图

其中，HTTP 缓存是最主要、最具表明性的缓存策略，咱们先来认识一下这位 HTTP 缓存机制。

HTTP 缓存机制

HTTP缓存又分为强缓存和协商缓存，强缓存优先级高于协商缓存，资源没有命中强缓存，才会走协商缓存。

强缓存

特征

• 强缓存由 HTTP 头中的 Expires 和 Cache-Control 两个字段控制
• 若是浏览器判断目标资源命中强缓存，则直接从缓存中获取资源
• 强缓存命中时，返回HTTP状态码为 200

从 expires 到 Cache-Control

• expires 是一个时间戳，若是本地时间小于 expires 设定的过时时间，那么就直接去缓存中取这个资源。
• 问题：时间戳由服务端生成，客户端和服务端之间可能存在时间差
• 解决：能够在 Cache-Control 中配置 max-age，max-age设定的是相对时间长度，表示在时间长度内有效。从而规避 expires 的时差问题。
• Cache-Control 的 max-age 优先级高于 expires
• max-age能够视做是对 expires 的补位/替换，但若是有向下兼容的诉求，expires 仍是要的。

Cache-Control 的其余配置项

• s-maxage：仅在代理服务器中生效
• public 与 private：
  • public：既能够被浏览器缓存，也能够被代理服务器缓存；
  • private：只能被浏览器缓存（默认）
• no-store：绕开浏览器，直接向服务端去确认该资源是否过时（走协商缓存）
• no-cache：不使用任何缓存策略，直接向服务端请求资源

协商缓存

特征

• 协商缓存是浏览器和服务端合做的缓存策略
• 浏览器询问服务端是否使用缓存，若是服务端响应 304(Not Modify)，即资源未改动，则使用浏览器缓存。

Last-Modified

实现

• 启用协商缓存，首次请求时，响应头携带 Last-Modified（时间戳）返回
• 以后每次请求，带上 If-Modified-Since ，值为首次请求时的 Last-Modified的值
• 服务器对比If-Modified-Since和资源的最后修改时间是否一致
  • 若是一致，返回 304
  • 若是不一致，返回完整的响应内容，并在响应头添加新的 Last-Modified

问题
Last-Modified 存在一些弊端，

• 文件编辑过，内容未修改，但最后修改时间改变了
• 文件内容修改了，但修改速度过快（未满1s），而 If-Modified-Since 只能检查到以秒为最小计量单位的时间差

对于上面两种场景，Last-Modified 没法正确判断资源是否变化。

Etag

为了解决上述问题，Etag 做为 Last-Modified 的补充出现了。

• 首次请求时，响应头携带 ETag 返回
• 以后每次请求，携带 if-None-Match（值为ETag的值）
• 当 Etag 和 Last-Modified 同时存在时，以 Etag 为准

弊端： Etag 生成过程须要服务器额外付出开销，影响服务端性能。