浏览器缓存原理
本文可以配合本人录制的视频一起食用
目的
通常说到浏览器缓存,大多是和性能优化有关,使用缓存,通常是两个主要目的,第一是提高访问速度,第二是减少网络IO消耗。
当合理配置了缓存,可以得到提升用户体验、减轻服务器负担、节省带宽等效果,这是一种效果显著的前端性能优化手段。
四个方面
浏览器缓存机制涉及四个方面,按照获取资源时请求的优先级排序如下:
- Memory Cache
- Service Worker Cache
- HTTP Cache
- Push Cache
其中最后一个Push Cache是HTTP2的新特性
缓存策略
通常我们面试时说的浏览器缓存原理,指的是缓存策略。
缓存策略分为两类:强缓存和协商缓存,通过设置HTTP HEADER来实现。
强缓存
强缓存优先级较高,在命中强缓存失败的情况下,才会走协商缓存。
当我们发起请求,去请求一个资源时,浏览器会去读取HTTP Header中的expires或Cache-control,来判断目标资源是否命中强缓存。
使用expires还是Cache-control和我们的HTTP协议版本有关,当使用1.0版本就根据expires进行判断,当使用1.1就根据Cache-control进行判断。
如果命中了强缓存,就直接从缓存中获取资源,不与服务端发生通信。此时返回的HTTP状态码为200,但会有from memory cache的标识。
【判断资源是否过期
那浏览器是如何根据expires和Cache-control进行判断的呢?
首先看expires,expires是一个时间戳,指的是资源过期时间,当我们试图再次从服务器请求同一份资源时,浏览器就会先对比本地时间和expires的值,如果本地时间小于expires设置的过期时间,就直接从缓存中获取资源。
因为expires的使用依赖于本地时间,这就会存在问题,不同的本地时间会使缓存的失效时间无法保证,也就是服务端和客户端会存在时差。
因此HTTP 1.1增加了Cache-control作为expires的完全替代方案,现在依然使用expires的唯一目的是为了向下兼容。两者同时使用时,Cache-control的优先级更高。
在Cache-control中我们可以设置max-age来控制资源的有效期,这是一个时间长度,规避了时间戳带来的问题,客户端会记录请求到资源的时间点,以此作为相对时间的起点,确保参与计算的两个时间节点都来源于客户端。
协商缓存
如果强缓存命中失败,浏览器就需要向服务器去询问缓存的相关信息,进而判断是重新请求、下载完整的响应,还是从本地中获取缓存的资源,此时就进入了协商缓存的阶段。
如果我们不想直接使用本地缓存,也可以设置Cache-Control: no-cache
直接进入协商缓存的阶段。
协商缓存,从字面上可以理解为:根据客户端和服务器的协商结果,来判断是否使用本地缓存。
如果服务端提示缓存资源未改动(Not Modified),资源会被重定向到浏览器缓存,这种情况下网络请求对应的状态码是304。
【判断资源有效性
那么服务器是如何去判断资源是否变动呢?
有两种判断方式:Last-Modified和Etag
首先看Last-Modified,它是一个时间戳,如果启用了协商缓存,它会在请求时随着response headers返回。
Last-Modified:
之后我们每次请求时,请求头request headers中就会带上一个时间戳字段,叫If-Modified-Since,它的值就是之前response返回的Last-Modified的值。字面上的意思就是在告诉服务器:在这个时间之后,资源如果发生变化,就要返回新的资源
服务器接收到这个字段后,就会与该资源在服务器上的最后修改时间进行比对,两者是否一致,从而判断资源是否发生变化。
-
如果发生变化
会返回一个完整的响应。并在响应头response headers中返回新的Last-Modified的值
-
如果没有发生变化
就会返回一个状态码为304的响应,提示浏览器使用本地缓存
Last-Modified和If-Modified-Since配合使用,看上去没什么问题,但实际存在一些弊端,比如:
-
编辑了文件,但文件内容实际没有变化的情况
我可能修改了一个文件,然后又撤销了修改,虽然文件内容没变,但资源的最后修改时间被更新了。
导致需要重新将资源返回给客户端,无法充分利用缓存
-
第二种情况,修改文件的速度过快,导致客户端使用了过期缓存
因为If-Modified-Since只能检查以秒为最小计量单位的时间差,如果在不可感知的时间内修改了资源,就会使客户端使用过期的资源
为了弥补Last-Modified的不足,就出现了Etag
Etag是服务器为每个资源生成的唯一标识字符串,基于文件内容编码,能够精准感知文件内容变化
首次请求时,客户端会在response headers获得一个标识字符串,类似:
Etag: "dec8d6f46497a9c6b4dff4e237cabe5d"
再次请求时,请求头request headers里会带上一个与Etag值相同的、名为If-None-Match的字段,字面上的意思就是在请求时告诉服务器:资源的Etag如果不一致,就要返回新的资源
If-None-Match的值就是供服务器进行比对:
If-None-Match: "dec8d6f46497a9c6b4dff4e237cabe5d"
Etag很好的弥补了Last-Modified的短板,但是也存在弊端,因为生成Etag需要服务器付出额外的开销,这会影响服务器的性能,这是启用Etag时需要考虑到的问题。
当Etag和Last-Modified同时存在时,Etag的优先级更高,因为它在感知文件变化上比Last-Modified更准确
如何配置?
了解了缓存策略,那在面对一个具体的缓存需求时,我们该如何配置呢?
网上这一张应该挺多人看到过的图,我也直接拿过来用,就是根据你项目的需求进行判断
-
考虑这个资源是否是可复用的,也就是是否使用缓存
-
如果是No,也就是不可复用,就设置no-store,拒绝一切形式的缓存,包括客户端和服务器的缓存
Cache-Control: no-store
-
如果是可复用资源
-
并且需要每次都进行资源有效性验证,就设置no-cache,会跳过强缓存判断,直接进入协商缓存阶段,向服务器进行资源有效性验证
Cache-Control: no-cache
-
考虑是否可被代理服务器缓存
- 如果只能被浏览器缓存,就设置为private,这也是默认值
Cache-Control: private
- 如果即可被浏览器缓存,也能被代理服务器缓存,就设置为pulic
Cache-Control: public
-
继续我们可以考虑设置缓存有效时间,以保证缓存的有效性
- 设置代理服务器缓存的有效时间,使用s-maxage,单位为秒
Cache-Control: public s-maxage=30
- 设置浏览器缓存的有效时间,使用max-age,单位也为秒
Cache-Control: max-age=30
s-maxage优先级高于max-age,如果s-maxage未过期,则向代理服务器请求其缓存内容,只针对public缓存有效。
-
最后设置协商缓存需要用到的ETag、Last-Modified等参数
-
-
这个图大概就是这么一个流程。
实操
以上大多都是我查到的一些资料,接下来做一些简单的配置,以科学的精神验证一部分内容。
下面的测试在nginx和Chrome中进行。
当不做配置时
location /cache-demo {
root html;
index index.html;
}
-
第一次访问页面
// 响应码 200 Status Code: 200 OK // 响应头里加上了Last-Modified和Etag Last-Modified: Thu, 27 Jul 2023 02:47:55 GMT ETag: "64c1dadb-e3" // 第一次请求头里没有`If-Modified-Since`和`If-None-Match`
-
再次请求,status变成了304,说明资源内容没有更改
// 响应码304 Status Code: 304 Not Modified // 响应头里Last-Modified和Etag和之前一次是一样的 Last-Modified: Thu, 27 Jul 2023 02:47:55 GMT ETag: "64c1dadb-e3" // 这一次请求头里带上了`If-Modified-Since`和`If-None-Match` If-Modified-Since: Thu, 27 Jul 2023 02:47:55 GMT If-None-Match: "64c1dadb-e3"
-
此时我们去修改资源内容,再去重新访问,响应码重新变成了200
// 响应 HTTP/1.1 200 OK Last-Modified: Thu, 27 Jul 2023 03:50:18 GMT ETag: "64c1e97a-e3" // 请求头 If-Modified-Since: Thu, 27 Jul 2023 02:47:55 GMT If-None-Match: "64c1dadb-e3"
可以看到响应头中的Etag和请求头中的If-None-Match不一致,Last-Modified和If-Modified-Since也不一致了,所以就返回了新的资源内容
配置no-store
接下来先做第一种配置,Cache-Control设置为no-store
add_header 'Cache-Control' 'no-store';
-
第一次访问
// 响应 HTTP/1.1 200 OK Last-Modified: Thu, 27 Jul 2023 03:50:18 GMT ETag: "64c1e97a-e3" // 在响应头中看到了no-store的配置 Cache-Control: no-store // 请求头里没有`If-Modified-Since`和`If-None-Match`
-
再次请求,可以看到status还是200,说明从服务器重新获取资源内容了
// 响应 HTTP/1.1 200 OK Last-Modified: Thu, 27 Jul 2023 03:50:18 GMT ETag: "64c1e97a-e3" Cache-Control: no-store // 请求 // 请求头里没有`If-Modified-Since`和`If-None-Match`,只有Cache-Control:max-age=0 Cache-Control: max-age=0
-
再请求几次结果也是一样的
配置max-age
修改配置max-age=240,也就是4分钟内如果命中缓存,就使用缓存
add_header 'Cache-Control' 'max-age=240';
-
第一次请求资源
// 响应头 HTTP/1.1 200 OK Last-Modified: Thu, 27 Jul 2023 04:13:31 GMT ETag: "64c1eeeb-e3" Cache-Control: max-age=240 // 请求 // 请求头里没有`If-Modified-Since`和`If-None-Match`
-
四分钟内再次请求,status是304
// 响应头 HTTP/1.1 304 Not Modified Last-Modified: Thu, 27 Jul 2023 04:13:31 GMT ETag: "64c1eeeb-e3" Cache-Control: max-age=240 // 请求头 Cache-Control: max-age=0 If-Modified-Since: Thu, 27 Jul 2023 04:13:31 GMT If-None-Match: "64c1eeeb-e3"
似乎没有直接使用本地缓存,默认的请求头的max-age=0,表示不使用强缓存,但允许协商缓存,所以返回响应码是304
使用Chrome插件ModHeader来修改请求头
Cache-Control: max-age=240
,还是304?怀疑是缓存不够用,因为理论上而言,应该使用本地缓存 -
HTML增加外部脚本的引用,请求脚本时可以命中缓存
试了几次修改HTML,还是不行,给HTML增加外部的js脚本,发现脚本可以被缓存,显示了from memory cache。可能是浏览器默认的策略,请求页面的时候默认为
no-cache
直接进入协商缓存阶段;请求其他类型资源的时候才会优先去匹配本地缓存。Request URL: http://localhost:8080/cache-demo/main.js Status Code: 200 OK (from memory cache)
此时设置
max-age=240
,发现脚本没有按照我们预期设置的max-age过期而重新获取新的资源,这应该是Chrome本身对资源加载的一个优化,以达到充分利用本地缓存的目的,这也解释了有些情况下,前端代码重新部署后,无法加载到最新内容的原因,一来HTML内容没有更改,所以默认的协商缓存返回304,读取了本地资源;二来HTML引用的js脚本也在本地可以找到缓存,就没有向浏览器发起请求。最终导致读取到的是旧的资源内容,需要等待几分钟才能读取到新的内容。为了解决这个问题,可以在nginx配置显式的声明
no-cache
:add_header 'Cache-Control' 'no-cache, max-age=240';
这样请求js脚本就会直接进入协商缓存,读取到新的资源内容。
结论
根据这个测试结果,为了保证内容的时效性,建议给资源所在服务器增加no-cache
的配置,并且给HTML页面所在服务器增加no-store
的配置,因为大多Vue或者react单页应用打包构建出来的HTML页面内容很少,往往只有一个div,配置了no-store
可以保证请求到最新的资源,因为页面内容极少,正常情况下资源返回也非常快。
本文来自博客园,作者:beckyye,转载请注明原文链接:https://www.cnblogs.com/beckyyyy/p/17589724.html