6.3 压缩、ETag与缓存：让回程更快

7.1 响应压缩与缓存策略（ETag、Cache-Control）

7.1 响应压缩与缓存策略（ETag、Cache-Control）

在现代Web应用架构中，性能早已不是可有可无的附加项，而是决定用户体验、系统可伸缩性乃至商业成败的核心要素。尤其在基于Node.js构建的Express框架生态下，如何高效利用网络资源、减少冗余传输、降低服务器负载，成为每一位后端工程师必须直面的课题。响应压缩与缓存策略，作为HTTP协议层最直接、最有效的性能优化手段，构成了第七章“性能优化与可伸缩性”的基石。本文将深入剖析这两个机制——从其诞生的协议背景，到在Express中的工程实现；从ETag的语义协商逻辑，到Cache-Control的精细控制粒度——力图揭示其背后的设计哲学与实践智慧。

HTTP性能优化的双重引擎：压缩与缓存

想象一下，你站在一座繁忙的城市交通枢纽，车辆川流不息。若没有高效的交通信号系统与合理的路线规划，拥堵将不可避免。在网络世界中，HTTP请求与响应便是这些“车辆”，而压缩与缓存正是那套精密的“交通管理系统”。压缩致力于减小单次传输的数据体积，如同为每辆车瘦身；缓存则通过复用已传输的内容，避免不必要的重复通行，相当于为高频路线设立快速通道。二者协同作用，共同提升整个系统的吞吐能力与响应速度。

值得注意的是，这两项技术并非Express框架独创，而是根植于HTTP/1.1规范（RFC 7234等）的通用机制。Express的价值在于提供了一套简洁、模块化的API，使得开发者能够以极低的认知成本接入这些强大的协议特性。然而，若仅满足于调用中间件而忽视其底层原理，则极易陷入“配置即正确”的误区，导致性能收益大打折扣，甚至引入隐蔽的Bug。

响应压缩：让数据轻装上阵

原理与协议支持

响应压缩的核心思想是：在服务器端对即将发送的响应体进行压缩编码，客户端收到后自动解压还原。这一过程对应用逻辑透明，却能显著减少传输字节数——尤其对于文本类资源（如HTML、CSS、JavaScript、JSON），压缩率常可达60%以上。

HTTP协议通过Accept-Encoding与Content-Encoding头部字段协商压缩算法：

• 客户端在请求头中声明其支持的压缩算法，例如：Accept-Encoding: gzip, deflate, br

• 服务器根据自身能力与资源类型，选择一种算法进行压缩，并在响应头中标注：Content-Encoding: gzip

目前主流的压缩算法包括：

• gzip：基于DEFLATE算法，兼容性最好，几乎所有浏览器和服务器都支持。

• deflate：同样基于DEFLATE，但封装格式略有不同，实际使用较少。

• Brotli (br)：由Google开发的新一代压缩算法，在相同压缩级别下通常比gzip更高效，尤其适合静态文本。但需注意，Node.js原生zlib模块直到v11.7.0才支持Brotli，且部分旧版浏览器不兼容。

Express中的实现：compression中间件

在Express中启用响应压缩极为简便，只需引入官方维护的compression中间件：

const express = require('express');
const compression = require('compression');
const app = express();
app.use(compression({
  threshold: 1024, // 仅当响应体大于1KB时才压缩
  filter: (req, res) => {
    // 自定义过滤逻辑，例如跳过已压缩的资源
    if (res.get('Content-Type') === 'application/json') {
      return true;
    }
    return compression.filter(req, res);
  }
}));
​

该中间件默认使用gzip，并智能处理以下细节：

• 自动检测客户端是否支持压缩；

• 避免对已压缩内容（如图片、视频）再次压缩；

• 通过threshold参数防止对小响应进行得不偿失的压缩操作（因压缩本身有CPU开销）。

然而，这种“一键启用”的便利性也隐藏着陷阱。例如，在高并发场景下，压缩操作会消耗大量CPU资源。若服务器CPU已接近瓶颈，盲目开启压缩反而可能降低整体吞吐量。此时，更优的策略是将压缩卸载至反向代理层（如Nginx），利用其更高效的C语言实现，同时释放Node.js主线程压力。

压缩的权衡：CPU vs 带宽

压缩的本质是一场资源置换游戏：用CPU计算时间换取网络带宽。其效益取决于两个关键变量：

1. 内容的可压缩性：纯文本高度可压缩，而二进制文件（如JPEG、MP4）几乎不可压缩。

2. 系统资源瓶颈所在：若带宽是瓶颈（如移动网络、跨国传输），压缩收益显著；若CPU是瓶颈（如密集计算型服务），则需谨慎评估。

一个值得深思的问题是：我们是否应该对动态生成的JSON API响应进行压缩？答案并非绝对。对于小型API（<1KB），压缩节省的字节数微乎其微，而压缩开销却固定存在；但对于包含大量数据的报表类API，压缩带来的延迟降低可能远超其CPU成本。因此，精细化的压缩策略——基于内容类型、响应大小、甚至用户地理位置动态决策——才是高级优化的方向。

缓存策略：避免重复劳动的艺术

如果说压缩是“减法”，那么缓存就是“除法”——它从根本上消除重复请求，将性能提升推向极致。HTTP缓存机制分为两类：强制缓存与协商缓存。前者通过Cache-Control或Expires头部直接决定资源是否可用；后者则依赖ETag或Last-Modified进行条件验证。

强制缓存：Cache-Control的精细调控

Cache-Control是HTTP/1.1引入的、功能强大的缓存控制指令集。它通过一系列指令（directives）精确描述资源的缓存行为。在Express中，可通过res.set()或专用中间件设置：

// 对静态资源设置长期缓存
app.use('/static', express.static('public', {
  maxAge: '1y' // 等价于 Cache-Control: public, max-age=31536000
}));
// 对API响应设置短时缓存
app.get('/api/data', (req, res) => {
  res.set('Cache-Control', 'public, max-age=60'); // 缓存60秒
  res.json({ data: '...' });
});
​

关键指令解析：

• max-age=<seconds>：指定资源在多少秒内被视为新鲜（fresh），无需重新验证。这是最常用的指令。

• s-maxage：专用于共享缓存（如CDN、代理服务器），优先级高于max-age。

• public / private：public表示响应可被任何缓存存储；private则限制仅用户私有缓存（如浏览器）可存储，防止敏感信息被代理缓存泄露。

• no-cache：并非禁止缓存！而是要求每次使用前必须向服务器验证资源是否更新（即触发协商缓存）。

• no-store：真正禁止缓存，适用于包含用户隐私或交易数据的响应。

一个常见误区是将no-cache等同于“不缓存”。实际上，no-cache允许缓存存储响应，但强制每次使用前进行验证。这在需要实时性但又希望减少完整响应体传输的场景中非常有用——若资源未变，服务器仅返回304 Not Modified，节省大量带宽。

协商缓存：ETag的语义力量

当强制缓存失效（或未设置）时，协商缓存登场。其核心是让客户端携带一个“资源指纹”向服务器询问：“我手上的副本还新鲜吗？” 最强大的指纹机制便是ETag（Entity Tag）。

ETag是一个由服务器生成的、唯一标识资源特定版本的字符串。它可以是：

• 强ETag：精确匹配资源字节内容（如文件的SHA-256哈希值）；

• 弱ETag：仅保证语义等价（如W/"123"），适用于动态生成但内容逻辑相同的资源。

工作流程如下：

1. 服务器首次响应时，在头部包含ETag: "abc123"；

2. 客户端后续请求时，在If-None-Match头中带上该ETag：If-None-Match: "abc123"；

3. 服务器比对当前资源ETag与请求中的值：

   • 若相同，返回304 Not Modified，响应体为空；

   • 若不同，返回200 OK及新资源与新ETag。

在Express中，可通过etag中间件自动生成ETag：

const app = express();
app.set('etag', 'strong'); // 或 'weak', false
​

Express默认使用弱ETag，基于响应体的MD5哈希（对Buffer）或字符串长度+校验和（对字符串）。这种实现兼顾了性能与准确性，但对于需要强一致性的场景（如API版本控制），开发者应手动设置强ETag：

app.get('/api/resource/:id', async (req, res) => {
  const resource = await db.find(req.params.id);
  const etag = crypto.createHash('sha256').update(JSON.stringify(resource)).digest('hex');
  res.set('ETag', `"${etag}"`);
  if (req.headers['if-none-match'] === `"${etag}"`) {
    return res.status(304).end();
  }
  res.json(resource);
});
​

ETag vs Last-Modified：精度之争

另一种协商缓存机制是Last-Modified/If-Modified-Since，它基于资源最后修改时间戳。然而，时间戳存在两大缺陷：

1. 精度限制：文件系统时间戳通常只精确到秒，若资源在1秒内多次变更，客户端可能获取过期副本；

2. 动态内容困境：对于数据库查询生成的动态内容，“最后修改时间”难以定义。

相比之下，ETag基于内容本身生成，天然规避了上述问题。正因如此，现代Web开发中ETag已成为协商缓存的首选。不过，ETag也非完美：生成强ETag需读取完整响应体并计算哈希，对大文件或高并发场景可能带来额外I/O与CPU开销。此时，结合Last-Modified作为快速路径（先比时间戳，再比ETag）是一种折中方案。

图：HTTP协商缓存决策流程

场景化策略：从静态资源到动态API

缓存与压缩策略绝非“一刀切”。不同资源类型、业务场景对性能与一致性的需求迥异，需量身定制。

静态资源：长期缓存 + 内容哈希

对于CSS、JS、图片等静态资源，最佳实践是：

• 设置极长的max-age（如1年）；

• 在文件名中嵌入内容哈希（如app.a3b8c2.js）；

• 通过HTML引用带哈希的资源URL。

如此一来，资源一旦发布即永久缓存，更新时因URL变更而自然失效。Express配合构建工具（如Webpack）可轻松实现此模式：

// Webpack 输出带哈希的文件
// HTML 中引用: <script src="/static/app.a3b8c2.js"></script>
app.use('/static', express.static('dist', {
  maxAge: '1y',
  etag: false // 因URL已含哈希，ETag冗余
}));
​

动态API：短时效缓存 + ETag验证

对于用户个人数据、实时行情等动态API，缓存策略需更谨慎：

• 设置较短的max-age（如10-60秒），平衡实时性与性能；

• 同时提供ETag，允许客户端在缓存过期后快速验证；

• 敏感数据标记为private，防止被共享缓存污染。

例如，一个用户资料接口可如此设计：

app.get('/api/profile', authenticate, async (req, res) => {
  const user = await getUser(req.user.id);
  const etag = generateETag(user); // 基于用户数据生成
  res.set({
    'Cache-Control': 'private, max-age=30',
    'ETag': `"${etag}"`
  });
  if (req.headers['if-none-match'] === `"${etag}"`) {
    return res.status(304).end();
  }
  res.json(user);
});
​

流式响应与压缩的冲突

值得注意的是，并非所有响应都适合压缩。对于流式传输（如视频直播、大文件下载），压缩可能导致：

• 无法预知最终大小，阻碍Content-Length设置；

• 压缩缓冲区阻塞流式输出，增加首字节时间（TTFB）。

此时，应显式禁用压缩：

app.get('/video', (req, res) => {
  res.set('Cache-Control', 'public, max-age=3600');
  res.removeHeader('Content-Encoding'); // 确保不被上游中间件压缩
  streamVideoTo(res);
});
​

最新进展与未来展望

随着Web技术演进，缓存与压缩领域亦在持续革新：

• Brotli普及化：得益于更高的压缩率，Brotli正逐步取代gzip成为静态资源压缩标准。Express虽原生支持有限，但可通过shrink-ray-current等第三方中间件集成。

• Cache API与Service Workers：在客户端，PWA技术栈提供了比HTTP缓存更灵活的Cache API，允许JavaScript精确控制缓存策略，实现离线优先体验。

• ESI（Edge Side Includes）：在CDN边缘节点进行动态内容拼接，结合细粒度缓存，进一步提升复杂页面的性能。

• HTTP/3与QPACK：新一代HTTP协议在头部压缩上采用QPACK算法，有望减少头部冗余，但对响应体压缩影响有限。

然而，技术演进并未削弱ETag与Cache-Control的基础地位。相反，它们作为HTTP协议的“元语”，将持续作为更高层优化的基石。正如一位资深架构师所言：“无论上层如何变化，理解并善用HTTP缓存，永远是Web性能优化的第一课。”

结语：在确定性与效率之间寻找平衡

响应压缩与缓存策略，表面看是技术细节的堆砌，实则蕴含深刻的工程哲学：在资源确定性与传输效率之间寻找最优平衡点。压缩牺牲CPU换带宽，缓存牺牲实时性换速度。优秀的工程师，不在于掌握多少中间件用法，而在于能根据业务上下文，精准判断何时该压缩、何时该缓存、以及缓存多久。

在Express的世界里，这些能力被封装得如此优雅，以至于我们几乎忘记了其背后的复杂性。但正是这份“简单”背后的深邃，值得我们反复咀嚼。毕竟，性能优化从来不是魔法，而是对协议、系统与用户需求的深刻洞察与精妙权衡。