# 了解一下浏览器缓存

WEB 缓存体系
认识浏览器缓存
浏览器缓存好处
浏览器缓存机制
缓存判断流程
参考

# WEB 缓存体系

在实际 WEB 开发过程中，缓存技术会涉及到不同层、不同端，比如：用户层、系统层、代理层、前端、后端、服务端等，每一层的缓存目标都是一致的，就是尽快返回请求数据、减少延迟，但每层使用的技术实现是各有不同，面对不同层、不同端的优劣，选用不同的技术来提升系统响应效率。所以，我们首先看下各层的缓存都有哪些技术，都缓存哪些数据，从整体上，对 WEB 的缓存技术进行了解，如下图所示：

# 认识浏览器缓存

当浏览器请求一个网站的时候，会加载各种各样的资源，比如：HTML 文档、图片、CSS 和 JS 等文件。对于一些不经常变的内容，浏览器会将他们保存在本地的文件中，下次访问相同网站的时候，直接加载这些资源，加速访问。

这些被浏览器保存的文件就被称为缓存（不是指 Cookie 或者 Localstorage）。

那么如何知晓浏览器是读取了缓存还是直接请求服务器？如下图网站来做个示例：

第一次打开该网站后，如果再次刷新页面。会发现浏览器加载的众多资源中，有一部分 size 有具体数值，然而还有一部分请求，比如图片、css 和 js 等文件并没有显示文件大小，而是显示了 from dis cache 或者 from memory cache 字样。这就说明了，该资源直接从本地硬盘或者浏览器内存读取，而并没有请求服务器。

# 浏览器缓存好处

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

浏览器是否使用缓存、缓存多久，是由服务器控制的。准确来说，当浏览器请求一个网页（或者其他资源）时，服务器发回的响应的「响应头」部分的某些字段指明了有关缓存的关键信息。下面看下，HTTP 报文中与缓存相关的首部字段：

通用首部字段（就是请求报文和响应报文都能用上的字段）

请求首部字段

响应首部字段

实体首部字段

# 浏览器缓存机制

根据上面四种类型的首部字段不同使用策略，浏览器中缓存可分为强缓存和协商缓存：

浏览器在加载资源时，先根据这个资源的一些 http header 判断它是否命中强缓存，强缓存如果命中，浏览器直接从自己的缓存中读取资源，不会发请求到服务器。比如：某个 css 文件，如果浏览器在加载它所在的网页时，这个 css 文件的缓存配置命中了强缓存，浏览器就直接从缓存中加载这个 css，连请求都不会发送到网页所在服务器；
当强缓存没有命中的时候，浏览器一定会发送一个请求到服务器，通过服务器端依据资源的另外一些 http header 验证这个资源是否命中协商缓存，如果协商缓存命中，服务器会将这个请求返回，但是不会返回这个资源的数据，而是告诉客户端可以直接从缓存中加载这个资源，于是浏览器就又会从自己的缓存中去加载这个资源；
当协商缓存也没有命中的时候，浏览器直接从服务器加载资源数据。

# 强缓存与协商缓存的共同点

如果命中，都是从客户端缓存中加载资源，而不是从服务器加载资源数据；

# 强缓存与协商缓存的区别

强缓存不发请求到服务器
协商缓存会发请求到服务器

# 强缓存（Expires&Cache-Control）

当浏览器对某个资源的请求命中了强缓存时，返回的 HTTP 状态为 200，在 chrome 的开发者工具的 network 里面 size 会显示为 from cache，比如：京东的首页里就有很多静态资源配置了强缓存，用 chrome 打开几次，再用 F12 查看 network，可以看到有不少请求就是从缓存中加载的：

强缓存是利用 Expires 或者 Cache-Control 这两个 http response header 实现的，它们都用来表示资源在客户端缓存的有效期。

# Expires（http1.0）

Expires 是 HTTP 1.0 提出的一个表示资源过期时间的 header，它描述的是一个绝对时间，由服务器返回，用 GMT 格式的字符串表示，如：Expires:Thu, 31 Dec 2037 23:55:55 GMT，包含了 Expires 头标签的文件，就说明浏览器对于该文件缓存具有非常大的控制权。

例如，一个文件的 Expires 值是 2020 年的 1 月 1 日，那么就代表，在 2020 年 1 月 1 日之前，浏览器都可以直接使用该文件的本地缓存文件，而不必去服务器再次请求该文件，哪怕服务器文件发生了变化。

所以，Expires 是优化中最理想的情况，因为它根本不会产生请求，所以后端也就无需考虑查询快慢。它的缓存原理，如下：

浏览器第一次跟服务器请求一个资源，服务器在返回这个资源的同时，在 response 的 header 加上 Expires 的 header，如：

浏览器在接收到这个资源后，会把这个资源连同所有 response header 一起缓存下来（所以缓存命中的请求返回的 header 并不是来自服务器，而是来自之前缓存的 header）；
浏览器再请求这个资源时，先从缓存中寻找，找到这个资源后，拿出它的 Expires 跟当前的请求时间比较，如果请求时间在 Expires 指定的时间之前，就能命中缓存，否则就不行；
如果缓存没有命中，浏览器直接从服务器加载资源时，Expires Header 在重新加载的时候会被更新；

# Expires => Cache-Control 的原因

Expires 是较老的强缓存管理 header，由于它是服务器返回的一个绝对时间，在服务器时间与客户端时间相差较大时，缓存管理容易出现问题，比如：随意修改下客户端时间，就能影响缓存命中的结果。所以在 HTTP 1.1 的时候，提出了一个新的 header，就是 Cache-Control，这是一个相对时间，在配置缓存的时候，以秒为单位，用数值表示，如：Cache-Control:max-age=315360000

# Cache-Control（http1.1）

Cache-Control 的缓存原理是：

浏览器第一次跟服务器请求一个资源，服务器在返回这个资源的同时，在 response 的 header 加上 Cache-Control 的 header，如：

浏览器在接收到这个资源后，会把这个资源连同所有 response header 一起缓存下来；
浏览器再请求这个资源时，先从缓存中寻找，找到这个资源后，根据它第一次的请求时间和 Cache-Control 设定的有效期，计算出一个资源过期时间，再拿这个过期时间跟当前的请求时间比较，如果请求时间在过期时间之前，就能命中缓存，否则就不行；
如果缓存没有命中，浏览器直接从服务器加载资源时，Cache-Control Header 在重新加载的时候会被更新；

Cache-Control 描述的是一个相对时间，在进行缓存命中的时候，都是利用客户端时间进行判断，所以相比较 Expires，Cache-Control 的缓存管理更有效，安全一些。

这两个 header 可以只启用一个，也可以同时启用，当 response header 中，Expires 和 Cache-Control 同时存在时，Cache-Control 优先级高于 Expires：

Cache-Control 可以指定的值

max-age（单位为 s，必须）指定设置缓存最大的有效时间，定义的是时间长短。

当浏览器向服务器发送请求后，在 max-age 这段时间里浏览器就不会再向服务器发送请求了。例如：shang.qq.com 上的 css 资源，max-age=2592000，也就是说缓存有效期为 2592000 秒（也就是 30 天）。于是在 30 天内都会使用这个版本的资源，即使服务器上的资源发生了变化，浏览器也不会得到通知。

max-age会覆盖掉Expires
s-maxage（单位为 s）同 max-age，只用于共享缓存（比如 CDN 缓存）。 比如，当 s-maxage=60 时，在这 60 秒中，即使更新了 CDN 的内容，浏览器也不会进行请求。

max-age 用于普通缓存，而 s-maxage 用于代理缓存。

如果存在 s-maxage，则会覆盖掉 max-age 和 Expires header
public指定响应会被缓存，并且在多用户间共享。

通常情况下，对于所有人都可以访问的资源（例如网站的 logo、图片、脚本等）

**Cache-Control 默认设为 public **。
private 响应只作为私有的缓存（见下图），不能在用户间共享。

该资源仅仅属于发出请求的最终用户，这将禁止中间服务器（如代理服务器）缓存此类资源。

对于包含用户个人信息的文件（如一个包含用户名的 HTML 文档），可以设置 private，一方面由于这些缓存对其他用户来说没有任何意义，另一方面用户可能不希望相关文件储存在不受信任的服务器上。

需要指出的是，private 并不会使得缓存更加安全，它同样会传给中间服务器（如果网站对于传输的安全性要求很高，应该使用传输层安全措施）

如果要求 HTTP 认证，响应会自动设置为 private。

no-cache 指定不缓存响应，表明资源不进行缓存

设置了 no-cache 之后并不代表浏览器不缓存，而是在缓存前要向服务器确认资源是否被更改。

因此有的时候只设置 no-cache 防止缓存还是不够保险，还可以加上 private 指令，将过期时间设为过去的时间
no-store 绝对禁止缓存。

用了这个命令就不会进行缓存了，每次请求资源都要从服务器重新获取
must-revalidate指定如果页面是过期的，则去服务器进行获取。

这个指令并不常用，就不做过多的讨论了

# 控制强缓存字段的优先级

Pragma > Cache-Control

# 协商缓存（Last-Modified&Etag）

当浏览器对某个资源的请求没有命中强缓存，就会发一个请求到服务器，验证协商缓存是否命中，如果协商缓存命中，请求响应返回的 http 状态为 304 并且会显示一个 Not Modified 的字符串，比如你打开京东的首页，按 F12 打开开发者工具，再按 F5 刷新页面，查看 network，可以看到有不少请求就是命中了协商缓存的：

查看单个请求的 Response Header，也能看到 304 的状态码和 Not Modified 的字符串，只要看到这个就可说明这个资源是命中了协商缓存，然后从客户端缓存中加载的，而不是服务器最新的资源：

协商缓存是利用的是【Last-Modified，If-Modified-Since】和【ETag、If-None-Match】这两对 Header 来管理的。

# 【Last-Modified，If-Modified-Since】

【Last-Modified，If-Modified-Since】的控制缓存的原理，如下：

浏览器第一次跟服务器请求一个资源，服务器在返回这个资源的同时，在 response 的 header 加上 Last-Modified 的 header，这个 header 表示这个资源在服务器上的最后修改时间：

浏览器再次跟服务器请求这个资源时，在 request 的 header 上加上 If-Modified-Since 的 header，这个 header 的值就是上一次请求时返回的 Last-Modified 的值：

服务器再次收到资源请求时，根据浏览器传过来 If-Modified-Since 和资源在服务器上的最后修改时间判断资源是否有变化，如果没有变化则返回 304 Not Modified，但是不会返回资源内容；如果有变化，就正常返回资源内容。当服务器返回 304 Not Modified 的响应时，response header 中不会再添加 Last-Modified 的 header，因为既然资源没有变化，那么 Last-Modified 也就不会改变，这是服务器返回 304 时的 response header：

浏览器收到 304 的响应后，就会从缓存中加载资源。
如果协商缓存没有命中，浏览器直接从服务器加载资源时，Last-Modified Header 在重新加载的时候会被更新，下次请求时，If-Modified-Since 会启用上次返回的 Last-Modified 值。

# 【Last-Modified，If-Modified-Since】=>【ETag、If-None-Match】的原因

【Last-Modified，If-Modified-Since】都是根据服务器时间返回的 header，一般来说，在没有调整服务器时间和篡改客户端缓存的情况下，这两个 header 配合起来管理协商缓存是非常可靠的，但是有时候也会服务器上资源其实有变化，但是最后修改时间却没有变化的情况（服务端和客户端时间不一致），而这种问题又很不容易被定位出来，而当这种情况出现的时候，就会影响协商缓存的可靠性。所以就有了另外一对 header 来管理协商缓存，这对 header 就是【ETag、If-None-Match】。

# 【ETag、If-None-Match】

【ETag、If-None-Match】的缓存管理的方式是：

浏览器第一次跟服务器请求一个资源，服务器在返回这个资源的同时，在 response 的 header 加上 ETag 的 header，这个 header 是服务器根据当前请求的资源生成的一个唯一标识，这个唯一标识是一个字符串，只要资源有变化这个串就不同，跟最后修改时间没有关系，所以能很好的补充 Last-Modified 的问题：

浏览器再次跟服务器请求这个资源时，在 request 的 header 上加上 If-None-Match 的 header，这个 header 的值就是上一次请求时返回的 ETag 的值：

服务器再次收到资源请求时，根据浏览器传过来 If-None-Match 和然后再根据资源生成一个新的 ETag，如果这两个值相同就说明资源没有变化，否则就是有变化；如果没有变化则返回 304 Not Modified，但是不会返回资源内容；如果有变化，就正常返回资源内容。与 Last-Modified 不一样的是，当服务器返回 304 Not Modified 的响应时，由于 ETag 重新生成过，response header 中还会把这个 ETag 返回，即使这个 ETag 跟之前的没有变化：

浏览器收到 304 的响应后，就会从缓存中加载资源。

Etag 和 Last-Modified 非常相似，都是用来判断一个参数，从而决定是否启用缓存。但是 ETag 相对于 Last-Modified 也有其优势，可以更加准确的判断文件内容是否被修改，从而在实际操作中实用程度也更高。

协商缓存跟强缓存不一样，强缓存不发请求到服务器，所以有时候资源更新了浏览器还不知道，但是协商缓存会发请求到服务器，所以资源是否更新，服务器肯定知道。大部分 web 服务器都默认开启协商缓存，而且是同时启用【Last-Modified，If-Modified-Since】和【ETag、If-None-Match】，比如 apache:

如果没有协商缓存，每个到服务器的请求，就都得返回资源内容，这样服务器的性能会极差。

【Last-Modified，If-Modified-Since】和【ETag、If-None-Match】一般都是同时启用，这是为了处理 Last-Modified 不可靠的情况。有一种场景需要注意：

分布式系统里多台机器间文件的 Last-Modified 必须保持一致，以免负载均衡到不同机器导致比对失败；

分布式系统尽量关闭掉 ETag(每台机器生成的 ETag 都会不一样）；

比如，京东页面的资源请求，返回的 repsonse header 就只有 Last-Modified，没有 ETag：

协商缓存需要配合强缓存使用，上面这个截图中，除了 Last-Modified 这个 header，还有强缓存的相关 header，因为如果不启用强缓存的话，协商缓存根本没有意义。

ETag 属性之间的比较采用的是弱比较算法，即两个文件除了每个比特都相同外，内容一致也可以认为是相同的。例如，如果两个页面仅仅在页脚的生成时间有所不同，就可以认为二者是相同的。

因为ETag的特性，所以相较于Last-Modified有一些优势：

某些情况下服务器无法获取资源的最后修改时间
资源的最后修改时间变了但是内容没变，使用 ETag 可以正确缓存
如果资源修改非常频繁，在秒以下的时间进行修改，Last-Modified 只能精确到秒

# 控制协商缓存字段的优先级

ETag > Last-Modified

# 缓存判断流程

如果资源已经被浏览器缓存下来，在缓存失效之前，再次请求时，默认会先检查是否命中强缓存

如果强缓存命中则直接读取缓存
如果强缓存没有命中则发请求到服务器检查是否命中协商缓存
- 如果协商缓存命中，则告诉浏览器还是可以从缓存读取
- 否则才从服务器返回最新的资源。

其浏览器判断缓存的详细流程图，如下：

# 参考

前端优化：浏览器缓存技术介绍 (opens new window)

浏览器 HTTP 缓存机制 (opens new window)

浏览器缓存 (opens new window)

浏览器缓存 (opens new window)

← 渲染原理 url输入后发生什么 →