为了账号安全,请及时绑定邮箱和手机立即绑定

有关 HTTP 缓存的首部字段说一下

常见的HTTP 缓存首部字段有:

  • Expires:响应头,代表该资源的过期时间

  • Cache-Control:请求/响应头,缓存控制字段,精确控制缓存策略

  • If-Modified-Since:请求头,资源最近修改时间,由浏览器告诉服务器

  • Last-Modified:响应头,资源最近修改时间,由服务器告诉浏览器

  • Etag:响应头,资源标识,由服务器告诉浏览器

  • If-None-Match:请求头,缓存资源标识,由浏览器告诉服务器

其中, 强缓存

  • Expires(HTTP/1.0)
  • Cache-Control(HTTP/1.1)

协商缓存:

  • Last-Modified 和 If-Modified-Since(HTTP/1.0)
  • ETag 和 If-None-Match(HTTP/1.1)

缓存过程分析

浏览器与服务器通信的方式为应答模式,即浏览器发起 HTTP 请求,服务器响应请求。在浏览器第一次发起请求时,会根据响应报文中 HTTP 头的缓存标识,决定是否缓存结果,如果是则将请求结果和缓存标识存入浏览器缓存中,简单的过程如下图:

由上图我们可以知道:

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

以上两点结论就是浏览器缓存机制的关键,它确保了每个请求的缓存存入与读取,只要我们再理解浏览器缓存的使用规则,那么所有的问题就迎刃而解了

本文也将围绕着这点进行详细分析。为了方便大家理解,这里我们根据是否需要向服务器重新发起HTTP请求将缓存过程分为两个部分,分别是:

  • 强缓存: 向浏览器缓存查找该请求结果,并根据该结果的缓存规则来决定是否使用该缓存结果的过程
  • 协商缓存: 强缓存失效后,浏览器携带缓存标识向服务器发起请求,由服务器根据缓存标识决定是否使用缓存的过程

强缓存(缓存控制)

强缓存表示在缓存期间是否使用缓存(缓存是否有效),需不需要重新发送HTTP请求

控制强缓存的字段分别是 ExpiresCache-Control ,其中 Cache-Control 优先级比 Expires

Expires(HTTP/1.0)

值为服务器返回该请求结果缓存的到期时间:

Expires: Wed, 22 Oct 2018 08:41:00 GMT

表示资源会在 Wed, 22 Oct 2018 08:41:00 GMT 后过期,需要再次请求。

并且 Expires 受限于客户端时间,如果修改了客户端时间,可能会造成缓存失效。

所以现在 HTTP/1.1中新增了 Cache-Control

Cache-Control(HTTP/1.1)

Cache-control: max-age=30

该属性值表示资源会在 30 秒后过期,需要再次请求。也就是说在 30 秒内如果再次发起该请求,则会直接使用缓存,强缓存生效。

它与 Expires 相比:

  • HTTP响应报文中 Expires 的时间值,是一个绝对值
  • HTTP响应报文中 Cache-Control为max-age=600 ,是相对值(解决 Expires 受限于客户端时间)

除了 max-age ,它还有以下取值:

注意下面的 no-cache ,资源依然会被缓存,并且这个缓存要服务器验证后才可以使用

max-age=0 和 no-cache 等价吗?

从规范的字面意思来说,max-age 到期是 应该(SHOULD) 重新验证,而 no-cache 是 必须(MUST) 重新验证。但实际情况以浏览器实现为准,大部分情况他们俩的行为还是一致的。(如果是 max-age=0, must-revalidate 就和 no-cache 等价了)

总结

自从 HTTP/1.1 开始,Expires 逐渐被 Cache-Control 取代。Cache-Control 是一个相对时间,即使客户端时间发生改变,相对时间也不会随之改变,这样可以保持服务器和客户端的时间一致性。而且 Cache-Control 的可配置性比较强大。

Cache-Control 的优先级高于 Expires,为了兼容 HTTP/1.0 和 HTTP/1.1,实际项目中两个字段我们都会设置。

协商缓存(缓存校验)

如果缓存过期了:

  • 没有 Cache-Control 和 Expires
  • Cache-Control 和 Expires 过期
  • 设置了 no-cache

需要发起请求验证服务器资源是否有更新:

  • 有更新,返回200,更新缓存
  • 无更新,返回304,更新浏览器缓存有效期

Last-Modified 和 If-Modified-Since(HTTP/1.0)

  • Last-Modified(响应头)
  • If-Modified-Since(请求头)

Last-Modified 表示本地文件最后修改日期,If-Modified-Since 会将 Last-Modified 的值发送给服务器,询问服务器在该日期后资源是否有更新,有更新的话就会将新的资源发送回来,否则返回 304 状态码。

但是这种方式存在着一些缺点,例如:

  • 负载均衡的服务器,各个服务器生成的 Last-Modified 可能有所不同
  • GMT 格式有最小单位,例如,如果在一秒内有更改将不能被识别

ETag 和 If-None-Match(HTTP/1.1)

为了解决上面的那个问题, HTTP/1.1 加了这组标记

  • ETag(响应头)
  • If-None-Match(请求头)

ETag 类似于文件指纹,是文件的一个唯一标识序列,当资源有变化时,Etag就会重新生成,If-None-Match 会将当前 ETag 发送给服务器,询问该资源 ETag 是否变动,有变动的话就将新的资源发送回来。并且 ETag 优先级比 Last-Modified 高

使用 ETag 就可以精确地识别资源的变动情况,就算是秒内的更新,也会让浏览器感知,能够更有效地利用缓存

ETag 强弱之分

ETag 机制同时支持强校验和弱校验。它们通过ETag标识符的开头是否存在“W/”来区分,如:

"123456789"   -- 一个强ETag验证符
W/"123456789"  -- 一个弱ETag验证符

强 ETag 要求资源在字节级别必须完全相符,弱 ETag 在值前有个“W/”标记,只要求资源在语义上没有变化,但内部可能会有部分发生了改变(例如 HTML 里的标签顺序调整,或者多了几个空格)

Vary 响应

服务器通过指定 Vary: Accept-Encoding ,告知代理服务器,对于这个资源,需要缓存两个版本:

  • 压缩

  • 未压缩

这样老式浏览器和新的浏览器, 通过代理, 就分别拿到了未压缩和压缩版本的资源,避免了都拿同一个资源的尴尬。

Vary: Accept-Encoding, User-Agent

如上设置,代理服务器将针对是否压缩和浏览器类型两个维度去缓存资源。如此一来,同一个url,就能针对 PC 和 Mobile 返回不同的缓存内容。

点击查看更多内容
TA 点赞

若觉得本文不错,就分享一下吧!

评论

作者其他优质文章

正在加载中
  • 推荐
  • 评论
  • 收藏
  • 共同学习,写下你的评论
感谢您的支持,我会继续努力的~
扫码打赏,你说多少就多少
赞赏金额会直接到老师账户
支付方式
打开微信扫一扫,即可进行扫码打赏哦
今天注册有机会得

100积分直接送

付费专栏免费学

大额优惠券免费领

立即参与 放弃机会
意见反馈 帮助中心 APP下载
官方微信

举报

0/150
提交
取消