一、304 Not Modified 的技术本质与价值

1.1 条件请求的底层逻辑

HTTP 协议通过条件请求机制实现缓存验证。当客户端（如浏览器）缓存了某个资源副本时，后续请求会携带以下头部之一：

• If-Modified-Since：资源最后修改时间（基于 Last-Modified 响应头）。
• If-None-Match：资源唯一标识符（基于 ETag 响应头）。

CDN 边缘节点收到此类请求后，会与源站资源进行比对：

• 若资源未变更，则返回 304 Not Modified，告知客户端继续使用本地缓存。
• 若资源已更新，则返回 200 OK 并附带新资源。

1.2 带宽成本优化的核心路径

传统 200 响应需传输完整资源，而 304 仅返回空响应体（约 50-100 字节），数据量减少 99% 以上。在以下场景中，其价值尤为显著：

• 大文件分发：如视频、软件安装包等动态更新频率低的资源。
• 高并发访问：热点资源被大量重复请求时，304 可避免回源流量爆炸式增长。
• 跨地域分发：边缘节点与源站之间的网络带宽成本通常高于用户与边缘节点的成本。

1.3 边缘计算场景的特殊性

CDN 边缘节点具备两大特性：

1. 分布式部署：全球数百万节点形成多层缓存架构（如 L1/L2/L3 缓存）。
2. 有限计算能力：边缘节点通常采用轻量级操作系统，需避免复杂逻辑影响性能。

因此，304 优化需在保证低延迟的前提下，最小化边缘节点的计算开销。

---

二、CDN 边缘计算中 304 优化的关键技术

2.1 缓存键（Cache Key）的精细化设计

缓存键是边缘节点识别资源的唯一标识。传统方案仅基于 URL 生成缓存键，易导致以下问题：

• 缓存污染：不同用户请求同一 URL 但参数不同（如用户 ID），可能返回错误缓存。
• 验证失效：未包含动态头部（如 Accept-Encoding）时，304 可能被错误触发。

优化方案：

• 多维组合键：将 URL、查询参数、请求头（如 User-Agent、Range）纳入缓存键生成逻辑。
• 哈希简化：对长参数列表进行哈希处理，避免缓存键过长影响存储效率。
• 动态头部过滤：仅保留对资源内容有影响的头部（如 Accept-Language 可能改变返回内容，需纳入缓存键）。

2.2 资源版本标识的动态生成

ETag 和 Last-Modified 是触发 304 的核心依据，其生成策略直接影响优化效果。

2.2.1 ETag 的优化实践

• 强验证 vs 弱验证：
  • 强验证（如文件哈希）：确保资源内容完全一致时才返回 304，但计算开销大。
  • 弱验证（如 W/"<version>"）：允许部分元数据变更（如文件权限）不触发更新，适合静态资源。
• 分层生成策略：
  • 静态资源：使用文件内容哈希作为 ETag，保证绝对一致性。
  • 动态资源：结合数据版本号（如数据库时间戳）和业务逻辑生成 ETag，平衡实时性与计算成本。

2.2.2 Last-Modified 的优化实践

• 时间精度控制：
  • 源站返回的 Last-Modified 需精确到秒级，避免边缘节点因时间粒度不足误判。
  • 边缘节点需同步本地时钟与源站时间，防止时钟偏移导致 304 失效。
• 动态资源更新逻辑：
  • 对于数据库驱动的内容（如新闻列表），使用数据最后修改时间而非文件系统时间。
  • 通过事件通知机制（如消息队列）实时更新边缘节点的资源时间戳。

2.3 缓存过期策略的协同设计

304 优化需与 Cache-Control、Expires 等头部协同工作，形成多层级缓存控制：

• 短过期时间 + 强验证：
  • 适用于频繁变更的资源（如股票行情），通过 max-age=60 设置短缓存周期，同时依赖 ETag 减少回源。
• 长过期时间 + 弱验证：
  • 适用于稳定资源（如 CSS/JS 库），通过 max-age=86400 设置长缓存周期，仅在 ETag 变更时回源。
• 分层缓存架构：
  • L1 缓存（内存）：存储热点资源，设置极短过期时间（如 10 秒）。
  • L2 缓存（磁盘）：存储常规资源，设置中等过期时间（如 1 小时）。
  • L3 缓存（回源）：作为最终保障，无本地缓存时触发回源。

2.4 预取与主动失效机制

为进一步提升 304 命中率，可引入以下机制：

• 资源预取：
  • 分析用户访问模式，提前将关联资源推送至边缘节点（如 HTML 中引用的图片）。
  • 结合 If-Modified-Since 预取资源元数据，避免盲目回源。
• 主动失效：
  • 当源站资源更新时，通过发布系统通知边缘节点立即失效旧缓存。
  • 采用增量失效策略，仅清除受影响资源的缓存，而非全量刷新。

---

三、监控与调优体系构建

3.1 核心指标定义

3.2 异常检测与根因分析

• 304 占比骤降：
  • 可能原因：源站资源频繁变更但未更新 ETag/Last-Modified，或边缘节点缓存键设计错误。
  • 排查方法：对比源站与边缘节点的资源元数据，检查缓存键生成逻辑。
• 回源带宽突增：
  • 可能原因：热点资源缓存过期导致集中回源，或 304 验证失败。
  • 排查方法：分析回源请求的 URL 分布，检查是否集中于特定资源。

3.3 A/B 测试与渐进式优化

• 灰度发布：
  • 选择部分边缘节点或用户群体启用新缓存策略，对比 304 占比和带宽变化。
  • 逐步扩大优化范围，降低风险。
• 参数调优：
  • 动态调整 Cache-Control 的 max-age 值，观察对 304 占比和缓存命中率的影响。
  • 例如：将 max-age 从 3600 秒调整为 7200 秒，观察 304 占比是否提升。

---

四、未来趋势与挑战

4.1 HTTP/3 与 QUIC 协议的影响

HTTP/3 基于 QUIC 协议，通过多路复用和更快的连接建立机制，进一步降低了 304 验证的延迟。然而，其头部压缩算法（QPACK）可能对 ETag 的传输效率产生影响，需重新评估缓存键设计。

4.2 边缘计算与 AI 的融合

未来边缘节点可能集成轻量级 AI 模型，实现以下优化：

• 预测性缓存：基于用户行为预测资源访问概率，提前触发 304 验证。
• 动态策略调整：根据实时流量模式自动优化 Cache-Control 参数。

4.3 安全与隐私的平衡

在 304 优化中，需避免泄露敏感信息：

• ETag 脱敏：避免直接使用用户 ID 或业务关键数据生成 ETag。
• 请求头过滤：禁止边缘节点记录或传输包含个人信息的请求头（如 Cookie）。

---

结论

CDN 边缘计算中的 304 Not Modified 优化，是降低回源带宽成本的核心手段之一。通过精细化缓存键设计、动态资源版本标识、协同缓存过期策略以及主动失效机制，可显著提升 304 响应占比，同时保障资源的新鲜度。结合完善的监控体系与渐进式优化方法，开发者能够在复杂分布式环境中实现性能与成本的平衡。未来，随着协议演进和边缘智能的发展，304 优化将迎来更多创新机遇。