浏览器缓存

菜心儿
192 阅读12分钟

为了方便记忆先来个总结：

Header内的字段用于控制缓存机制，强缓存优先于协商缓存

强缓存（Expires和Cache-Control）：老方法Expires，记录的绝对值；新方法Cache-Control，多了一堆选项，记录的时间max-age是相对值，获取缓存，检测缓存是否过期，没过期取缓存，优先从内存，其次硬盘

如果过期，则进行协商缓存(Last-Modified / If-Modified-Since和Etag / If-None-Match)，协商缓存由服务器决定是否使用缓存，若协商缓存失效，重新获取请求结果，再存入浏览器缓存中；生效则返回304，取缓存

1. 概述

浏览器的缓存机制也就是我们说的HTTP缓存机制，其机制是根据HTTP报文的缓存标识进行的，所以在分析浏览器缓存机制之前，先使用图文简单介绍一下HTTP报文，HTTP报文分为两种：

HTTP请求(Request)报文，报文格式为：请求行 – HTTP头(通用信息头，请求头，实体头) – 请求报文主体(只有POST才有报文主体)，如下图：

http4.png

HTTP响应(Response)报文，报文格式为：状态行 – HTTP头(通用信息头，响应头，实体头) – 响应报文主体，如下图： HTTP3.png

注：通用信息头指的是请求和响应报文都支持的头域，分别为Cache-Control、Connection、Date、Pragma、Transfer-Encoding、Upgrade、Via；实体头则是实体信息的实体头域，分别为Allow、Content-Base、Content-Encoding、Content-Language、Content-Length、Content-Location、Content-MD5、Content-Range、Content-Type、Etag、Expires、Last-Modified、extension-header。这里只是为了方便理解，将通用信息头，响应头/请求头，实体头都归为了HTTP头。

浏览器缓存如果处理不当，可能会导致服务端代码更新了，但是用户却还是老页面。所以我们要针对项目中各个资源的实际情况，做出合理的缓存策略。

缓存的优点：

  • 减少了冗余的数据传输，节省网费
  • 减少服务器的负担，提升网站性能
  • 加快了客户端加载网页的速度

2. 缓存过程分析

浏览器与服务器通信的方式为应答模式，即：浏览器发起HTTP请求 – 服务器响应该请求。那么浏览器第一次向服务器发起该请求后拿到请求结果，会根据响应报文中HTTP头的缓存标识，决定是否缓存结果，是则将请求结果和缓存标识存入浏览器缓存中，简单的过程如下图：

第一次发起http请求： http7.png 由上图我们可以知道：

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

以上两点结论就是浏览器缓存机制的关键，他确保了每个请求的缓存存入与读取，只要我们理解浏览器缓存的使用规则，那么所有的问题就迎刃而解了，接下来将围绕着这点进行详细分析。为了方便大家理解，这里我们根据是否需要向服务器重新发起HTTP请求将缓存过程分为两个部分，分别是强制缓存和协商缓存。

3. 缓存规则

强缓存和协商缓存

强缓存

强制缓存就是向浏览器缓存查找该请求结果，并根据该结果的缓存规则来决定是否使用该缓存结果的过程，强制缓存的情况主要有三种(暂不分析协商缓存过程)，如下：

  1. 不存在该缓存结果和缓存标识，强制缓存失效，则直接向服务器发起请求（跟第一次发起请求一致），如下图：

http8.png

  1. 存在该缓存结果和缓存标识，但该结果已失效，强制缓存失效，则使用协商缓存(暂不分析)，如下图：

http9.png

  1. 存在该缓存结果和缓存标识，且该结果尚未失效，强制缓存生效，直接返回该结果，如下图：

http10.png

那么强缓存的缓存规则是什么？

当浏览器向服务器发起请求时，服务器会将缓存规则放入HTTP响应报文的HTTP头中和请求结果一起返回给浏览器，控制强制缓存的字段分别是Expires和Cache-Control，其中Cache-Control优先级比Expires高。

Expires

Expires是HTTP/1.0控制网页缓存的字段，其值为服务器返回该请求结果缓存的到期时间，即再次发起该请求时，如果客户端的时间小于Expires的值时，直接使用缓存结果。

Expires是HTTP/1.0的字段，但是现在浏览器默认使用的是HTTP/1.1，那么在HTTP/1.1中网页缓存还是否由Expires控制？

到了HTTP/1.1，Expire已经被Cache-Control替代，原因在于Expires控制缓存的原理是使用客户端的时间与服务端返回的时间做对比，那么如果客户端与服务端的时间因为某些原因（例如时区不同；客户端和服务端有一方的时间不准确）发生误差，那么强制缓存则会直接失效，这样的话强制缓存的存在则毫无意义，那么Cache-Control又是如何控制的呢？

Cache-Control

在HTTP/1.1中，Cache-Control是最重要的规则，主要用于控制网页缓存，主要取值为：

  • public：所有内容都将被缓存（客户端和代理服务器都可缓存）
  • no-cache：客户端缓存内容，但是是否使用缓存则需要经过协商缓存来验证决定（重要）
  • no-store：所有内容都不会被缓存，即不使用强制缓存，也不使用协商缓存
  • max-age=xxx (xxx is numeric)：缓存内容将在xxx秒后失效（重要）

注：规则可以同时多个

http25.png

这里有个问题，就是 max-age = 0 ，和 no-cache 有啥区别，我理解的是，no-cache直接不进行强缓存，让你去走协商缓存，而max-age=0是进行强缓存，但是过期了，需要更新，虽然实际上看起来两者效果是一样的。

接下来，我们直接看一个例子，如下：

http11.png 由上面的例子我们可以知道：

  • HTTP响应报文中expires的时间值，是一个绝对值
  • HTTP响应报文中Cache-Control为max-age=600，是相对值

由于Cache-Control的优先级比expires，那么直接根据Cache-Control的值进行缓存，意思就是说在600秒内再次发起该请求，则会直接使用缓存结果，强制缓存生效

注：在无法确定客户端的时间是否与服务端的时间同步的情况下，Cache-Control相比于expires是更好的选择，所以同时存在时，只有Cache-Control生效。

了解强制缓存的过程后，我们拓展性的思考一下：

浏览器的缓存存放在哪里，如何在浏览器中判断强制缓存是否生效？

http12.png 上图网页状态码为灰色的请求则代表使用了强制缓存，请求对应的Size值则代表该缓存存放的位置，分别为from memory cache 和 from disk cache。

那么from memory cache 和 from disk cache又分别代表的是什么呢？什么时候会使用from disk cache，什么时候会使用from memory cache呢？

from memory cache代表使用内存中的缓存，from disk cache则代表使用的是硬盘中的缓存，浏览器读取缓存的顺序为memory –> disk。

接下来我们一起详细分析一下缓存读取问题，这里仍以上图为例进行分析：

访问网页 –> 200 –> 关闭标签页 –> 重新打开网页 –> 200(from disk cache) –> 刷新 –> 200(from memory cache)

过程如下：

  • 访问网页

http13.png

  • 关闭标签页
  • 重新打开页面

http14.png

  • 刷新

http15.png 可能有人小伙伴问了，最后一个步骤刷新的时候，不是同时存在着from disk cache和from memory cache吗？

对于这个问题，我们需要了解内存缓存(from memory cache)和硬盘缓存(from disk cache)，如下:

  • 内存缓存(from memory cache)：内存缓存具有两个特点，分别是快速读取和时效性：
  • 快速读取：内存缓存会将编译解析后的文件，直接存入该进程的内存中，占据该进程一定的内存资源，以方便下次运行使用时的快速读取。
  • 时效性：一旦该进程关闭，则该进程的内存则会清空。
  • 硬盘缓存(from disk cache)：硬盘缓存则是直接将缓存写入硬盘文件中，读取缓存需要对该缓存存放的硬盘文件进行I/O操作，然后重新解析该缓存内容，读取复杂，速度比内存缓存慢。

在浏览器中，浏览器会在js和图片等文件解析执行后直接存入内存缓存中，那么当刷新页面时只需直接从内存缓存中读取(from memory cache)；而css文件则会存入硬盘文件中，所以每次渲染页面都需要从硬盘读取缓存(from disk cache)。

协商缓存

协商缓存就是强制缓存失效后，浏览器携带缓存标识向服务器发起请求，由服务器根据缓存标识决定是否使用缓存的过程，主要有以下两种情况：

协商缓存生效，返回304，如下：

http16.png 协商缓存失效，返回200和请求结果结果，如下：

http17.png 同样，协商缓存的标识也是在响应报文的HTTP头中和请求结果一起返回给浏览器的，控制协商缓存的字段分别有：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是服务器响应请求时，返回该资源文件在服务器最后被修改的时间，如下：

http18.png If-Modified-Since则是客户端再次发起该请求时，携带上次请求返回的Last-Modified值，通过此字段值告诉服务器该资源上次请求返回的最后被修改时间。服务器收到该请求，发现请求头含有If-Modified-Since字段，则会根据If-Modified-Since的字段值与该资源在服务器的最后被修改时间做对比，若服务器的资源最后被修改时间大于If-Modified-Since的字段值，则重新返回资源，状态码为200；否则则返回304，代表资源无更新，可继续使用缓存文件，如下：

http19.png

Etag / If-None-Match

Etag是服务器响应请求时，返回当前资源文件的一个唯一标识(由服务器生成)，如下：

http20.png If-None-Match是客户端再次发起该请求时，携带上次请求返回的唯一标识Etag值，通过此字段值告诉服务器该资源上次请求返回的唯一标识值。服务器收到该请求后，发现该请求头中含有If-None-Match，则会根据If-None-Match的字段值与该资源在服务器的Etag值做对比，一致则返回304，代表资源无更新，继续使用缓存文件；不一致则重新返回资源文件，状态码为200，如下。

http21.png 注：Etag / If-None-Match优先级高于Last-Modified / If-Modified-Since，同时存在则只有Etag / If-None-Match生效。

4. 其他

  • 怎么配置资源的缓存规则

可以在后端服务器配置，也可以在nginx中配置 26.png

java代码中增加如下代码

28.png

  • 为什么要有Etag

你可能会觉得使用Last-Modified已经足以让浏览器知道本地的缓存副本是否足够新，为什么还需要Etag呢？HTTP1.1中Etag的出现（也就是说，ETag是新增的，为了解决之前只有If-Modified的缺点）主要是为了解决几个Last-Modified比较难解决的问题：

一些文件也许会周期性的更改，但是他的内容并不改变(仅仅改变的修改时间)，这个时候我们并不希望客户端认为这个文件被修改了，而重新GET；

某些文件修改非常频繁，比如在秒以下的时间内进行修改，(比方说1s内修改了N次)，If-Modified-Since能检查到的粒度是s级的，这种修改无法判断(或者说UNIX记录MTIME只能精确到秒)

某些服务器不能精确的得到文件的最后修改时间。

  • 强缓存与协商缓存的区别可以用下表来表示：

11.png

  • 用户行为对缓存的影响 22.png

即：F5 会 跳过强缓存规则，直接走协商缓存；Ctrl+F5 ，跳过所有缓存规则，和第一次请求一样，重新获取资源

  • 项目缓存策略

比如 vue 项目，脚手架已经将更改的文件做 hash 处理了，因此一般的 js、css 文件不需要我们再去操作。 而对于 index.html，我们需要在 nginx 上做 no-store 处理，即完全不缓存 index.html，每次都请求最新的html，因为 html 中会外链 css、js，如果我 html 还是走的缓存，那链接的还是老的 css 。

总结

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

http22.png

avatar
文章
阅读
粉丝