数得其道

道 · 法 · 术 · 器

⭐ 精选文章

ETag 完全指南：从“傻瓜式”请求到高性能架构的演进之路

Web
ETag 完全指南：从“傻瓜式”请求到高性能架构的演进之路

ETag 完全指南：从“傻瓜式”请求到高性能架构的演进之路

大家好，今天我们来聊一个老生常谈但至关重要的 Web 性能优化工具：ETag。

很多开发者可能听说过它，但未必真正理解其工作原理以及在应用架构中的强大作用。今天，我们不直接讲理论，而是跟随一个虚拟的应用 “MyApp” 的成长历程，看看它是如何在不同阶段被“逼”着使用 ETag 来解决性能瓶颈的。

V1.0 - “我的应用上线了！” (原始阶段)

MyApp 是一个简单的博客展示应用。开发者小明用最新的框架把它快速搭建了起来。

  • 架构：一台服务器，运行着 Node.js 应用，直接响应所有请求。

  • 用户体验：用户每次刷新页面，或在文章列表和详情页之间跳转时，浏览器都会忠实地重新下载所有资源：HTML、CSS、JS、图片，以及调用 API 获取文章数据。

  • 遇到的问题:

    1. 慢：页面加载速度不理想，即使用户刚刚看过这张图片。
    2. 浪费：用户的带宽和服务器的流量都被不必要的重复下载所消耗。
    3. 高负载：服务器需要一遍又一遍地处理相同的请求，提供相同的内容。

阶段小结：在应用的起步阶段，功能优先。但很快，性能问题就会成为用户体验和服务器成本的头号敌人。

V1.5 - “我学会了浏览器缓存！” (盲目缓存阶段)

小明学习了 HTTP 缓存，他发现了一个简单的解决方案：Cache-Control 和 Expires。

  • 架构升级：小明在 Nginx 或应用层为静态资源配置了缓存头。

    location /static/ {
    # 告诉浏览器，这个资源可以缓存 7 天
    expires 7d; 
}

  • 用户体验改善：哇！现在网站快多了！在 7 天内，浏览器甚至不会向服务器发送请求，而是直接从本地磁盘读取 JS/CSS 和图片，实现了瞬时加载。

  • 新的问题（致命的）: 小明修复了一个紧急的 CSS bug，发布了新版本的 main.css。但他沮丧地发现，大量用户看到的仍然是旧的、有问题的样式。因为他们的浏览器认为缓存的 main.css 在 7 天内都是有效的，根本不会来服务器询问是否有更新。

阶段小结：强制性的长期缓存（强缓存）虽然快，但牺牲了内容的“新鲜度”。我们陷入了两难：要么牺牲性能，要么牺牲更新的及时性。有没有一种方法，既能利用缓存，又能确保内容更新时用户能立即看到？

V2.0 - “智能验证，ETag 登场！” (协商缓存阶段)

为了解决 V1.5 的问题，小明引入了今天的主角——ETag (实体标签)，这是一种协商缓存机制。

核心思想：我不强制浏览器缓存多久，而是给每个资源一个唯一的“版本号”（ETag）。浏览器每次都来问我，但它会带上它手里的版本号。如果版本号没变，我就告诉它“你那个还能用”，这样它就不用重新下载了。

2.1 ETag 如何工作？

这个过程就像一个严谨的“对暗号”流程：

  1. 首次请求：

    • 浏览器请求 /api/posts/1。
    • 服务器返回 200 OK，响应体是文章数据，响应头里带着 ETag: "v1-abcdef"。
    • 浏览器缓存了文章数据和这个 ETag。

  2. 后续请求：

    • 浏览器再次请求 /api/posts/1，但这次它在请求头里加上了 If-None-Match: "v1-abcdef"。
    • 这个头的意思是：“我手里有 v1-abcdef 这个版本，除非你有不一样的，否则别给我完整数据。”

  3. 服务器决策：

    • 情况A：内容未变。服务器计算出当前文章的 ETag 仍然是 "v1-abcdef"。它发现“暗号”对上了。
      • 服务器返回一个极小的 304 Not Modified 响应（没有响应体！）。
      • 浏览器收到 304 后，开心地从自己的缓存里读取数据来使用。
    • 情况B：内容已变。服务器发现文章被编辑了，新的 ETag 是 "v2-ghijkl"。
      • 服务器返回 200 OK，响应体是新的文章数据，响应头里是新的 ETag: "v2-ghijkl"。
      • 浏览器用新的数据和新的 ETag 更新自己的缓存。

2.2 如何在 MyApp 中实现 ETag？

A. 静态文件 (Nginx 实现)

对于 JS, CSS, 图片等，Nginx 可以自动处理。

# Nginx 默认会根据文件的修改时间和大小生成 ETag
location /static/ {
    etag on; # 通常默认开启
}

B. 动态 API (应用层实现)

对于 API 数据，只有应用本身知道内容是否变化。因此，应用需要负责生成 ETag。

// Node.js/Express 示例
const express = require('express');
const crypto = require('crypto');
const app = express();

function generateEtag(data) {
    const hash = crypto.createHash('md5').update(JSON.stringify(data)).digest('hex');
    return `"${hash}"`;
}

app.get('/api/posts/:id', (req, res) => {
    const post = getPostFromDb(req.params.id); // 从数据库获取文章
    if (!post) return res.status(404).send();

    const etag = generateEtag(post); // 为当前内容生成 ETag
    const clientEtag = req.headers['if-none-match'];

    // 对比 ETag
    if (clientEtag === etag) {
        return res.status(304).send(); // ETag 匹配，返回 304
    } else {
        res.setHeader('ETag', etag); // ETag 不匹配，返回新数据和新 ETag
        res.status(200).json(post);
    }
});

阶段小结： ETag 完美解决了 V1.5 的问题！我们既享受了缓存带来的速度，又通过 304 响应保证了数据的及时更新，同时极大地节省了带宽。

V3.0 - “流量上来了！” (反向代理缓存阶段)

MyApp 火了，访问量激增。小明发现，尽管 304 响应很小，但大量的验证请求仍然给 Node.js 应用带来了不小的压力。因为每次验证，应用都需要：查询数据库 -> 计算 ETag -> 进行比较。

架构升级：小明在 Node.js 应用前加了一层 Nginx 作为反向代理缓存。

工作原理升级（多级缓存）：

  1. 第一个请求到达时，流程和 V2.0 一样： Nginx 将请求转发给 Node.js，Node.js 返回带 ETag 的数据。

  2. 关键区别： Nginx 在将响应发给浏览器的同时，将这个完整的响应（包括 ETag 头和数据体）缓存在自己的磁盘上 (proxy_cache)。

  3. 后续请求（无论是普通请求还是带 If-None-Match 的条件请求）到达 Nginx 时：

    • Nginx 首先检查自己的缓存。
    • 如果缓存命中，Nginx 直接返回缓存的响应（包括 ETag），无需再请求 Node.js。
    • 如果缓存未命中，Nginx 才会转发请求到 Node.js。
    • 整个过程，后端的 Node.js 应用完全没有被请求到！
# 在 http 块中定义缓存区域
proxy_cache_path /var/cache/nginx/api_cache keys_zone=my_cache:10m inactive=60m;

server {
    location /api/ {
        proxy_cache my_cache;
        proxy_cache_key "$request_method$request_uri";
        proxy_cache_valid 200 304 5m; // 缓存 5 分钟

        # 如果后端应用返回了 ETag，Nginx 会自动用它来处理 If-None-Match
        # 无需特殊配置
        
        proxy_pass http://localhost:3000;
    }
}

阶段小结： 通过在 Nginx 层增加 proxy_cache，我们将大部分对动态内容的验证负载也从应用服务器上卸载了。 应用服务器可以更专注于处理核心业务逻辑（如用户登录、写入数据等），整个系统的吞吐能力和响应速度得到了质的飞跃。