理解浏览器的缓存机制

理解浏览器的缓存机制

缓存是性能优化中简单高效的一种优化方式,一个优秀的缓存策略可以缩短网页请求资源的距离,减少延迟。并且由于缓存文件可以重复利用,还可以减少带宽,降低网络负荷。

对于一个数据请求来说,可以分为发起三个步骤:

  • 网络请求

  • 后端处理

  • 浏览器响应

浏览器缓存可以帮助我们在第一和第三步骤中优化性能。

比如说直接使用缓存而不发起请求,或者发起了请求但后端存储的数据和前端一致,那么就没有必要再将数据回传回来,这样就减少了响应数据。本博文将通过缓存位置、缓存策略以及实际场景应用缓存策略来总结一下浏览器缓存机制。

思维导图

浏览器缓存机制

缓存位置

从缓存位置上来分类可以分成 4 种,并且各自有其优先级,当我们挨个查找缓存发现都没命中🎯时才会发起请求

  • Service Worker
  • Memory Cache
  • Disk Cache
  • Push Cache

1. Service Worker

service worker 是运行在浏览器背后的独立工作线程,一般可以用来实现缓存功能。使用 Service Worker 的话,传输协议必须为 HTTPS !因为 Service Worker 中涉及到请求拦截,所以必须使用 HTTPS 协议来保证安全。

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

要想实现分三步:

  1. 首先需要注册 Service Worker
  2. 然后监听到 install 事件以后就可以缓存需要的文件
  3. 在下次用户访问的时候就可以通过拦截请求的方式查询是否存在相应缓存。

一个有意思的是:

当 Service Worker 没有命中缓存的时候,会根据缓存查找的优先级去查找数据。

但是不管我们是从 Memory Cache 中还是从网络请求中获取的数据,浏览器都会显示我们是从 Service Worker 中获取的内容。

2. Memory Cache

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

然而计算机中的内存一定比硬盘容量小得多,内存的使用需要精打细算,所以能让我们使用必然不多。

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

内存缓存

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 头中的缓存指令。由于在国内 HTTP/2 还不算非常普及,这一部分的知识还需要更多谷歌了解 😂

缓存过程

浏览器与服务器通信的方式为:浏览器发起 HTTP 请求 – 服务器响应该请求,浏览器怎么确定一个资源该不该缓存,如何去缓存呢

浏览器第一次向服务器发起该请求后拿到请求结果后,将请求结果和缓存标识存入浏览器缓存,浏览器对于缓存的处理是根据第一次请求资源时返回的响应头来确定的。具体过程如下图:

缓存何时村

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

我们根据 是否需要向服务器重新发起 HTTP 请求 ,将缓存过程分为两个部分,分别是 强缓存协商缓存

强缓存

不会向服务器发送请求,直接从缓存中读取资源。

在 Chrome 控制台的 Network 选项中可以看到该请求返回 200 的状态码,并且 Size 显示 from disk cachefrom memory cache

强缓存可以通过设置两种 HTTP Header 实现:ExpiresCache-Control:

Expires

缓存过期时间,用来指定资源到期的时间,是服务器端的具体的时间点

也就是说,Expires=max-age + 请求时间,需要和 Last-modified 结合使用。Expires 是 Web 服务器响应消息头字段,在响应 HTTP 请求时告诉浏览器在过期时间前浏览器可以直接从浏览器缓存取数据,而无需再次请求。

Expires 是 HTTP/1 的产物,受限于本地时间,如果修改了本地时间,可能会造成缓存失效Expires: Wed, 22 Oct 2018 08:41:00 GMT表示资源会在 Wed, 22 Oct 2018 08:41:00 GMT 后过期,需要再次请求。

Cache-Control

浏览器缓存里, Cache-Control 是金字塔顶尖的规则,它藐视一切其他设置,只要其他设置与其抵触,一律覆盖之。不仅如此, 它还是一个复合规则,包含多种值,横跨 存储策略, 过期策略 两种,同时在请求头和响应头都可设置。

语法为: Cache-Control: cache-directive.

Cache-directive 共有如下 12 种,其中请求中指令 7 种,响应中指令 9种:

Cache-directive描述存储策略过期策略请求字段响应字段
public资源将被客户端和代理服务器缓存✔️ ✔️
private资源仅被客户端缓存, 代理服务器不缓存✔️ ✔️
no-store请求和响应都不缓存✔️ ✔️✔️
no-cache相当于max-age:0,must-revalidate即资源被缓存, 但是缓存立刻过期, 同时下次访问时强制验证资源有效性✔️✔️✔️✔️
max-age缓存资源, 但是在指定时间(单位为秒)后缓存过期✔️✔️✔️✔️
s-maxage同上, 依赖public设置, 覆盖max-age, 且只在代理服务器上有效.✔️✔️ ✔️
max-stale指定时间内, 即使缓存过时, 资源依然有效 ✔️✔️
min-fresh缓存的资源至少要保持指定时间的新鲜期 ✔️✔️
must-revalidation / proxy-revalidation如果缓存失效, 强制重新向服务器(或代理)发起验证(因为max-stale等字段可能改变缓存的失效时间) ✔️ ✔️
only-if-cached仅仅返回已经缓存的资源, 不访问网络, 若无缓存则返回504 ✔️
no-transform强制要求代理服务器不要对资源进行转换, 禁止代理服务器对 Content-Encoding, Content-Range, Content-Type字段的修改(因此代理的gzip压缩将不被允许) ✔️✔️

假设所请求资源于 5 月 5 日缓存,且在 5 月 12 日过期。当 max-agemax-stalemin-fresh 同时使用时,它们的设置相互之间独立生效,最为保守的缓存策略总是有效。

这意味着, 如果 max-age=10 days, max-stale=2 days, min-fresh=3 days

那么由于 客户端总是采用最保守的缓存策略 ,因此, 5 月 9 日后, 对于该资源的请求将重新向服务器发起验证。

  • 根据 max-age 的设置, 覆盖原缓存周期, 缓存资源将在 5 月 15 日失效 (5+10=15)

  • 根据 max-stale 的设置,缓存过期后两天依然有效,此时响应将返回 110(Response is stale) 状态码, 缓存资源将在 5 月 14 日失效 (12+2=14)

  • 根据 min-fresh 的设置, 至少要留有 3 天的新鲜期, 缓存资源将在 5月9日失效 (12-3=9)

    min-fresh 的过程可以这样来看:

    min-fresh

    从图中我们可以看到,我们可以将多个指令配合起来一起使用,达到多个目的:比如说我们希望客户端和代理服务器都能缓存,还能设置缓存失效时间等等。

Expires 和 Cache-Control 两者对比

其实这两者差别不大,区别就在于 Expires 是http1.0的产物,Cache-Control是http1.1的产物,两者同时存在的话,Cache-Control优先级高于Expires;在某些不支持HTTP1.1的环境下,Expires就会发挥用处。所以Expires其实是过时的产物,现阶段它的存在只是一种兼容性的写法。
强缓存判断是否缓存的依据来自于是否超出某个时间或者某个时间段,而不关心服务器端文件是否已经更新,这可能会导致加载文件不是服务器端最新的内容,那我们如何获知服务器端内容是否已经发生了更新呢?此时我们需要用到协商缓存策略。

协商缓存

强制缓存失效后,浏览器携带缓存标识向服务器发起请求,由服务器根据缓存标识决定是否使用缓存的过程。

主要有以下两种情况:

  1. 协商缓存生效,返回 304 Not Modified

    协商缓存机制

  2. 协商缓存失效,返回 200 和请求结果,然后将请求结果和缓存标示存入浏览器缓存中

协商缓存可以通过设置两种 HTTP Header 实现:Last-ModifiedETag

Last-Modified 与 If-Modified-Since

语法: Last-Modified: 星期,日期 月份 年份 时:分:秒 GMT

Last-Modified: Tue, 04 Apr 2017 10:01:15 GMT

用于标记请求资源的最后一次修改时间,格式为 GMT(格林尼治标准时间) 。 如可用 new Date().toGMTString()获取当前 GMT 时间。 Last-ModifiedETagfallback 机制,优先级比 ETag 低,且只能精确到秒。

If-Modified-Since: Tue, 04 Apr 2017 10:12:27 GMT

If-Modified-Since是一个缓存校验字段,语法同上,其值为上次响应头的 Last-Modified 值,若与请求资源当前的 Last-Modified 值相同,那么将返回 304 状态码的响应,反之,将返回 200 状态码响应。

但是 Last-Modified 存在一些弊端:

  • 如果本地打开缓存文件,即使没有对文件进行修改,但还是会造成 Last-Modified 被修改,服务端不能命中缓存导致发送相同的资源。
  • 不太适合短时间内频繁改动的资源,比如有些服务端的静态资源通常需要编译打包,也可能出现资源内容没有改变,而 Last-Modified 却改变的情况。
  • 因为 Last-Modified 只能以秒计时,如果在不可感知的时间内修改完成文件,那么服务端会认为资源还是命中了,不会返回正确的资源

另外还有 If-Unmodified-Since

也是一个缓存校验字段,表示资源未修改则正常执行更新,否则返回 412 Precondition Failed 状态码的响应. 常用于如下两种场景:

  • 有一定事务性的请求, 比如说使用 POST 请求更新 wiki 文档, 文档未修改时才执行更新。
  • If-Range 字段同时使用时, 可以用来保证新的片段请求来自一个未修改的文档.

既然根据文件修改时间来决定是否缓存尚有不足,能否可以直接根据文件内容是否修改来决定缓存策略?所以在 HTTP / 1.1 出现了 ETagIf-None-Match

ETag 和 If-None-Match

ETag 是服务器响应请求时,返回当前资源文件的一个唯一标识(由服务器生成),只要资源有变化,ETag 就会重新生成

浏览器在下一次加载资源向服务器发送请求时,会将上一次返回的 ETag 值放到 Request Header 里的 If-None-Match 里,服务器只需要比较客户端传来的 If-None-Match 跟自己服务器上该资源的 ETag 是否一致,就能很好地判断资源相对客户端而言是否被修改过了。

  • 如果服务器发现 ETag 匹配不上,那么直接以常规 GET 200 回包形式将新的资源(当然也包括了新的 ETag )发给客户端;

  • 如果 ETag 是一致的,则直接返回 304 知会客户端直接使用本地缓存即可。

Last-Modified 与 ETag 的对比

  • 首先在精确度上,ETag 要优于 Last-Modified

    Last-Modified 的时间单位是 ,如果某个文件在 1 秒内改变了多次,那么他们的 Last-Modified 其实并没有体现出来修改,但是 ETag 每次都会改变确保了精度;

    如果是负载均衡的服务器,各个服务器生成的 Last-Modified 也有可能不一致。

  • 第二在性能上,ETag 要逊于 Last-Modified,毕竟 Last-Modified 只需要记录时间,而 ETag 需要服务器通过算法来计算出一个 hash 值。

  • 第三在优先级上,服务器校验优先考虑 ETag

缓存机制

  1. 强制缓存优先于协商缓存进行。
  2. 若强制缓存 ExpiresCache-Control 生效则直接使用缓存。
  3. 若不生效则进行协商缓存 Last-Modified / If-Modified-SinceETag / If-None-Match,协商缓存由服务器决定是否使用缓存
    • 若协商缓存失效,那么重新请求,返回 200,将返回的资源和缓存标示重新存入浏览器缓存中;
    • 生效则返回 304,继续使用缓存。具体流程图如下;

缓存机制

流程图来自:路易斯来源:掘金,此图著作权归原作者所有。

References

  1. 浏览器缓存机制剖析

  2. 彻底理解浏览器的缓存机制

  3. 前端面试之道

评论

Your browser is out-of-date!

Update your browser to view this website correctly. Update my browser now

×