HTTP 优化方案：连接复用、缓存、压缩和 SSL 加速怎么选

资料 第 149 页把 HTTP 优化方案列成五类：TCP 复用、HTTP 复用、内容缓存、压缩、SSL 加速。看起来像一个清单，但真正落到应用中，不能见一个开一个。每个方案解决的瓶颈不同，副作用也不同。

如果瓶颈是连接建立太多，优先看连接复用；如果瓶颈是同一个内容被反复取，优先看缓存；如果瓶颈是响应体太大，优先看压缩；如果 HTTPS 握手耗时明显，才重点看 TLS 会话复用、证书卸载和 SSL 加速。

优化的基本思路可以压成一句话：少建连、少传输、少计算。少建连减少握手和连接管理开销；少传输减少带宽和下载时间；少计算减少源站和应用服务器重复工作。

资料 对 TCP 复用的描述是：将多个客户端的 HTTP 请求复用到一个服务端的 TCP 连接上。这个说法常出现在代理、网关、负载均衡、连接池场景里。客户端很多，后端服务如果为每个请求都新建连接，握手、内核状态、文件描述符都会产生压力。

网关或代理可以维护到后端服务的一组长连接。前面来了很多客户端请求，网关不必每次都和后端重新三次握手，而是把请求转发到已有后端连接上。对后端来说，连接数量更稳定，建连成本更低。

这类优化最适合后端短请求很多、上游网关稳定、服务间调用频繁的系统。但连接池也要设置上限、空闲超时和健康检查。连接复用不是连接越多越好，池子太大同样会占资源，池子太小又会排队。

文中说 HTTP 复用是：将一个客户端的多个 HTTP 请求复用到一个 TCP 连接进行处理。前面讲 Keep-Alive 时已经见过这个思想。HTTP/1.1 的长连接可以让多个请求复用同一条 TCP 连接，减少重复握手和关闭。

HTTP/2 进一步把复用做得更彻底。它支持多路复用，多个请求和响应可以在同一条连接上交错传输，减少 HTTP/1.1 队头阻塞带来的等待。页面里有很多资源时，连接复用能明显减少建连和排队成本。

不过复用也有边界。单条连接如果被大响应占住，或者网络丢包严重，体验也可能受影响。实际应用中，要结合协议版本、浏览器行为、网关支持、请求大小和服务端并发能力一起看。

资料 对内容缓存的说法很简单：将经常用到的内容进行缓存，下次获取时就可以直接在内存中获取相应数据。这个方向在 HTTP 里非常重要，因为很多性能问题不是算不出来，而是重复算、重复查、重复传。

缓存可以放在很多位置。浏览器缓存能让用户第二次打开页面时少下载静态资源；CDN 缓存能让用户就近拿图片、CSS、JS；网关缓存能挡住一部分热点匿名接口；应用内存缓存能减少重复计算；后端缓存能减少数据库压力。

但缓存最怕两个问题：旧和错。旧是缓存时间太长，用户看不到更新；错是把不该缓存的个性化内容缓存了，甚至把一个用户的数据返回给另一个用户。缓存策略要和资源类型绑定，静态资源可以长缓存，登录态接口和用户私有数据要谨慎。

文中把压缩概括为：文本数据压缩，减少带宽。HTTP 响应里，HTML、CSS、JS、JSON、XML、SVG 这类文本内容通常压缩效果很好。启用 gzip 或 Brotli 后，传输体积可能明显下降，用户下载时间也会缩短。

压缩不适合所有内容。JPEG、PNG、MP4、ZIP 这类本身已经压缩过的文件，再压一次收益很小，反而浪费 CPU。大多数服务会按 MIME 类型和响应大小判断是否压缩，太小的响应压缩后未必划算。

排查压缩是否生效，可以看请求头 `Accept-Encoding` 和响应头 `Content-Encoding`。客户端声明支持 gzip、br，服务器返回对应编码，才说明链路上用了压缩。只看资源大小不够，还要看是不是经过 CDN 或代理二次处理。

资料 最后列了 SSL 加速。现在大多数网站都跑 HTTPS，TLS 握手、证书校验、密钥协商、加解密都会带来额外成本。单次看不一定夸张，高并发和大量短连接下就会明显。

SSL 加速常见做法包括 TLS 会话复用、证书卸载、网关终止 HTTPS、硬件加速或专用负载均衡设备。比如用户到 CDN 或网关走 HTTPS，网关负责处理 TLS，后端应用服务走内网连接，这样应用服务器不必承担全部加解密压力。

但 SSL 加速也要注意安全边界。TLS 在哪里终止，明文就从哪里开始出现。网关到后端是否还要 HTTPS，取决于内网可信程度、合规要求和威胁模型。不能为了省 CPU，把安全边界随便往前挪。

HTTP 请求不是只有浏览器和服务器两点。真实链路里可能有浏览器缓存、DNS、CDN、网关、负载均衡、应用服务器、缓存系统、数据库。优化要放回这条链路里看，才知道该动哪里。

如果 TTFB 高，说明浏览器等第一个字节等得久，可能是 CDN 回源慢，也可能是应用处理慢，还可能是后端查询慢。如果下载慢，要看资源体积、压缩、带宽和 CDN 节点。如果 TLS 耗时高，要看会话复用、连接复用和证书链。

如果连接数很多，要看 Keep-Alive、HTTP/2、多路复用和连接池。如果缓存命中率低，要看 `Cache-Control`、CDN 规则、URL 是否带版本号、查询参数是否导致缓存分散。不要只盯平均响应时间，一个指标很难说明全部问题。

缓存和压缩常常同时出现，但它们解决的问题不同。缓存是下次不再取，压缩是这次少传一点。一个资源如果能命中浏览器缓存，甚至不用发网络请求；如果必须发请求，压缩才能减少响应体体积。

CDN 也可能参与压缩。源站返回未压缩内容，CDN 根据客户端能力压缩后返回；或者源站已经压缩，CDN 直接缓存压缩版本。这里要注意 `Vary: Accept-Encoding`，否则不同客户端能力下可能拿到不合适的缓存版本。

发布前端静态资源时，比较稳的做法是文件名带 hash、设置长缓存、开启 gzip/br、通过 CDN 分发。内容变化后 URL 变化，缓存不会挡住更新；内容不变时，用户和 CDN 都可以放心复用。

连接复用减少建连成本，但不是没有代价。HTTP/1.1 长连接里，如果请求串行排队，前面的慢响应会影响后面的请求。HTTP/2 多路复用缓解了应用层队头阻塞，但如果底层 TCP 丢包，整个连接里的多个流仍可能受影响。

后端连接池也一样。连接池太小，请求会在网关或客户端排队；连接池太大，后端连接和内存压力上升。复用不是把连接数量降到越少越好，而是让连接数量稳定、可控，并和后端处理能力匹配。

所以看连接复用效果时，不只看连接数下降。还要看等待队列、连接池耗尽次数、后端响应时间、错误率和超时。如果复用后延迟反而变高，可能是池子容量或请求分配策略不合适。

如果被问 HTTP 优化方案，可以按 相关的五类回答：TCP 复用、HTTP 复用、内容缓存、压缩、SSL 加速。然后不要只背名词，要说每类解决什么问题。

TCP 复用主要减少客户端到后端或网关到服务端的连接建立开销；HTTP 复用让同一客户端多个请求复用同一条 TCP 连接，HTTP/2 还支持多路复用；内容缓存减少重复获取和重复计算；压缩减少文本响应体积；SSL 加速降低 HTTPS 握手和加解密成本。

最后补排查思路：先定位瓶颈再优化。建连多看 Keep-Alive、HTTP/2 和连接池；回源多看 CDN 和缓存规则；体积大看 gzip/br；TLS 耗时高看会话复用和证书链；TTFB 高看回源、应用处理和后端查询。