【HTTP缓存】浏览器缓存理论知识

时间:2024-01-15 11:48:02

时间:2016-12-12 17:51:30

作者: zhongxia

零、前言

这里主要写的是理论,具体实践的比较少,后期写一个实践教程,内容基本都是从参考文章里面抄过来的【看完文章,顺便写做下笔记,加深理解。】

浏览器缓存,也就是客户端缓存,既是网页性能优化里面静态资源相关优化的一大利器,也是无数web开发人员在工作过程不可避免的一大问题,所以在产品开发的时候我们总是想办法避免缓存产生,而在产品发布之时又在想策略管理缓存提升网页的访问速度。

了解浏览器的缓存命中原理,是开发web应用的基础,本文着眼于此,学习浏览器缓存的相关知识,总结缓存避免和缓存管理的方法,结合具体的场景说明缓存的相关问题。希望能对有需要的人有所帮助。

一、浏览器缓存基本认识

1. 强缓存 和 协商缓存

浏览器在加载资源的时,先根据 http header 判断它是否命中强缓存.

  • 命中强缓存:浏览器直接从自己缓存中读取资源,不发送请求到服务器

  • 不命中强缓存:浏览器发送一个请求到服务器,服务器根据资源的另外一些 http header 验证 该资源 是否命中 协商缓存

    • 命中协商缓存:将请求返回,但不是返回该资源的数据,而是告诉浏览器可以直接从缓存中加载这个资源。

    • 不命中协商缓存:服务器返回该资源数据

2. 异同点 和 关系

共同点:命中,都是从浏览器缓存中加载资源

不同点:强缓存不发送请求到服务器,协商缓存会发送请求。

必须开启强缓存,协商缓存才会起作用

二、强缓存原理

什么是协商缓存?

如图,返回http状态为200,size为 form cache 的就是强缓存

【HTTP缓存】浏览器缓存理论知识

1. HTTP Response Header 看强缓存

Expires

HTTP1.0 时代,Expires 【表示资源过期时间】【缓存过期的下一个时间 必须GMT 格式】

可能存在问题:服务器时间和客户端时间不一致,因此 HTTP1.1 出了一些 Cache-control

如图:

【HTTP缓存】浏览器缓存理论知识

Cache-control

HTTP1.1 时代,Cache-control: 过期时间【缓存多少毫秒】

如图:

【HTTP缓存】浏览器缓存理论知识

例子:

Expires步骤

  1. 浏览器第一次请求资源,服务器在返回的同时,会在 response 的 header 上加上 Expires

  2. 浏览器收到资源后,把资源和 Expires 一起缓存下来

  3. 第二次请求资源时,拿出Expires和当前请求时间比较下,如果还未过期,则直接从缓存中读取出来,【这个就叫命中缓存

  4. 没有命中的话,去服务端请求,走协商缓存道路,最后返回时,会返回一个新的 Expires , 浏览器在缓存下来。

Cache-control 步骤

和 Expires一样,只是 过期时间=当前时间+Cache-control 的 Max-age 缓存毫秒数

Cache-control 和 Expires

  1. 这两个可以一起用,也可以只用其中一个 【一起用,优先级: Cache-Control > Expires
  2. Expires 是比较老的强缓存管理Header,因为它是绝对时间,而服务器时间和客户端时间相差大,或者修改客户端时间,就会影响缓存命中率
  3. Cache-control 是相对时间,受到的影响小一些

如何设置强缓存?

1. 代码形式

通过代码的形式,在web服务器的返回响应 header 中添加 Expies, Cache-control

java.util.Date date = new java.util.Date();
response.setDateHeader("Expires",date.getTime()+20000); //Expires:过时期限值
response.setHeader("Cache-Control", "public"); //Cache-Control来控制页面的缓存与否,public:浏览器和缓存服务器都可以缓存页面信息;
response.setHeader("Pragma", "Pragma"); //Pragma:设置页面是否缓存,为Pragma则缓存,no-cache则不缓存

设置不缓存

response.setHeader( "Pragma", "no-cache" );
response.setDateHeader("Expires", 0);
response.addHeader( "Cache-Control", "no-cache" );//浏览器和缓存服务器都不应该缓存页面信息

2. web服务器配置

让web服务器在响应资源的时候统一添加Expires和Cache-Control Header

nginx和apache作为专业的web服务器,都有专门的配置文件,可以配置expires和cache-control,这方面的知识,如果你对运维感兴趣的话,可以在百度上搜索“nginx 设置 expires cache-control”或“apache 设置 expires cache-control”都能找到不少相关的文章。

3. 强缓存的应用

  1. 强缓存是前端性能优化最有力的工具,没有之一。

  2. 大量的静态资源网站,一定要利用强缓存,提高响应速度

  3. 例子,京东页面,强缓存到2026年。【这个强缓存可以有】

  4. 使用强缓存后,如何更新网站呢?

给文件加上 hash 值。

知乎上的完美解决方案

https://www.zhihu.com/question/20790576

  1. 注意点【强缓存针对静态资源,动态资源不要,html资源不要。】

强缓存还有一点需要注意的是,通常都是针对静态资源使用,动态资源需要慎用,除了服务端页面可以看作动态资源外,那些引用静态资源的html也可以看作是动态资源,如果这种html也被缓存,当这些html更新之后,可能就没有机制能够通知浏览器这些html有更新,尤其是前后端分离的应用里,页面都是纯html页面,每个访问地址可能都是直接访问html页面,这些页面通常不加强缓存,以保证浏览器访问这些页面时始终请求服务器最新的资源

三、协商缓存

1. 什么是协商缓存?

如图:返回http状态304,Not Modified

【HTTP缓存】浏览器缓存理论知识

说白了就是浏览器自己不确定,没有办法决定,因此要找 服务器商量下。 服务器说可以,那浏览器就直接从自己缓存里面找出资源, 服务器说你这个不行啊,过期了。 我给你个新的,浏览器就拿新的咯。

协商缓存要发请求,所有header都是 response 和 request 一人一个。

2. 协商缓存如何控制?

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

Response Header : Last-Modified, ETag

Request Header : If-Modified-Since , If-None-Match

3. 【Last-Modified,If-Modified-Since】缓存管理方式

  1. 第一次跟web服务器请求资源时,在 response 的 header 加上 Last-Modified【文件最后修改时间】

  2. 浏览器收到资源的时候,把资源文件和 Last-Modified 缓存起来

  3. 再次请求的时候, 在 Request Header 加上 If-Modified-Since 的 header, 这个值,就是 第一次web服务器返回的 Last-Modified。

  4. web服务器收到之后,判断 Last-Modified-Since 和 Last-Modified 是否一致,一致则返回 304 Not Modified. 让浏览器去加载缓存里面的。

  5. 不一致的话,返回资源,并返回一个新的 Last-Modified

  6. 浏览器继续缓存下来, 然后继续上面的步骤。

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

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

所有的步骤都是差不多的

  1. 发送请求,返回资源的时候,也返回了一个 ETag【文件的Hash值】

  2. 浏览器缓存资源,并缓存下 ETag

  3. 再次请求的时候,Request Header If-None-Match 把上次传过来的 ETag 传过去

  4. web服务器,在生成一个资源文件的 ETag, 然后跟传过来的比较

  5. 一样,返回 304 Not-Modified,浏览器从缓存拿

  6. 不一样, web服务器返回资源,并返回一个新的 ETag, 然后重复上面操作。

强缓存 和 协商缓存的 缓存管理都是一样的步骤哈。

5. 注意ETag的使用

  1. 在分布式部署的时候,多台机器的 Last-Modified 必须保持一致,否则协商缓存会出问题。

  2. 分布式部署,不同的机器生成的 ETag 都会不一样。 然后协商缓存就会出问题。【因此如果没有搞定ETag 一致,就先关闭掉。】

  3. 协商缓存 需要 配合 强缓存使用 【不启动强缓存,协商缓存也就不起作用】

    response header 包含了强缓存的管理 header

    【HTTP缓存】浏览器缓存理论知识

四、浏览器行为对缓存的影响

如果资源已经被浏览器缓存下来,在缓存失效之前,再次请求时,默认会先检查是否命中强缓存,如果强缓存命中则直接读取缓存,如果强缓存没有命中则发请求到服务器检查是否命中协商缓存,如果协商缓存命中,则告诉浏览器还是可以从缓存读取,否则才从服务器返回最新的资源。这是默认的处理方式,这个方式可能被浏览器的行为改变:

  1. 当ctrl+f5强制刷新网页时,直接从服务器加载,跳过强缓存和协商缓存;
  2. 当f5刷新网页时,跳过强缓存,但是会检查协商缓存;

五、注意点

勾选这个 disable cache 缓存, 则不会使用缓存

【HTTP缓存】浏览器缓存理论知识

参考文章

  1. 《浏览器缓存知识小结及应用》
  2. 《HTTP缓存》
  3. 《浏览器 HTTP 协议缓存机制详解》