无需登录 数据私有 本地保存

ETag 缓存验证演示 - 条件请求交互

10
0
0
0

ETag 缓存验证演示

模拟 HTTP 条件请求 · If-None-Match · 304 Not Modified · 乐观并发控制

服务器 资源内容 & ETag
当前 ETag: "a1b2c3d4"
就绪
修改内容后 ETag 将自动更新
⇅ HTTP 请求/响应 ⇅
⇅ HTTP 请求/响应 ⇅
客户端 缓存状态
缓存 ETag: — 无缓存 —
缓存内容:
尚未缓存任何内容
条件请求将携带 If-None-Match 头
乐观并发控制 (If-Match) 模拟PUT请求的并发冲突检测
等待操作
当If-Match ETag与服务器不匹配时返回 412 Precondition Failed
HTTP 请求/响应日志
点击操作按钮发起请求
请求和响应将在此显示
常见问题 & 知识点

ETag（Entity Tag）是HTTP协议中用于标识资源版本的机制。服务器为每个版本的资源生成一个唯一标识符（通常是内容的哈希值），客户端缓存该ETag。当客户端再次请求时，通过If-None-Match头将缓存的ETag发送给服务器，服务器比较ETag：若匹配则返回304 Not Modified（节省带宽），若不匹配则返回200 OK和新内容。这是HTTP缓存验证的核心机制，比Last-Modified更精确（可检测秒级内的变化）。

强ETag（如"abc123"）要求资源字节完全相同才匹配，适用于二进制文件、图片等精确资源。
弱ETag（如W/"abc123"）允许资源在语义等价但字节不完全相同时匹配，例如HTML页面中空格差异、CDN对内容做了微小优化等场景。弱ETag以W/前缀标识。在本演示工具中，您可以切换两种类型来观察行为差异。

304 Not Modified表示服务器告知客户端："你缓存的版本仍然是最新的，无需重新传输资源主体"。304响应不包含消息体（body），只包含HTTP头信息，因此能显著节省带宽。客户端收到304后，继续使用本地缓存的版本，并更新缓存过期时间。这是条件请求的核心价值——用极小的网络开销验证缓存有效性。

If-None-Match：用于缓存验证（GET请求），语义为"如果ETag不匹配则返回资源"。ETag匹配→304，不匹配→200。
If-Match：用于乐观并发控制（PUT/PATCH请求），语义为"如果ETag匹配才执行操作"。ETag匹配→操作成功，不匹配→412 Precondition Failed，防止"丢失更新"问题。本工具同时演示了这两种场景。

ETag比Last-Modified更精确：
1. 秒级精度：Last-Modified只能精确到秒，ETag可检测亚秒级变化；
2. 内容敏感：ETag基于内容哈希，即使时间戳不变也能检测到变化；
3. 避免时钟同步问题：分布式服务器时钟不同步时Last-Modified可能不准确；
4. HTTP/1.1规范明确：当两者同时存在时，ETag优先级更高。现代Web应用通常同时提供两者以获得最佳兼容性。

CDN节点和浏览器都广泛使用ETag进行缓存验证：
• 浏览器：自动在条件请求中携带If-None-Match，无需开发者干预；
• CDN：边缘节点使用ETag验证源站资源是否变化，减少回源带宽；
• Nginx：默认自动生成ETag（基于文件修改时间和大小）；
• 最佳实践：静态资源使用内容哈希作为ETag，动态API响应可基于数据版本号生成ETag。合理配置ETag可大幅降低服务器负载和带宽消耗。

412 Precondition Failed最常见于乐观并发控制场景：多个用户同时编辑同一资源时，先提交者成功，后提交者收到412错误，避免覆盖他人的修改。工作流程：
1. 客户端A读取资源（获得ETag: "v1"）
2. 客户端B也读取并修改提交（服务器ETag变为"v2"）
3. 客户端A尝试提交时携带If-Match: "v1"
4. 服务器发现"v1"≠"v2"，返回412
5. 客户端A需重新获取最新版本并合并冲突。这是RESTful API设计的重要模式。
🔧 相关工具