浏览器是如何实现Http缓存机制的？

《参考资料》

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

《浏览器缓存原理以及本地存储》

《MDN文档》

《HTTP缓存机制》

---

-----------------------正文分割线--------------------------------

前言

Web 缓存大致可以分为：数据库缓存、服务器端缓存（代理服务器缓存、CDN 缓存）、浏览器缓存。

浏览器缓存也包含很多内容： HTTP 缓存、indexDB、cookie、localstorage 等等。

这里只讨论 HTTP 缓存相关内容。

在具体了解 HTTP 缓存之前先来明确几个术语：

• 缓存命中率：从缓存中得到数据的请求数与所有请求数的比率。理想状态是越高越好。
• 过期内容：超过设置的有效时间，被标记为“陈旧”的内容。通常过期内容不能用于回复客户端的请求，必须重新向源服务器请求新的内容或者验证缓存的内容是否仍然准备。
• 验证：验证缓存中的过期内容是否仍然有效，验证通过的话刷新过期时间。
• 失效：失效就是把内容从缓存中移除。当内容发生改变时就必须移除失效的内容。

浏览器缓存主要是 HTTP 协议定义的缓存机制。HTML meta 标签，例如

含义是让浏览器不缓存当前页面。但是代理服务器不解析 HTML 内容，一般应用广泛的是用 HTTP 头信息控制缓存。

缓存位置

从缓存位置上来说，缓存分为四种，并且各自有优先级，当依次查找缓存且都没有命中的时候，才会去请求网络。

1.Service Worker

Service Worker 是运行在浏览器背后的独立线程，一般可以用来实现缓存功能。

使用 Service Worker的话，传输协议必须为 HTTPS。

Service Worker 中涉及到请求拦截，所以必须使用 HTTPS 协议来保障安全。

Service Worker 的缓存与浏览器其他内建的缓存机制不同，它可以让我们自由控制缓存哪些文件、如何匹配缓存、如何读取缓存，并且缓存是持续性的。

Service Worker 实现缓存功能一般分为几个步骤：

• 首先需要先注册 Service Worker

• 监听到 install 事件以后就可以缓存需要的文件，那么在下次用户访问的时候就可以通过拦截请求的方式查询是否存在缓存，存在缓存的话就可以直接读取缓存文件，否则就去请求数据。

• 当 Service Worker 没有命中缓存的时候，我们需要去调用 fetch 函数获取数据。也就是说，如果我们没有在 Service Worker 命中缓存的话，会根据缓存查找优先级去查找数据。但是不管我们是从 Memory Cache 中还是从网络请求中获取的数据，浏览器都会显示我们是从 Service Worker 中获取的内容。

2.Memory Cache

Memory Cache 也就是内存中的缓存，主要包含的是当前中页面中已经抓取到的资源,例如页面上已经下载的样式、脚本、图片等。读取内存中的数据肯定比磁盘快,内存缓存虽然读取高效，可是缓存持续性很短，会随着进程的释放而释放。 一旦关闭 Tab 页面，内存中的缓存也就被释放了。

那么既然内存缓存这么高效，是不是能让数据都存放在内存中呢？
这是不可能的。计算机中的内存一定比硬盘容量小得多，操作系统需要精打细算内存的使用，所以能让我们使用的内存必然不多。

当我们访问过页面以后，再次刷新页面，可以发现很多数据都来自于内存缓存

内存缓存中有一块重要的缓存资源是preloader相关指令（例如<link rel="prefetch">）下载的资源。

preloader的相关指令已经是页面优化的常见手段之一，它可以一边解析js/css文件，一边网络请求下一个资源。

需要注意的事情是，内存缓存在缓存资源时并不关心返回资源的HTTP缓存头Cache-Control是什么值，同时资源的匹配也并非仅仅是对URL做匹配，还可能会对Content-Type，CORS等其他特征做校验。

3.Disk Cache

Disk Cache 也就是存储在硬盘中的缓存，读取速度慢点，但是什么都能存储到磁盘中，比之 Memory Cache 胜在容量和存储时效性上。

在所有浏览器缓存中，Disk Cache 覆盖面基本是最大的。它会根据 HTTP Herder 中的字段判断哪些资源需要缓存，哪些资源可以不请求直接使用，哪些资源已经过期需要重新请求。并且即使在跨站点的情况下，相同地址的资源一旦被硬盘缓存下来，就不会再次去请求数据。绝大部分的缓存都来自 Disk Cache，关于 HTTP 的协议头中的缓存字段，我们会在下文进行详细介绍。

浏览器会把哪些文件丢进内存中？哪些丢进硬盘中？
关于这点，网上说法不一，不过以下观点比较靠得住：

• 对于大文件来说，大概率是不存储在内存中的，反之优先
• 当前系统内存使用率高的话，文件优先存储进硬盘

4.Push Cache

Push Cache（推送缓存）是 HTTP/2 中的内容，当以上三种缓存都没有命中时，它才会被使用。它只在会话（Session）中存在，一旦会话结束就被释放，并且缓存时间也很短暂，在Chrome浏览器中只有5分钟左右，同时它也并非严格执行HTTP头中的缓存指令。

• 所有的资源都能被推送，并且能够被缓存,但是 Edge 和 Safari 浏览器支持相对比较差
• 可以推送 no-cache 和 no-store 的资源
• 一旦连接被关闭，Push Cache 就被释放
• 多个页面可以使用同一个HTTP/2的连接，也就可以使用同一个Push Cache。这主要还是依赖浏览器的实现而定，出于对性能的考虑，有的浏览器会对相同域名但不同的tab标签使用同一个HTTP连接。
• Push Cache 中的缓存只能被使用一次
• 浏览器可以拒绝接受已经存在的资源推送
• 你可以给其他域名推送资源

如果以上四种缓存都没有命中的话，那么只能发起请求来获取资源了。

缓存过程

强制缓存

判断HTTP首部字段：cache-control，Expires。

Expires是一个绝对时间，即服务器时间。浏览器检查当前时间，如果还没到失效时间就直接使用缓存文件。但是该方法存在一个问题：服务器时间与客户端时间可能不一致。因此该字段已经很少使用。

cache-control中的max-age保存一个相对时间。例如Cache-Control: max-age = 484200，表示浏览器收到文件后，缓存在484200s内均有效。 如果同时存在cache-control和Expires，浏览器总是优先使用cache-control。

• 判断是否过期（服务器会通知浏览器一个缓存时间，相关头部信息在Cache-Control和Expires中），如果时间未过期，则直接从缓存中取，即强缓存；

  • Cache-Control

    • 其中max-age = <seconds>设置缓存存储的最大周期，超过这个时间缓存将会被认为过期，与Expires相反，时间是相对于请求的时间
    • public 表示响应可以被任何对象缓存，即使是通常不可缓存的内容
    • private 表示缓存只能被单个用户缓存，不能作为共享缓存（即代理服务器不可缓存它）
    • no-cache 告诉浏览器、缓存服务器，不管本地副本是否过期，使用副本前一定要到源服务器进行副本有效校验
    • no-store 缓存不应该存储有关客户端请求或服务器响应的任何内容

  • Expires(不推荐使用)

    • expires 字段规定了缓存的资源的过期时间，该字段时间格式使用GMT时间标准时间格式， js通过new Date().toUTCString()得到，由于时间期限是由服务器生成，存在着服务端和客户端的时间误差，相比cache-control优先级较低

注：cache-control和expires谁的优先级更高(常见问题)

对比缓存（协商缓存）

通过HTTP的last-modified，Etag字段进行判断。

last-modified是第一次请求资源时，服务器返回的字段，表示最后一次更新的时间。下一次浏览器请求资源时就发送if-modified-since字段。服务器用本地Last-modified时间与if-modified-since时间比较，如果不一致则认为缓存已过期并返回新资源给浏览器；如果时间一致则发送304状态码，让浏览器继续使用缓存。

Etag：资源的实体标识（哈希字符串），当资源内容更新时，Etag会改变。服务器会判断Etag是否发生变化，如果变化则返回新资源，否则返回304。

• 那么如果判断缓存时间已经过期，将会采用协商缓存策略
  • Last-Modified响应头和If-Modified-Since请求头
    • Last-Modified 表示资源最后的修改时间，在浏览器第一次发送HTTP请求时，服务器会返回该响应头
    • 那么浏览器在下次发起HTTP请求时，会带上If-Modified-Since请求头，其值就是第一次发送HTTP请求时，服务器设置在Last-Modified响应头中的值
    • 两种情况：如果资源最后修改时间大于If-Modified-Since，说明资源有被改动过，则响应完整的资源内容，返回状态码200；如果小于或者等于，说明资源未被修改，则响应状态码304，告知浏览器可以继续使用所保存的缓存
  • Etag响应头和If-None-Match请求头
    • Etag值为当前资源在服务器的唯一标识
    • 类比上面Last-Modified响应头和If-Modified-Since请求头，请求头中If-None-Match将会和资源的唯一标标识进行对比，如果不同，则说明资源被修改过，响应200；如果相同，则说明资源未改动，响应304

流程图

浏览器第一次请求

浏览器再次请求时：

补充

Cache-Control

• HTTP/1.1中引入的机制
• 主要用于控制网页缓存
• Cache-Control 可以在请求头或者响应头中设置，并且可以组合使用多种指令

指令	作用
public	表示响应可以被客户端和代理服务器缓存
private	表示响应只可以被客户端缓存
max-age=30	缓存30秒后就过期，需要重新请求
s-maxage=30	覆盖max-age，作用一样，只在代理服务器中生效
no-store	不缓存任何相应
no-cache	资源被缓存，但是立即失效，下次会发起请求验证资源是否过期
max-stable	30秒内，即使缓存过期，也使用该缓存
min-fresh	希望在30秒内获取最新的相应

例如，当Cache-Control:max-age=300时，则代表在这个请求正确返回时间（浏览器也会记录下来）的5分钟内再次加载资源，就会命中强缓存。

• public

所有内容都将被缓存（客户端和代理服务器都可缓存）

具体来说响应可被任何中间节点缓存，如 Browser <-- proxy1 <-- proxy2 <-- Server，中间的proxy可以缓存资源，比如下次再请求同一资源proxy1直接把自己缓存的东西给 Browser 而不再向proxy2要。

• private

所有内容只有客户端可以缓存

Cache-Control的默认取值。

表示中间节点不允许缓存，对于Browser <-- proxy1 <-- proxy2 <-- Server，proxy 会老老实实把Server 返回的数据发送给proxy1,自己不缓存任何数据。当下次Browser再次请求时，proxy会做好请求转发而不是自作主张给自己缓存的数据。

• no-cache

客户端缓存内容，是否使用缓存则需要经过协商缓存来验证决定。

表示不使用 Cache-Control的缓存控制方式做前置验证，而是使用 Etag 或者Last-Modified字段来控制缓存。需要注意的是，no-cache这个名字有一点误导。设置了no-cache之后，并不是说浏览器就不再缓存数据，只是浏览器在使用缓存数据时，需要先确认一下数据是否还跟服务器保持一致。

• no-store

所有内容都不会被缓存，即不使用强制缓存，也不使用协商缓存

• max-age

max-age=xxx (xxx is numeric)表示缓存内容将在xxx秒后失效

• s-maxage（单位为s)

同max-age作用一样，只在代理服务器中生效（比如CDN缓存）。比如当s-maxage=60时，在这60秒中，即使更新了CDN的内容，浏览器也不会进行请求。max-age用于普通缓存，而s-maxage用于代理缓存。s-maxage的优先级高于max-age。如果存在s-maxage，则会覆盖掉max-age和Expires header。

max-stale：能容忍的最大过期时间。max-stale指令标示了客户端愿意接收一个已经过期了的响应。如果指定了max-stale的值，则最大容忍时间为对应的秒数。如果没有指定，那么说明浏览器愿意接收任何age的响应（age表示响应由源站生成或确认的时间与当前时间的差值）。

min-fresh：能够容忍的最小新鲜度。min-fresh标示了客户端不愿意接受新鲜度不多于当前的age加上min-fresh设定的时间之和的响应。

可以将多个指令配合起来一起使用，达到多个目的。比如说希望资源能被缓存下来，并且是客户端和代理服务器都能缓存，还能设置缓存失效时间等等。

Last-Modify/If-Modify-Since

浏览器第一次请求一个资源的时候，服务器返回的header中会加上Last-Modify，Last-modify是一个时间标识该资源的最后修改时间，例如Last-Modify: Thu,31 Dec 2037 23:59:59 GMT。

当浏览器再次请求该资源时，发送的请求头中会包含If-Modify-Since，该值为缓存之前返回的Last-Modify。服务器收到If-Modify-Since后，根据资源的最后修改时间判断是否命中缓存。

如果命中缓存，则返回http304，并且不会返回资源内容，并且不会返回Last-Modify。

由于对比的服务端时间，所以客户端与服务端时间差距不会导致问题。

但是有时候通过最后修改时间来判断资源是否修改还是不太准确（资源变化了最后修改时间也可以一致。于是出现了ETag/If-None-Match。

ETag/If-None-Match

与Last-Modify/If-Modify-Since不同的是，Etag/If-None-Match返回的是一个校验码（ETag: entity tag）。

ETag可以保证每一个资源是唯一的，资源变化都会导致ETag变化。

ETag值的变更则说明资源状态已经被修改。服务器根据浏览器上发送的If-None-Match值来判断是否命中缓存。

Last-Modified和Etag比较

使用Last-Modified已经足以让浏览器知道本地的缓存副本是否足够新，为什么还需要Etag（实体标识）呢？HTTP1.1中Etag的出现主要是为了解决几个Last-Modified比较难解决的问题：

• Last-Modified标注的最后修改只能精确到秒级，如果某些文件在1秒钟以内，被修改多次的话，它将不能准确标注文件的修改时间

• 如果某些文件会被定期生成，当有时内容并没有任何变化，但Last-Modified却改变了，导致文件没法使用缓存

• 有可能存在服务器没有准确获取文件修改时间，或者与代理服务器时间不一致等情形

Etag是服务器自动生成或者由开发者生成的对应资源在服务器端的唯一标识符，能够更加准确的控制缓存。

Last-Modified与ETag是可以一起使用的，服务器会优先验证ETag，一致的情况下，才会继续比对Last-Modified，最后才决定是否返回304。

用户行为对浏览器缓存的影响

用户行为对浏览器缓存的影响，指的就是用户在浏览器如何操作时，会触发怎样的缓存策略。主要有 3 种：

• 打开网页，地址栏输入地址： 查找 disk cache 中是否有匹配。如有则使用；如没有则发送网络请求。
• 普通刷新 (F5)：因为 TAB 并没有关闭，因此 memory cache 是可用的，会被优先使用(如果匹配的话)。其次才是 disk cache。
• 强制刷新 (Ctrl + F5)：浏览器不使用缓存，因此发送的请求头部均带有 Cache-control: no-cache(为了兼容，还带了 Pragma: no-cache),服务器直接返回 200 和最新内容。

用户操作	Expires/Cache-Control	Last-Modified/Etag
地址栏回车	有效	有效
页面链接跳转	有效	有效
新开窗口	有效	有效
前进、后退	有效	有效
F5刷新	无效	有效
Ctrl+F5刷新	无效	无效

实际场景应用缓存策略

频繁变动的资源

Cache-Control: no-cache

对于频繁变动的资源，首先需要使用Cache-Control: no-cache 使浏览器每次都请求服务器，然后配合 ETag 或者 Last-Modified 来验证资源是否有效。

这样的做法虽然不能节省请求数量，但是能显著减少响应数据大小。

不常变化的资源

Cache-Control: max-age=31536000

通常在处理这类资源时，可以给它们的 Cache-Control 配置一个很大的 max-age=31536000 (一年)。

这样浏览器之后请求相同的 URL 会命中强制缓存。

而为了解决更新的问题，就需要在文件名(或者路径)中添加 hash， 版本号等动态字符，之后更改动态字符，从而达到更改引用 URL 的目的，让之前的强制缓存失效 (其实并未立即失效，只是不再使用了而已)。

在线提供的类库 (如 jquery-3.4.1.min.js, lodash.min.js 等) 均采用这个模式。