HTTP缓存

缓存是一种保存资源副本并在下次请求时直接使用该副本的技术。

使用缓存的优点：

• 减少冗余的数据传输
• 减少服务器负担
• 加快客户端加载网页的速度

根据是否需要向服务器重新发起 HTTP 请求将缓存过程分为两个部分，分别是 强缓存 和 协商缓存(弱缓存、对比缓存) 。

HTTP 缓存过程分析

浏览器 第一次 向服务器发起该请求后拿到请求结果，会根据响应报文中HTTP头的缓存标识，决定是否缓存结果，是则将请求结果和缓存标识存入浏览器缓存中，简单的过程如下图：

cache.jpg

由上图我们可以知道：

• 浏览器每次发起请求，都会先在浏览器缓存中查找该请求的结果以及缓存标识
• 浏览器每次拿到返回的请求结果都会将该结果和缓存标识存入浏览器缓存中

当浏览器 再次请求 该资源时，浏览器会先获取该资源缓存的 header 信息，根据其中的 Expires 和 Cache-Control 判断是否命中 强缓存，若命中则直接从浏览器缓存中获取资源，包括缓存的header信息，本次请求不会与服务器进行通信；如果没有命中强缓存，浏览器会发送请求到服务器，该请求会携带第一次请求返回的有关缓存的 header 字段信息（Last-Modified/IF-Modified-Since、Etag/IF-None-Match）,由服务器根据请求中的相关 header 信息来对比结果是否命中 协商缓存，若命中，则服务器返回新的响应 header 信息更新缓存中的对应 header 信息，但是并不返回资源内容，它会告知浏览器从缓存获取资源；否则返回最新的资源内容

强缓存

当浏览器对某个资源的请求命中了强缓存时，返回的http状态为200，在chrome的开发者工具的network里面size会显示为from cache

强缓存是利用 http 的返回头中的 Expires 或者 Cache-Control 字段来控制的，用来表示资源在客户端缓存的有效期，Cache-Control 的优先级更高。

Expires

该字段是 http1.0 时的规范，它的值为一个 绝对时间 的GMT格式的时间字符串，比如 Expires:Mon,18 Oct 2022 23:59:59 GMT。这个时间代表着这个资源的失效时间，在此时间之前，即命中缓存。

这种方式有一个明显的缺点，由于失效时间是一个绝对时间，所以当服务器与客户端时间偏差较大时，缓存管理容易出现问题，比如随意修改下客户端时间，就能影响缓存命中的结果。因此，在 http1.1 的时候，提出了一个新的 header，就是 Cache-Control。

Cache-control

Cache-Control 是 http1.1 时出现的header信息，默认取值为 private，常见取值有：

• private：只有客户端可以缓存，不能作为共享缓存（即代理服务器不能缓存）(默认值)
• public：表明响应可以被任何对象（发送请求的客户端、代理服务器等等）缓存
• max-age=< secends >：设置缓存存储的最大周期，超过这个时间缓存被认为过期(单位秒)
• no-cache：协商缓存验证，客户端缓存内容，但是能否使用缓存需要经过协商缓存来验证决定
• no-store：不使用任何缓存, 强缓存和协商缓存都不会触发

注意：规则可以同时设置多个。

指定 no-cache 或 max-age=0, must-revalidate 表示客户端可以缓存资源，每次使用缓存资源前都必须重新验证其有效性。这意味着每次都会发起 HTTP 请求，但当缓存内容仍有效时可以跳过 HTTP 响应体的下载。

最常使用的是利用该字段的 max-age 值来进行判断，它是一个相对时间。例如 Cache-Control:max-age=3600，代表着资源的有效期是3600秒。

如果在 Cache-Control 响应头设置了 max-age 或者 s-max-age 指令，那么 Expires 头会被忽略。

常见强缓存策略

• Cache-Control: max-age=xxxx, immutable:
  客户端在xxx秒的有效期内，直接读取缓存, 状态码 200 ，即使用户做了刷新操作，也不向服务器发起http请求

协商缓存

协商缓存就是强缓存失效后，浏览器携带缓存标识向服务器发起请求，由服务器根据缓存标识决定是否使用缓存的过程。如果协商缓存命中，则返回 304 状态码并且会显示一个 Not Modified 的字符串，如果未命中，则会返回 200 状态码及最新的资源和缓存标识。

控制协商缓存的字段有下面2组：Last-Modified / If-Modified-Since 和 Etag / If-None-Match，其中 Etag / If-None-Match 的优先级比 Last-Modified / If-Modified-Since 高。

Last-Modified / If-Modified-Since

Last-Modified

浏览器第一次请求一个资源的时候，服务器在响应头中会加上 Last-Modified，它标识该资源的最后修改时间，例如 Last-Modified: Thu,31 Dec 2037 23:59:59 GMT。

If-Modified-Since

当浏览器再次请求该资源时，会在请求头中加上 If-Modified-Since，它的值为上次请求返回的 Last-Modified值。服务器收到该请求，则会根据If-Modified-Since的值与该资源在服务器的最后被修改时间做对比，若服务器的资源最后被修改时间大于If-Modified-Since的字段值，则重新返回资源，状态码为200；否则返回304 Not Modified，代表资源无更新，可继续使用缓存文件，并且不会返回Last-Modified。

If-Modified-Since 只可以用在 GET 或 HEAD 请求中，当与 If-None-Match 一同出现时，它（If-Modified-Since）会被忽略掉，除非服务器不支持 If-None-Match。

Etag / If-None-Match

Etag

Etag 表示当前资源在服务器的唯一标识（生成规则由服务器决定）。

浏览器第一次请求时，服务器会在 响应头 中加上 Etag 字段。

If-None-Match

当浏览器再次请求该资源时，会在请求头中加上 If-None-Match，它的值为上次请求返回的 Etag值。
服务器收到该请求, 则会根据 If-None-Match的值和根据服务器资源重新生成新的 ETag 值进行比对，
若不同，说明资源被改动过，则返回新的资源内容，返回状态码200；
若相同，说明资源无新修改，则返回 304 Not Modified，告知浏览器可继续使用缓存文件，还是会返回新生成的 Etag

Etag 和 Last-Modified 对比

Etag 的出现主要解决了 Last-Modified 以下几个问题：

• 某些文件可能仅仅改变了修改时间，内容并没有改变，这个时候我们并不希望客户端认为这个文件被修改了，而重新 GET
• 某些文件修改非常频繁，比如在秒以下的时间内进行修改，(比方说1s内修改了N次)，If-Modified-Since 能检查到的粒度是秒级的，这种修改无法判断(或者说UNIX记录MTIME只能精确到秒)
• 某些服务器不能精确的得到文件的最后修改时间

用户行为对缓存的影响

更新缓存

• F5： 刷新网页时，会跳过强缓存，但是会检查协商缓存
• Ctrl + F5： 强制刷新网页时，会直接从服务器加载，跳过强缓存和协商缓存
• 版本号控制： 在资源请求的 URL 中增加一个版本号参数，比如：js/mian.js?ver=0.0.1。每次部署的时候变更一下版本号，当这个参数发生变化，强缓存都会失效并重新加载，这样就可以解决客户端升级时的缓存更新问题。

总结

强缓存优先于协商缓存进行，若强缓存 (Expires 和 Cache-Control) 生效则直接使用缓存，若不生效则进行协商缓存 (Last-Modified/If-Modified-Since 和 Etag/If-None-Match)，协商缓存由服务器决定是否使用缓存，若协商缓存失效，那么代表该请求的缓存失效，重新获取请求结果，再存入浏览器缓存中；生效则返回304，继续使用缓存。

主要过程如下：

image.png

参考文章

• http://caibaojian.com/browser-cache.html

• https://heyingye.github.io/2018/04/16/%E5%BD%BB%E5%BA%95%E7%90%86%E8%A7%A3%E6%B5%8F%E8%A7%88%E5%99%A8%E7%9A%84%E7%BC%93%E5%AD%98%E6%9C%BA%E5%88%B6

• https://juejin.cn/post/6844903763665240072

完