http请求缓存

本文深入探讨了HTTP缓存的工作原理,包括强缓存和协商缓存。强缓存通过expires和cache-control头判断是否使用缓存;协商缓存涉及last-modified和If-Modified-Since,以及Etag和If-None-Match头的比较。当缓存未失效时,直接使用,否则服务器会检查更新并决定是否返回304状态码。了解这一机制有助于优化网络请求性能。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

http请求缓存总结


多余的话不多说,这篇文章主要梳理一下http缓存的整个过程。

http缓存分为强缓存和协商缓存,强缓存优先于协商缓存,总体的过程如下:

  1. 浏览器在发送http请求时,先判断是否有缓存,如果有缓存(expires/catche-control1),则判断缓存是否失效,如果没有失效,则直接采用缓存,如果已失效则走协商缓存。(catche-control的不同的值2
  2. 协商缓存有2套机制:一个last-Modified+If-Modified-Since模式,另一个是Etag+If-None-Match模式,前者通过文件更新时间来判断是否取缓存,后者通过hash值来判断3
  3. 第一次请求时,response header里会携带这些缓存信息,浏览器把这些信息保存在缓存中,第二次请求的时候会携带这些信息。
  4. 服务器比对信息之后,判断是否命中缓存,命中缓存则返回304,通知客户端取浏览器缓存,没有命中则返回200,把资源重新发给客户端。

看下面的图,会有一个更清晰的认识:

流程图


  1. expires是http1.0的产物,存储的是一个时间,表示该缓存的过期时间;catche-control是http1.1的产物,目前浏览器大多支持的是1.1,存储的是一个倒计时,表示多少秒之后过期; ↩︎

  2. private: 客户端可以缓存
    public: 客户端和代理服务器都可缓存(对于前端来说public和private是一样的)
    max-age=xxx: 缓存的内容将在 xxx 秒后失效
    no-cache: 需要使用协商缓存来验证缓存数据
    no-store: 所有内容都不会缓存,强制缓存,协商缓存都不会触发 ↩︎

  3. last-modified是服务端把文件的最新更新时间返回给客户端,客户端第二次请求时,把这个时间带上,服务根据这个时间与文件的更新时间进行对比,如果不一致,说明文件有更新;
    Etag模式是服务端返回一个hash值给前端,文件每次更新都会生成一个新的hash值,同样是对比2个hash值是否一致,如果不一致则说明文件有更新。
    俩者的区别:Etag模式优先于lastModified,并且更加精确。因为lastModified精确度是到秒,如果一秒内更新了多次,并不能跟踪到每次更新,如果是负载均衡的服务器,各个服务器生成的Last-Modified也有可能不一致。
    参考:
    [1]: https://www.cnblogs.com/chenqf/p/6386163.html ↩︎

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值