浏览器缓存机制

深入理解浏览器的缓存机制

缓存机制简介

1. 上图

2. 解释

  浏览器请求资源主要有三个阶段，第一阶段是发起请求，第二阶段是服务器处理请求，第三阶段是服务器向客户端浏览器响应请求资源。浏览器的缓存机制主要可以在第一阶段和第三阶段来优化。 通过强缓存直接使用本地缓存而不发起请求或者通过协商缓存判断本地缓存是否新鲜选择性的返回资源来减少数据传输来优化浏览器请求。
  浏览器的缓存机制主要通过在本地记录记录下最后一次服务服务器时资源的状态以及在请求头与响应头中添加相应字段来控制。主要包括三个部分或者三个阶段。
  首先，浏览器会判断当前请求的资源在本地是否有缓存，没有的话，直接向服务器发起请求获取资源以及缓存标识，并存入缓存。缓存标识的话比如就会有像 Last-Modified 记录资源在服务器上最后一次修改的时间，ETag 记录资源的唯一标识值。
  然后若是本地存在缓存的话，接下来就会根据强缓存以及协商缓存两种策略来决定是否使用本地缓存。
  首先是强缓存策略，通过缓存标识的 Expires 和 Cache-Control 在本地直接判断资源是否过期，若资源未过期则强缓存命中，直接使用本地缓存而无需发起请求。
  若资源过期，则继续使用协商缓存策略。浏览器向服务器发起请求，并在请求中携带 If-Modified-Since 或 If-None-Match 请求头，并在服务器中对比资源最后一次修改时间或利用资源的 ETag 来判断本地缓存是否可用，从而选择性的返回 “200状态码与新资源” 或者 “304状态码” 表明资源未修改，本地缓存可用。

总结来说就是三个部分

• 本地是否有缓存，没有的话直接向服务器请求；
• 有的话判断资源是否过期，未过期说明强缓存命中，直接使用本地缓存而无需发起请求；
• 过期则采用协商缓存策略，携带缓存标识发起请求。若在服务器端发现协商缓存命中，也就是缓存未过期，则返回304状态码告知浏览器可以使用本地缓存。若服务器发现缓存过期，则返回新资源。

3、实际场景应用缓存策略

1. 频繁变动的资源
   Cache-Control: no-cache
   对于频繁变动的资源，首先需要使用Cache-Control: no-cache使浏览器每次都请求服务器，然后配合 ETag 或者 Last-Modified 来验证资源是否有效。这样的做法虽然不能节省请求数量，但是能显著减少响应数据大小。
2. 不常变化的资源
   Cache-Control: max-age=31536000
   通常在处理这类资源时，给它们的 Cache-Control 配置一个很大的 max-age=31536000 (一年)，这样浏览器之后请求相同的 URL 会命中强制缓存。而为了解决更新的问题，就需要在文件名(或者路径)中添加 hash， 版本号等动态字符，之后更改动态字符，从而达到更改引用 URL 的目的，让之前的强制缓存失效 (其实并未立即失效，只是不再使用了而已)。
   在线提供的类库 (如 jquery-3.3.1.min.js, lodash.min.js 等) 均采用这个模式。

补充

1. max-age 与 max-stale 和 min-fresh 同时使用时，遵循“最为保守的缓存策略总是有效”

假设所请求资源于4月5日缓存, 且在4月12日过期.
如果max-age=10 days, max-stale=2 days, min-fresh=3 days, 那么:
1.根据max-age的设置, 覆盖原缓存周期, 缓存资源将在4月15日失效(5+10=15);
2.根据max-stale的设置, 缓存过期后两天依然有效, 此时响应将返回110(Response is stale)状态码, 缓存资源将在4月14日失效(12+2=14);
3.根据min-fresh的设置, 至少要留有3天的新鲜期, 缓存资源将在4月9日失效(12-3=9);
4.遵循"最为保守的缓存策略总是有效的"，当三者同时存在时，4月9日后, 对于该资源的请求将重新向服务器发起验证.

2. Pragma请求header: 兼容http1.0