4、HTTP/HTTPS性能：HTTP1.1 vs HTTP2 vs HTTP3、Keep-Alive与连接复用、TLS握手优化与延迟分析
聊到网络性能，HTTP 协议版本演进绝对是个绕不开的话题。很多团队花大价钱买了 CDN、升级了带宽，结果发现页面加载还是很慢。我排查过不少这类案例，最后发现根因往往出在 HTTP 协议本身——要么是连接没复用，要么是 TLS 握手太频繁。
这一节，我们就把 HTTP/1.1、HTTP/2、HTTP/3 的核心差异讲透，再聊聊 Keep-Alive 和 TLS 握手的优化手段。嗯，都是实战中能直接拿来用的东西。
4.1 HTTP/1.1：队头阻塞与连接复用
HTTP/1.1 其实已经做了不少优化，比如支持持久连接（Keep-Alive），不用每次请求都重新建 TCP 连接。但它的致命伤是队头阻塞（Head-of-Line Blocking）。
什么意思呢？同一个连接上，请求是串行的。前一个请求没响应完，后面的就得排队等着。哪怕后面的资源再小，也得等。
核心问题：HTTP/1.1 一个 TCP 连接同时只能处理一个请求。浏览器虽然可以开 6~8 个连接并行，但每个连接内部依然是串行的。
我在项目中遇到过这样一个场景：一个页面有 80 多个小图标和 CSS 文件，HTTP/1.1 下光排队就花了 2 秒多。后来用域名分片（Domain Sharding）把资源分散到多个域名下，才勉强缓解。但这其实是「拆东墙补西墙」——连接多了，TCP 和 TLS 握手的开销也上去了。
| 特性 | HTTP/1.1 | 说明 |
|---|---|---|
| 持久连接 | 支持（Keep-Alive） | 默认开启，减少 TCP 建连次数 |
| 队头阻塞 | 严重 | 同一连接请求必须串行 |
| 并行能力 | 依赖多连接 | 浏览器通常限制 6~8 个/域名 |
| 头部压缩 | 无 | 每次请求携带完整头部 |
4.2 HTTP/2：多路复用与头部压缩
HTTP/2 的出现，很大程度上就是为了解决 HTTP/1.1 的队头阻塞。它引入了多路复用（Multiplexing）——同一个 TCP 连接上，可以同时发送多个请求和响应，互不干扰。
说白了，就是一条高速公路上可以同时跑很多辆车，不用等前面的车下高速才能上。
另外，HTTP/2 还做了头部压缩（HPACK）。你想想看，HTTP/1.1 每次请求都要带一堆 Cookie、User-Agent 之类的头部，几百字节甚至几 KB 就没了。HTTP/2 用静态表和动态表来压缩，能省掉 80%~90% 的头部开销。
个人经验：我建议在升级 HTTP/2 时，先把域名分片去掉。因为 HTTP/2 的多路复用已经能充分利用单连接，分片反而会增加连接数，降低压缩效率。我曾经帮一个客户做迁移，去掉分片后首屏加载时间反而降了 30%。
但 HTTP/2 也有一个坑——它的多路复用是基于 TCP 的。如果 TCP 层丢包了，所有流都得等重传。这就是TCP 级别的队头阻塞。嗯，这个问题在弱网环境下特别明显。
4.3 HTTP/3：基于 QUIC 的终极方案
HTTP/3 直接把传输层从 TCP 换成了 QUIC（Quick UDP Internet Connections）。QUIC 基于 UDP，但实现了类似 TCP 的可靠传输、流量控制，还内置了 TLS 1.3。
为什么说它是终极方案？因为 QUIC 解决了两个老大难问题：
- 连接建立快：QUIC 的握手通常只需要 1-RTT，甚至 0-RTT（如果之前连接过）。而 TCP + TLS 1.3 最少也要 2-RTT。
- 无队头阻塞：QUIC 的流是独立的，一个流丢包不影响其他流。这在弱网环境下简直是救命稻草。
我记得有一次帮一个视频直播平台做优化，他们在东南亚地区的用户经常卡顿。升级到 HTTP/3 后，首帧时间从 4 秒降到了 1.2 秒。原因就是 QUIC 在丢包率 5% 的网络下，性能比 TCP 好太多了。
| 对比维度 | HTTP/1.1 | HTTP/2 | HTTP/3 |
|---|---|---|---|
| 传输层 | TCP | TCP | QUIC (UDP) |
| 多路复用 | 不支持 | 支持（TCP 级别有队头阻塞） | 支持（无队头阻塞） |
| 握手延迟 | 2~3 RTT | 2~3 RTT | 0~1 RTT |
| 头部压缩 | 无 | HPACK | QPACK |
| 部署难度 | 低 | 中 | 较高（需支持 UDP） |
4.4 Keep-Alive 与连接复用实战
Keep-Alive 是 HTTP/1.1 的默认行为，但很多人没用好。它的核心作用是复用 TCP 连接，避免每次请求都重新建连。
但 Keep-Alive 也不是越长越好。我见过有人把超时时间设成 600 秒，结果服务器上挂了几万个空闲连接，内存吃光，新连接反而进不来。
避坑指南：我曾经在一个高并发项目里，把 Keep-Alive 超时设成了 300 秒。结果高峰期服务器连接数飙到 5 万+，直接 OOM。后来调成 30 秒，配合连接池复用，连接数降到了 8000 左右，性能反而更好了。
关于连接复用，我建议你关注以下几点：
- 服务端：Nginx 的
keepalive_timeout建议设为 30~60 秒；keepalive_requests建议 1000 左右，避免单连接处理太多请求后内存碎片化。 - 客户端：使用连接池（如 Go 的
http.Transport、Java 的HttpClient），限制最大空闲连接数，避免无限创建。 - 监控：关注
ESTABLISHED和TIME_WAIT连接数。如果TIME_WAIT过多，说明连接复用率低，需要调大 Keep-Alive 或启用连接池。
# Nginx Keep-Alive 配置示例
http {
keepalive_timeout 30s; # 空闲连接超时
keepalive_requests 1000; # 单连接最大请求数
upstream backend {
server 10.0.0.1:8080;
keepalive 32; # 上游连接池大小
}
}4.5 TLS 握手优化与延迟分析
TLS 握手是 HTTPS 性能的「隐形杀手」。一次完整的 TLS 1.3 握手需要 2-RTT（TCP 三次握手 1-RTT + TLS 1.3 握手 1-RTT），而 TLS 1.2 需要 3-RTT。如果用户在地球的另一端，RTT 是 200ms，光握手就要 600ms。
怎么优化？我总结了几个实战经验：
- 启用 TLS 1.3：减少握手 RTT，且支持 0-RTT 恢复（但要注意重放攻击风险）。
- 会话复用：使用 Session ID 或 Session Ticket，让客户端在后续连接中跳过完整握手。我建议 Session Ticket 的有效期设为 2~4 小时。
- OCSP Stapling：服务端主动缓存证书状态，避免客户端去 OCSP 服务器查询。这个能省掉几十到几百毫秒。
- False Start：允许客户端在握手还没完全完成时就发送数据。TLS 1.3 默认支持，TLS 1.2 需要手动开启。
- 证书链优化：证书链不要超过 3 级，中间证书尽量合并。我见过有人挂了 5 级证书，握手时光证书传输就多了 10KB。
关键指标：TLS 握手时间应控制在 100ms 以内（本地测试），如果超过 300ms，说明需要优化了。可以用 curl -w "TCP handshake: %{time_connect}, TLS handshake: %{time_appconnect}" 来测量。
嗯，这里还要提一个容易被忽略的点——TLS 的密码套件选择。有些套件计算量很大，比如 ECDHE-RSA-AES256-GCM-SHA384，虽然安全，但握手耗时比 AES128-GCM 多了 30%~50%。我建议在安全性和性能之间取平衡，优先选 AES128-GCM 或 ChaCha20-Poly1305。
4.6 知识体系总览
下面这张图把 HTTP 协议演进、Keep-Alive 和 TLS 优化的核心逻辑串起来了。你可以把它当作排查性能瓶颈的「地图」。
4.7 小结
HTTP 协议的性能优化，说白了就是两件事：减少等待和减少开销。HTTP/2 的多路复用减少了等待，HTTP/3 的 QUIC 进一步消除了 TCP 级别的等待；Keep-Alive 和连接池减少了建连开销，TLS 优化减少了握手开销。
我个人建议的落地顺序是：先上 HTTP/2，再优化 TLS，最后根据业务场景评估是否升级到 HTTP/3。别一上来就追新，兼容性和改造成本也得算进去。
嗯，这一节的内容就到这里。记住，协议是工具，不是目的。你的目标是让用户更快地看到内容，而不是让协议版本号看起来更酷。