初窥 HTTP 缓存

news/2024/12/13 1:30:58

引言

对于前端来说, 你肯定听说过 HTTP 缓存。 当然不管你知不知道它, 对于提高网站性能和用户体验, 它都扮演着重要的角色! 它通过在客户端和服务器之间存储和重用先前获取的资源副本, 来减少网络流量和降低资源加载时间, 从而提升用户体验! 以下是 HTTP 缓存的重要性:

  1. 减少加载时间: 通过使用缓存, 浏览器可以重用已下载的资源, 而不必每次都从服务器重新请求。这减少了页面加载时间, 提高了用户体验, 尤其是在较慢的网络连接下
  2. 降低服务器负载: HTTP 缓存可以减少服务器的负载, 因为不再需要为相同的资源处理大量重复请求。这有助于减少服务器资源的使用, 降低运营成本
  3. 减少网络流量: HTTP 缓存可以减少不必要的网络流量, 因为浏览器可以从本地缓存中加载资源, 而不必每次都从服务器下载。这有助于减少带宽成本, 尤其是对于大型网站来说
  4. 提高用户体验: 快速加载的网页提供更好的用户体验, 吸引更多的访问者, 并增加用户留存率。缓存使用户能够更快地访问网站内容, 从而提高了他们的满意度

实际开发中我们有时为了避免因为缓存导致资源没有更新, 常常会简单而粗暴的为资源文件路径添加一个时间戳! 该方式虽然有效, 也能解决实际问题, 但过于粗暴了, 我们完全可以采用更加优雅的方式。本文将对 HTTP 缓存进行一个详细的讲解, 来帮助大家对 HTTP 缓存有一个较深的理解, 帮忙大家在实际项目中设计出更为合理、高效的缓存方案!!

补充(偶然看到一句话, 送给大家): 所有的技术都是为了解决问题而存在的, 在不了解问题情况下强行记忆, 效果肯定是打折扣的!!

本文使用到的 DEMO 地址点 这里

一、强缓存

首先在上文我们已经强调了 HTTP 缓存的一个重要性, 那么要想设计一个缓存方案, 最简单的办法就是根据资源加载的时间:

  • 首次加载资源时将资源缓存起来
  • 然后在指定时间内如果加载同一份资源, 则客户端(浏览器)直接使用缓存数据, 而不向服务器发起任何请求
  • 当然如果超时则会发起新的请求获取资源, 然后再次缓存起来

image

而这种不发起任何请求(没经过服务端), 直接由客户端(浏览器)自行决定是否使用缓存的方案, 则被称为 强缓存!!

1.1 Expires

Expires 响应头, 表示当前获取到的资源的过期时间, 该时间是一个 GMT 时间, 即格林尼治时间!!

image

当客户端(浏览器)再次获取资源前:

  • 如果 存在未到期 的缓存资源, 则直接获取缓存的资源, 不发起任何请求!!
  • 如果 不存在缓存资源 或者 缓存的资源已过期, 则向服务器发起请求获取资源, 并再次缓存资源

image

特别注意的是, ExpiresHTTP/1.0 的产物了, 现在大部分浏览器均默认使用 HTTP/1.1 所以它的作用基本可以忽略!!

image

但这里其实有一个问题, Expires 时间是由服务端生成的, 这时如果客户端时间跟服务器时间不一致, 就会导致缓存命中的误差!!

所以后面就有了 Cache-Control

1.2 Cache-Control

Cache-Control 响应头, HTTP/1.1 出现的一个响应头, 它弥补了 Expires 的缺陷:

  • Expires 是直接由服务端给定一个资源过期时间
  • Cache-Control 则不同, 服务端只会告诉客户端该资源的有效期! 就比如, 它有一个 max-age 字段, 当它被设置为 10, 则表示当前资源有效期为 10 秒, 10 秒过后资源缓存将失效

image

Cache-Control 相对来说使用起来也更为复杂, 可设置的属性也比较多。当然复杂也说明它可适用于更广泛的复杂场景, 下面我们来看下 Cache-Control 响应头的语法规则:

  • 不区分大小写, 但建议使用小写
  • 多个指令以逗号分隔
  • 具有可选参数, 可以用令牌或者带引号的字符串语法

Cache-Control 可选属性有: 注意 no-cacheno-store 的区别, no-store 才是禁用 强缓存

类型属性描述
可缓存性public表明响应可以被任何对象(发送请求的客户端、代理服务器等等)缓存
可缓存性private私有缓存, 响应只能被单个客户端缓存
可缓存性no-cache无论本地缓存是否过期, 都需要请求源服务器进行验证(协商缓存验证)
可缓存性no-store不使用任何缓存
到期时间max-age=<seconds>设置缓存有效期的最大周期, 超过这个时间缓存被认为过期(单位秒)
到期时间s-maxage=<seconds>max-age, 但是仅适用于共享缓存(代理服务器), 生效时会覆盖 max-age 或者 Expires
到期时间max-stale[=<seconds>]表明客户端愿意接收一个已经过期的资源, 可以设置一个可选的秒数, 表示缓存允许过期的最大值
到期时间min-fresh=<seconds>希望在一个指定的秒数内保持资源的最新, 也就是说在设定的时间内获取资源不管缓存有没效, 都需要发起缓存进行验证(协商缓存验证)
到期时间stale-while-revalidate=<seconds>实验版, 有点类似 max-stale, 客户端愿意接收一个已经过期的资源, 同时客户端会在后台异步获取新的资源; 可以设置一个秒数, 表示允许接受陈旧缓存的最大值
到期时间stale-if-error=<seconds>实验版, 如果新的检查失败, 则客户端愿意接受陈旧的响应, 设置的秒数值表示客户端在初始到期后愿意接受陈旧响应的时间
重新验证或重新加载must-revalidate如果本地副本未过期, 可以使用本地副本; 否则, 需要请求源服务器进行验证
重新验证或重新加载proxy-revalidatemust-revalidate 作用相同, 但它仅适用于共享缓存(例如代理服务器), 对于私有缓存(本地缓存)该值会被忽略
重新验证或重新加载immutable实验版, 表示缓存一直有效, 再也不会发起请求了
其他no-transform不允许对资源进行转换或转变, Content-EncodingContent-RangeContent-TypeHTTP 头允许被代理服务修改
其他only-if-cached客户端只接受已缓存的响应, 不会进行任何请求, 如果缓存不命中则返回错误

下面我们来测试下, 如下代码是使用 Koa 搭建的一个简单服务:

  • 代码中实现了一个 GET 接口 /api/cache-control
  • 在接口 /api/cache-control 响应体中设置了 Cache-Control 响应头, 值为 public,max-age=120
  • 那么当客户端访问 /api/cache-control 理论上, 请求的响应内容会被任何端缓存起来, 缓存有效期 120s
const Koa = require('koa');
const moment = require('moment');
const cors = require('@koa/cors')
const Router = require('@koa/router');const app = new Koa();
const router = new Router();// 跨域设置
app.use(cors({maxAge: 5,origin: "*",credentials: true,allowMethods: ['GET', 'POST'],allowHeaders: ['Content-Type'],exposeHeaders: ['Content-Type'],
}));// 2. Cache-Control
router.get('/api/cache-control', async (ctx) => {ctx.status = 200;ctx.body = 111111111;ctx.set('Cache-Control', `public,max-age=120`);
});app.use(router.routes()).use(router.allowedMethods());
app.listen(3000);

1.3 Pragma

Pragma 是一个在 HTTP/1.0 中规定的响应头, 它只有一个属性值, 就是 no-cache, 其效果和 Cache-Control 中的 no-cache 是一致的, 表明不使用强缓存, 需要客户端(浏览器)与服务器验证缓存是否有效, Pragma 在本节的 3 个头部属性中的优先级是最高的

image

也许你会奇怪为啥有了 Cache-Control 还要整个 Pragma, 这里你需要注意的是 Cache-Control 其实是后面 HTTP/1.1 才出来的, 在 Cache-Control 之前 Pragma 是作为 Expires 的一个补充!!

当然 Pragma 目前主要就是用于向后兼容那些只支持 HTTP/1.0 协议的客户端!!

二、协商缓存

上文几个响应头, 客户端、服务端是通过约定缓存有效时间来决定, 是否 直接 使用本地缓存!! 但是这个方案其实存在很明显的问题:

  • 假设我们约定每次资源缓存的有效时间为 2 分钟
  • 但是呢? 2 分钟内, 如果服务端资源更新了, 按强缓存来, 这时客户端拿到的资源都是缓存内容, 就无法保证资源的最新
  • 同样, 如果服务端资源一直不更新, 那么 2 分钟后, 客户端如果发起请求这时将会重新获取资源, 这就不可避免的造成资源的浪费

那么要想解决上面这个问题, 就可以使用 协商缓存, 其实所谓 协商缓存 就是客户端(浏览器)在请求资源时先向服务端进行 协商: 客户端(浏览器)向服务端询问本地缓存的资源是否是最新的

  • 如果本地缓存的资源 未过期, 那么服务端就会将请求状态码设置为 304(Not Modified), 这时请求不会返回任何 body, 客户端(浏览器)将直接使用本地缓存
  • 如果本地缓存已过期, 那么服务端正常处理请求, 状态码设置为 200, 这时的 body 将是完整的资源内容

image

那么服务端如何判断客户端本地的缓存不是最新的呢? 它们之间又是怎么协调的呢?

2.1 Last-Modified / If-Modified-Since

第一个方案其实就是根据 资源最后修改时间 来进行判断:

  • 当客户端首次请求资源时, 服务端会把资源的最后修改时间放到 Last-Modified 响应头中(浏览器自动将 Last-Modified 也缓存起来)
  • 当客户端再次请求资源时, 浏览器会通过 If-Modified-Since 请求头, 将本地缓存资源对应最后修改时间带上(这个是浏览器自己的行为, 不需要我们认为去处理)
  • 服务端就可以根据 If-Modified-Since 来判断客户端(浏览器)的资源是否是最新的
  • 如果是客户缓存的资源是最新的, 则 body 直接返回空, 同时将状态码改为 304(Not Modified)
  • 否则按首次请求资源处理, 状态码为 200, body 为请求的资源内容

image

下面使用 Koa 搭建的一个简单服务:

  • 在接口中我们将客户端请求头中的 if-modified-since 和当前的 Last-Modified 进行比较
  • 如果相同, 则表示客户端的资源是最新的, 则不返回任何内容(body 为空), 让客户端直接使用缓存(状态码设置为 304)
  • 如果不相同, 则表示客户端的资源不是最新的, 则正常返回内容(状态码为 200, body 为当前资源内容), 当然这时还需要带上 Last-Modified
const Koa = require('koa');
const moment = require('moment');
const cors = require('@koa/cors')
const Router = require('@koa/router');const app = new Koa();
const router = new Router();// 跨域设置
app.use(cors({maxAge: 5,origin: "*",credentials: true,allowMethods: ['GET', 'POST'],allowHeaders: ['Content-Type'],exposeHeaders: ['Content-Type'],
}));// 4. Last-Modified / If-Modified-Since
const lastModified = 'Thu, 09 Nov 2023 06:37:41 GMT'
router.get('/api/last-modified', async (ctx) => {// 客户端本地缓存最新更改时间和当前的一致 => 让客户端直接使用缓存吧if (ctx.request.header['if-modified-since'] === lastModified) {ctx.status = 304;ctx.body = '2222'} else {// 返回最新内容ctx.status = 200;ctx.body = '111111111'}ctx.set('Last-Modified', lastModified);ctx.set('Cache-Control', 'no-cache');
});app.use(router.routes()).use(router.allowedMethods());app.listen(3000);

image

这里有个奇怪的现象, 第二次请求时, 服务器实际上设置的状态码为 304, body 内容为 2222, 但是在 chrome 中查看的话会发现展示出来的状态码为 200, body 为缓存的数据!!

image
image

猜测: chrome 针对本地存在缓存的 304 接口做了处理, 这里有一篇文章可供参考 《为什么Chrome开发工具显示200状态代码而不是 304? 》, 具体原因就不细究了…

2.2 ETag / If-None-Match

「根据最后修改时间, 来判定客户端缓存是否是最新的资源」这个依据在大部分情况应该是有效的!! 但是也避免不了一种情况就是, 资源更新时间变了, 但是呢内容和之前却是一样的(比如项目重新打包、资源修改一版又撤销回去…)

这种情况下, 我们就可以使用 ETag 来判断资源是否有效!!! ETag 作为资源内容的唯一标记被使用, 它可以是资源内容对应的一个唯一 ID, 也可以是根据资源文件内容生成的一个 MD5, 总之它代表的当前资源的一个唯一值!!

ETag 在服务端和客户端之前的工作流程和 Last-Modified 基本一致:

  • 当客户端首次请求资源时, 服务端会把当前资源对应唯一标记放到 ETag 响应头中(浏览器会将 ETag 也缓存起来)
  • 当客户端再次请求资源时, 浏览器会通过 If-None-Match 请求头, 将本地缓存资源对应的 ETag 带上(浏览器自己的行为)
  • 服务端就可以根据 If-None-Match 以及当前资源的 ETag 来判断客户端(浏览器)的资源是否是最新的
  • 如果客户缓存的资源是最新的, 则 body 直接返回空, 同时将状态码改为 304(Not Modified)
  • 否则按首次请求资源处理, 同时带上 ETag

image

下面使用 Koa 搭建的一个简单服务:

  • 在接口中我们将客户端请求头中的 if-none-match 和当前的 ETag 进行比较
  • 如果相同, 则表示客户端的资源是最新的, 则不返回任何内容(body 为空), 让客户端直接使用缓存(状态码设置为 304)
  • 如果不相同, 则表示客户端的资源不是最新的, 则正常返回内容(状态码为 200, body 为当前资源内容), 当然这时还需要带上 ETag
const Koa = require('koa');
const moment = require('moment');
const cors = require('@koa/cors')
const Router = require('@koa/router');const app = new Koa();
const router = new Router();// 跨域设置
app.use(cors({maxAge: 5,origin: "*",credentials: true,allowMethods: ['GET', 'POST'],allowHeaders: ['Content-Type'],exposeHeaders: ['Content-Type'],
}));// 5. ETag / If-None-Match
const ETag = '33a64df551425fcc55e4d42a148795d9f25f89d4'
router.get('/api/etag', async (ctx) => {// 客户端本地缓存最新 ETag 和当前的一致 => 让客户端直接使用缓存吧if (ctx.request.header['if-none-match'] === ETag) {ctx.status = 304;ctx.body = '2222'} else {// 返回最新内容ctx.status = 200;ctx.body = '111111111'}ctx.set('ETag', ETag);ctx.set('Cache-Control', 'no-cache');
});app.use(router.routes()).use(router.allowedMethods());app.listen(3000);

image

同上文, 如果本地缓存有效, 并且服务端状态码为 304, chrome 展示状态码也只会是 200, 内容为缓存的内容

2.3 补充: If-Unmodified-Since / If-Match

上文提到的几个消息头, 都只是在获取资源(get 请求)情况下生效!! If-Unmodified-SinceIf-Match 则是在修改内容的情况下生效, 比如 postputremove 等请求:

  • 当客户端(浏览器)发起请求试图修改资源时, 可以携带上 If-Unmodified-Since(本地资源对应 Last-Modified)If-Match(本地资源 ETag)
  • 服务端通过请求头中的 If-Unmodified-SinceIf-Match 来判断服务端资源是否已经被修改过(当前本地资源是否是最新的)
  • 如果服务端的资源已经被修改过, 那么服务端直接返回 412 (Precondition Failed) 错误, 不处理本次请求
  • 相反, 则返回 200! 正常处理请求

image

三、优先级

  1. 首先强缓存优先级大于协商缓存, 只有在强缓存失效情况下, 然后才会和服务端建立连接进行协商
  2. 强缓存中: Pragma > Cache-Control > Expires
  3. 协商缓存中: ETag > Last-Modified, 因为 ETag 更为精准

四、参考

  • 30分钟搞懂 HTTP 缓存
  • 前端应该知道 HTTP 缓存机制
  • 从未如此简单 5 分钟搞懂 HTTP 缓存机制
  • 彻底搞懂 HTTP 缓存策略,切记死背概念!
  • HTTP 缓存看这一篇就够了
  • 图解 HTTP 缓存
  • 轻松理解 HTTP 缓存策略
  • 面试官: 你懂 HTTP 缓存,那说下浏览器强制刷新是怎么实现的?

image


https://dhexx.cn/news/show-5466008.html

相关文章

C++实现网格交易的例子

网格交易是一种投资策略&#xff0c;它通过在预设的价格区间内自动进行买入和卖出操作来捕捉市场的波动收益。以下是网格交易的一些详细介绍&#xff1a; 定义&#xff1a; 网格交易策略是一种围绕基准价进行的交易方法&#xff0c;每当价格下跌时&#xff0c;在触发点位执行买…

【docker】docker的起源与容器的由来、docker容器的隔离机制

Docker 的起源与容器的由来 1. 虚拟机的局限&#xff1a;容器的需求萌芽 在 Docker 出现之前&#xff0c;开发和部署软件主要依赖虚拟机&#xff08;VMs&#xff09;&#xff1a; 虚拟机通过模拟硬件运行操作系统&#xff0c;每个应用程序可以运行在自己的独立环境中。虽然虚…

云技术基础(泷羽sec)

声明 学习视频来自B站UP主 泷羽sec,如涉及侵泷羽sec权马上删除文章。 笔记只是方便各位师傅学习知识,以下网站只涉及学习内容,其他的都与本人无关,切莫逾越法律红线,否则后果自负 这节课旨在扩大自己在网络安全方面的知识面&#xff0c;了解网络安全领域的见闻&#xff0c;了…

Sofia-SIP 使用教程

Sofia-SIP 是一个开源的 SIP 协议栈&#xff0c;广泛用于 VoIP 和即时通讯应用。以下是一些基本的使用教程&#xff0c;帮助你快速上手 Sofia-SIP。 1. 安装 Sofia-SIP 首先&#xff0c;你需要安装 Sofia-SIP 库。你可以从其官方 GitHub 仓库克隆源代码并编译安装&#xff1a…

C++优选算法十六 BFS解决最短路问题

1.BFS解决最短路问题的优势与局限 BFS是一种有效的解决最短路问题的算法&#xff0c;特别适用于无权图或边权相等的图。 优势&#xff1a; BFS能够逐层遍历图中的所有节点&#xff0c;直到找到目标节点或遍历完所有可达节点。对于无权图&#xff08;即边权为1的图&#xff0…

在内网工作时,如何使用 vscode remote ssh 去连接内网服务器?

来源&#xff1a;https://stackoverflow.com/questions/56671520/how-can-i-install-vscode-server-in-linux-offline 看这个回答&#xff1a; 一般来说&#xff0c;内网会提供 vscode 安装包&#xff0c;remote-ssh 的 vsix&#xff0c;先安装好。 随后&#xff0c;保证自己…

C++设计模式:桥接模式(Bridge)

什么是桥接模式&#xff1f; 桥接模式&#xff08;Bridge Pattern&#xff09;是一个用来解耦的设计模式&#xff0c;它将抽象层和实现层分离开&#xff0c;让它们可以独立变化。用最简单的话来说&#xff0c;就是让你能够改变抽象的功能和具体的实现&#xff0c;而不需要修改…

Zariski交换代数经典教材Commutative Algebra系列(pdf可复制版)

Zariski的名字估计学代数几何的人都耳熟能详&#xff0c;先是入门时期的交换代数教材&#xff0c;然后就是深入研究时期随处可见的Zariski拓扑。本帖我们分享的便是著名的Zariski交换代数教材。 Oscar Zariski & Pierre Samuel写的交换代数经典教材Commutative Algebra&am…

AppFlow:支持飞书机器人调用百炼应用

AppFlow&#xff1a;支持飞书机器人调用百炼应用 简介&#xff1a; 本文介绍了如何创建并配置飞书应用及机器人&#xff0c;包括登录飞书开发者后台创建应用、添加应用能力和API权限&#xff0c;以及通过AppFlow连接流集成阿里云百炼服务&#xff0c;最后详细说明了如何将机器…

尚硅谷学习笔记——Java设计模式(一)设计模式七大原则

一、介绍 在软件工程中&#xff0c;设计模式&#xff08;design pattern&#xff09;是对软件设计中普遍存在&#xff08;反复出现&#xff09;的各种问题&#xff0c;提出的解决方案。我们希望我们的软件能够实现复用性、高稳定性、扩展性、维护性、代码重用性&#xff0c;所以…