企业官网建设流程全解析

SSE流式传输中compress: true的陷阱与优化实践

场景：Node.js 服务通过 SSE 给前端实时推日志，打开compress: true后首包延迟飙到 1.2 s，Wireshark 一看——TCP 流里愣是等不到一个 FIN、也等不到一个 PSH。
结论：gzip 缓冲区把事件“憋”住了。本文记录踩坑→定位→优化的全过程，附可直接粘贴到 Koa 的中间件源码。

正文约 4 000 字，阅读时间 10 min，代码全部带 JSDoc，可直接复用。

1. 现象：打开 gzip 后 SSE “假死”

上线第二天，客服反馈“日志大屏”经常 10 s 才刷出第一条消息。复现步骤极简：

1. 服务端打开compress: true（koa-compress 默认配置）。
2. 浏览器new EventSource('/api/log')。
3. 抓包：Wireshark → Follow TCP Stream，能看到三次握手后服务端愣是 1 200 ms 才发第一帧数据，如图：

根因：gzip 流默认 8 k（或 16 k）才刷新一次，SSE 单条消息往往只有几百字节，于是被死死按在缓冲区里。
副作用：首包延迟↑、吞吐量↓、CPU 空转。

2. 技术方案：让压缩块“边压边吐”

2.1 原生压缩 vs 分块压缩

测试条件：4 核 8 G Docker，autocannon -c 100 -d 30s，消息大小 500 B，每秒 1 条。

2.2 核心：zlib.flush() 强制刷新

zlib 提供Z_SYNC_FLUSH可以在不关闭流的前提下把当前块推出去，SSE 正好借用它实现“分块压缩”。

关键代码（TypeScript）：

import { createGzip } from 'zlib'; import { Transform, TransformCallback } from 'stream'; /** * 将 gzip 流拆成“一块一条”模式，保证每条 SSE 消息及时刷新。 * 用法：res.write(data); gzipTransform.write(data); gzipTransform.flush(); */ export class SseGzipTransform extends Transform { private gzip = createGzip({ flush: constants.Z_SYNC_FLUSH }); constructor() { super(); this.gzip.on('data', chunk => this.push(chunk)); } _transform( chunk: any, encoding: BufferEncoding, callback: TransformCallback ): void { this.gzip.write(chunk, encoding, callback); } /** 手动刷新，确保压缩块立即输出 */ public flush(): void { this.gzip.flush(); } _destroy(error: Error | null, callback: TransformCallback): void { this.gzip.close(callback); } }

2.3 完整 Koa 中间件（含防泄漏）

import { Context, Next } from 'koa'; import { constants } from 'zlib'; /** * 只在 Accept-Encoding 包含 gzip 且响应类型为 text/event-stream 时启用 * @param threshold 最小字节数才压缩，以下直接透传 */ export function sseCompress({ threshold = 200 }: { threshold?: number } = {}) { return async (ctx: Context, next: Next) => { if (!ctx.acceptsEncodings('gzip')) return await next(); if (!ctx.type?.includes('text/event-stream')) return await next(); const gzip = new SseGzipTransform(); ctx.body = gzip; ctx.set('Content-Encoding', 'gzip'); ctx.set('Cache-Control', 'no-cache'); // 拦截 res.write，自动判断长度 const rawWrite = ctx.res.write.bind(ctx.res); ctx.res.write = function (chunk: any, encoding?: any) { if (chunk?.length >= threshold) { gzip.write(chunk, encoding); gzip.flush(); // 关键：及时推送 } else { rawWrite(chunk, encoding); } return true; }; await next(); // 确保流正确关闭，防止内存泄漏 ctx.res.on('close', () => gzip.destroy()); }; }

调优依据

• threshold=200：小于 200 B 的 heartbeat 包压缩收益不足，还浪费 CPU。
• Z_SYNC_FLUSH而非Z_FULL_FLUSH：后者压缩率略好但多 15 % CPU，得不偿失。
• 监听res.close事件：客户端断开即销毁流，避免积压。

3. 性能验证：autocannon 全量报告

3.1 测试脚本

# 优化前 autocannon -c 100 -d 30 -T 30 http://localhost:8000/api/log # 优化后 autocannon -c 100 -d 30 -T 30 http://localhost:8000/api/log

3.2 结果汇总

3.3 压缩级别对 CPU 的影响

结论：SSE 场景下 3 级是甜点，压缩率与 6 级相差 10 %，CPU 降 7 %。

4. 生产环境指南

4.1 Nginx 反向代理

• 关闭proxy_buffering off;否则 Nginx 也会等 4 k/8 k 才吐。
• 若同时开启gzip on;，一定加gzip_min_length 0;并排除text/event-stream，避免双重压缩。
• 建议让 Node 端自己压缩，Nginx 只做透传，减少一次gunzip → regzip的损耗。

4.2 浏览器兼容性

• 只有 HTTP/1.1 以上支持Transfer-Encoding: chunked+ gzip，IE11 需 TLS 1.2。
• 移动端 UC 浏览器 12.x 存在eventSource = null的 bug，需心跳包兜底。
• 若需支持 HTTP/2，可强制降级到不压缩，或走fetch + ND-JSON方案。

4.3 监控埋点

• 首包延迟：res.write第一个 chunk 到flush()完成时间。
• 压缩率：(原始字节 - 压缩后字节) / 原始字节。
• 错误率：监听gzip.on('error')与req.aborted，上报 Sentry。
• CPU 占比：通过process.cpuUsage()每 10 s 自采样，写入 Prometheus。

5. 小结 & 开放讨论

1. SSE 开启compress: true时，务必关注 zlib 缓冲区阻塞；
2. 通过自定义 Transform +flush()可以把压缩块及时推出去，首包延迟降 90 %；
3. 压缩级别、阈值、内存回收都要根据实际场景微调，切勿“一把梭”；
4. 生产链路里，Nginx、浏览器、监控缺一不可。

思考题：当链路全面切到 QUIC/HTTP3 时，UDP 自带流多路复用、队头阻塞更小，我们还需要“分块压缩”这种手工活吗？欢迎在评论区分享你的看法。

如果本文帮到了你，记得点个赞；踩坑日记持续更新，下一篇聊聊“WebSocket 0-RTT 的代价”。