浏览器缓存原理

本文可以配合本人录制的视频一起食用

目的

通常说到浏览器缓存,大多是和性能优化有关,使用缓存,通常是两个主要目的,第一是提高访问速度,第二是减少网络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可以保证请求到最新的资源,因为页面内容极少,正常情况下资源返回也非常快。

热门相关:我的治愈系游戏   愈合伴侣   上神来了   美人图   修真界败类