HTTP/2 多路复用真的快吗:一次 CDN 升级反而变慢的两周复盘

把 CDN 从 HTTP/1.1 升级到 HTTP/2,所有人都以为页面会加快,结果首屏时间反而从 800ms 涨到 1.2s,移动端弱网用户感受尤其明显。复盘了两周才搞明白,HTTP/2 的多路复用在某些场景下确实更慢,原因不是协议设计有问题,而是底层 TCP 的队头阻塞被放大了。这篇把这次升级失败的完整过程、HTTP/2 真实的优劣场景、几种修法的取舍、以及最后我们选择部分回退到 HTTP/1.1 的决策依据,完整讲一遍。看完之后,你应该能对协议升级这件事有更现实的认知,而不是盲目相信"新版本就是更好"。

故障现场

背景是一个图片密集型的电商首页,平均一个页面要加载八十多张商品图,加上 css、js、字体、API 请求,总计大约一百二十个资源。CDN 之前用的是 HTTP/1.1,开了 keep-alive 和 pipeline,浏览器每个域名建六条 TCP 连接,大概十秒内能加载完首屏。我们的优化目标是把首屏压到三秒以内,运维建议升级到 HTTP/2,因为社区资料都说"HTTP/2 的多路复用能解决 HTTP/1.1 的六连接限制,理论上更快"。

HTTP/2 多路复用的承诺和现实

HTTP/2 的核心卖点之一就是多路复用。在 HTTP/1.1 里,每个请求需要一条独占的 TCP 连接,浏览器为了避免阻塞最多对同一个域名建六条连接,超过的请求要排队。HTTP/2 把所有请求都塞进同一条 TCP 连接,通过流的概念逻辑上并发,理论上能省掉大量的连接建立成本,也没有六连接的限制。

但理论很美好,现实是所有流共享一条 TCP 连接,TCP 层的丢包会阻塞所有流。这就是著名的 TCP 队头阻塞问题。在弱网或者高丢包场景下,一个数据包丢了,TCP 会等到这个包重传成功之后才把后续数据交给应用层,期间所有 HTTP/2 流都被阻塞。HTTP/1.1 的多连接模型反而能避免这个问题,因为一条连接的丢包不影响其他连接。

抓包看到的真实数据

我们用 Wireshark 抓了几个典型用户的 TLS,在 HTTP 之上加一层 TLS 加密,防止中间人窃听和篡改。">HTTPS 流量,对比 HTTP/1.1 和 HTTP/2 的数据流。在 PC 端有线网络下,HTTP/2 确实更快,平均节省了大约一百毫秒。但在 4G 网络下,HTTP/2 反而比 HTTP/1.1 慢三百毫秒。在 3G 或者地铁这种间歇性丢包的场景下,差距更大,HTTP/2 比 HTTP/1.1 慢一秒以上。

# 用 curl 测试单连接 HTTP/2 性能
curl --http2 -w "@curl-format.txt" -o /dev/null -s https://example.com/page

# curl-format.txt 内容
time_namelookup:  %{time_namelookup}\n
time_connect:     %{time_connect}\n
time_appconnect:  %{time_appconnect}\n
time_pretransfer: %{time_pretransfer}\n
time_starttransfer: %{time_starttransfer}\n
time_total:       %{time_total}\n

# 模拟丢包测试 HTTP/2 队头阻塞
tc qdisc add dev eth0 root netem loss 5%
curl --http2 -o /dev/null -s https://example.com/manifest
tc qdisc del dev eth0 root

关键数据:无丢包时,HTTP/2 比 HTTP/1.1 快 100ms;5% 丢包时,HTTP/2 比 HTTP/1.1 慢 800ms。这个差距完全推翻了"HTTP/2 一定更快"的常识。我们当时被这个结果震惊了,因为社区资料几乎没有人提到这种弱网场景下的 HTTP/2 退化。

修法一:服务端推送(Server Push)

HTTP/2 提供了一个 Server Push 机制,允许服务端主动把客户端可能需要的资源推过去,避免往返。理论上这能减少请求数,缓解队头阻塞。我们试了之后发现,Server Push 在我们的场景下效果不明显,原因是大部分图片是动态计算出来的,服务端不知道客户端要哪些;而且 Server Push 容易推错,推了客户端已经缓存的资源,反而浪费带宽。

# Nginx 配置 HTTP/2 Server Push
location = /index.html {
    http2_push /style.css;
    http2_push /app.js;
    http2_push /logo.png;
}

# 但 Chrome 在 2022 年已经移除了 Server Push 支持
# 因为实际使用中负面影响多于正面

事实上,Chrome 已经在 2022 年移除了对 Server Push 的支持,理由是"实际使用中的负面影响多于正面"。这一变化让 Server Push 基本上失去了实用价值,只有少数 HTTP/2 客户端还支持。我们当时不知道这个变化,白费了一周时间调试 Server Push 配置,后来才发现 Chrome 早就不支持了。

修法二:开启 HTTP/2 的优先级和权重

HTTP/2 允许客户端给每个流指定优先级,服务端按优先级调度发送顺序。理论上重要资源(比如首屏 css)可以优先发送,次要资源(比如下方图片)往后排。但实际上各家浏览器、CDN、源站对优先级的实现差异极大,Cloudflare 做过一个研究发现至少有六种不同的优先级算法在线上运行,效果难以预测。

我们尝试在 Nginx 里调整优先级配置,但效果不稳定,有时候反而比默认配置更慢。后来发现 Nginx 在 1.20 版本前的 HTTP/2 优先级实现有 bug,会导致某些流被饿死。升级到 1.24 之后情况有所改善,但仍然不如 HTTP/1.1 的并发连接模型那么稳定可预测。这种"理论很美好但实现各异"的问题在 HTTP/2 生态里非常普遍,投入产出比不高。

修法三:HTTP/2 + 连接合并(Connection Coalescing)

HTTP/2 允许把多个域名指向同一个 IP 的请求合并到同一条连接里,这叫连接合并。对于大型站点用了多个 CDN 域名分流图片的场景,连接合并能减少连接数,提高 TLS 复用率。但合并的代价是所有请求都共享同一条 TCP 连接,队头阻塞更严重。在我们的场景下,合并之后弱网性能反而进一步下降。

# 查看浏览器是否对域名做了连接合并
# Chrome DevTools -> Network -> 看 Connection ID
# 同样的 Connection ID 表示用了同一条连接

# Nginx 启用连接合并需要证书覆盖所有域名
ssl_certificate wildcard.example.com.crt;
ssl_certificate_key wildcard.example.com.key;

连接合并在内网或者高质量网络下效果不错,但在公网弱网下是个反向优化。我们后来给图片域名单独配了证书,主动避免连接合并,首屏时间反而有所改善。这是个反直觉的优化,但符合 TCP 队头阻塞的原理:连接越多,丢包影响的范围越小。

修法四:升级到 HTTP/3(QUIC)

HTTP/3 的核心改进就是用 QUIC 替代 TCP。QUIC 在 UDP 上实现了类似 TCP 的可靠传输,但它的流是真正独立的,一个流的丢包不会阻塞其他流。这从协议层根本解决了 TCP 队头阻塞问题。理论上 HTTP/3 在弱网场景下应该明显优于 HTTP/2。

我们测试了几家 CDN 的 HTTP/3 支持,结果差异很大。Cloudflare 的 HTTP/3 实现成熟,在 4G 网络下确实比 HTTP/2 快 200ms 左右。但其他 CDN 的 HTTP/3 还在 beta 阶段,稳定性堪忧,某些请求会出现奇怪的延迟尖刺。考虑到我们当时正面临紧急修复需求,等待 HTTP/3 全面成熟不现实,最终选择了更务实的方案。

四种修法对比

我们最终的方案

经过两周的测试和分析,我们采取了一个混合方案:API 请求保留 HTTP/2,图片资源回退到 HTTP/1.1。理由是 API 请求数量少、响应大、对 TLS 握手开销敏感,适合 HTTP/2 的连接复用优势;而图片资源数量多、响应小、对队头阻塞敏感,在多连接的 HTTP/1.1 模型下表现更稳定。

具体实施是在 CDN 配置里把 api.example.com 走 HTTP/2,img.example.com 走 HTTP/1.1。这种"按场景选协议"的做法虽然违背了"协议升级一刀切"的工程惯性,但实测效果非常好,首屏时间回到 750ms,比升级前还快了 50ms,移动端用户投诉也基本消失。这次事故让我深刻意识到,没有银弹协议,只有更适合场景的协议。

HTTP/2 在哪些场景下确实更快

说了这么多 HTTP/2 的问题,公平起见也要承认它的优势场景。第一个场景是API 密集型应用,比如单页应用的后台请求,数量适中、响应小、需要低延迟。HTTP/2 的连接复用和头部压缩能显著降低 TLS 握手开销,首次访问可能比 HTTP/1.1 快几百毫秒。

第二个场景是高质量网络环境,比如内网服务之间的调用、数据中心内部通信。这种场景下几乎没有丢包,队头阻塞问题不存在,HTTP/2 的所有优势都能体现出来。我们公司的微服务之间全部用 HTTP/2,稳定性和性能都很好。

第三个场景是带宽受限但延迟低的场景,比如某些卫星链接或者移动专网。HTTP/2 的头部压缩能省下不少带宽,在带宽紧张的场景下效果显著。HTTP/1.1 的头部每次都要完整发送,在请求数量大时浪费严重。

第四个场景是需要服务端主动推送的实时场景。虽然 Server Push 已经不被推荐,但 HTTP/2 的多路复用配合 SSE(Server-Sent Events)或者 gRPC streaming 仍然能实现高效的实时通信。这种场景下 HTTP/2 的优势远超 HTTP/1.1,因为 HTTP/1.1 实现实时通信需要长轮询或者 WebSocket,代价更高。

HTTP/3 的真实状态

截至 2026 年,HTTP/3 的部署情况比一两年前好了很多,主要 CDN 都支持,主要浏览器也都默认开启。但实际使用中仍然有几个问题需要注意。第一个问题是中间设备的 UDP 支持,某些企业防火墙、运营商网关对 UDP 流量做了限速或屏蔽,HTTP/3 在这些网络下完全跑不通,会自动降级到 HTTP/2。这种降级在统计上看不出来,但用户体验上会有明显抖动。

第二个问题是CPU 开销。QUIC 的加密和拥塞控制都在用户态实现,比 TCP 的内核态实现 CPU 开销大不少。在高并发服务端,HTTP/3 的 CPU 占用率比 HTTP/2 高百分之三十到五十。这对成本敏感的业务来说是个负担,需要权衡性能提升和成本增加。

第三个问题是调试工具的成熟度。HTTP/2 的调试已经有完善的工具链,Wireshark、Chrome DevTools、nghttp 都支持得很好。HTTP/3 的调试工具还在发展中,某些场景下的问题排查比较困难。这对运维团队的能力是个挑战,小团队不一定有精力跟进。

第四个问题是客户端实现差异。各家浏览器、操作系统、应用 SDK 的 HTTP/3 实现还在快速演进,行为差异较大。同样的服务端配置,Chrome、Safari、Firefox 可能表现完全不同。这种碎片化让 HTTP/3 的真实性能很难预测,生产部署需要做大量的实际测试。

压测的正确姿势

协议升级之前必须做充分的压测,而且压测要模拟真实的用户网络环境,不能只在内网测。我们这次事故的根本原因之一就是压测环境没有模拟丢包,所有指标都在理想网络下采集,结果上线后真实用户的弱网场景完全没被覆盖到。后来我们专门搭了一套带网络损伤模拟的压测环境,加了丢包、延迟、抖动等参数,各种协议组合都跑一遍,然后再做决策。

# 用 tc 模拟弱网环境
# 5% 丢包 + 50ms 延迟 + 10ms 抖动
tc qdisc add dev eth0 root netem loss 5% delay 50ms 10ms

# 模拟 3G 网络
tc qdisc add dev eth0 root tbf rate 400kbit burst 4kbit latency 50ms
tc qdisc add dev eth0 parent root: handle 1: netem delay 300ms 50ms loss 2%

# 压测脚本(用 h2load 测 HTTP/2 性能)
h2load -n 10000 -c 100 -m 10 https://example.com/api/list

# 压测完恢复
tc qdisc del dev eth0 root

压测数据应该覆盖几个维度:不同网络质量、不同请求模式、不同负载。每种组合都要跑足够长的时间,采集 P50、P95、P99 各级延迟数据。看 P50 容易得出"HTTP/2 更快"的误导性结论,看 P95 和 P99 才能发现长尾问题。我们这次的教训就是只看了 P50,完全没看 P99,所以提前没发现弱网退化。

关于协议选型的几条经验

第一条经验是不要被"新版本就是更好"的惯性绑架。技术升级要看实际场景的契合度,而不是版本号。HTTP/2 在某些场景下确实更好,但不是所有场景。盲目升级可能带来反向优化,代价是用户体验下降和团队信任度下降。

第二条经验是压测要模拟真实环境。内网压测看不出真实问题,必须有网络损伤模拟。真实用户的网络质量分布远比开发者想象的复杂,弱网用户的占比可能比你以为的高很多。任何协议升级都要在弱网场景下验证,不然就是赌博。

第三条经验是不同资源类型可以走不同协议。没有规定一个站点必须用同一种协议,API 走 HTTP/2、图片走 HTTP/1.1、视频走 HTTP/3 都是合理的选择。按场景选协议虽然增加了运维复杂度,但能让每种资源都跑在最适合的协议上,整体效果最好。

第四条经验是关注协议生态的实际状态。Chrome 移除 Server Push 这种重要变化,不主动跟踪根本不知道。技术决策不能只看协议规范,还要看主流实现的实际状态。某个特性即使写在 RFC 里,如果没有客户端支持就是死代码。

性能数据对比

从数据能清楚看到三个协议各自的优劣。HTTP/1.1 在弱网下意外地稳定,HTTP/2 在理想网络下最快但弱网最慢,HTTP/3 综合表现最好但 CPU 开销大。这就是为什么我们最终选择按场景分协议,而不是统一升级。

团队立的几条规矩

1. 任何协议变更必须经过弱网压测,不允许只在内网测。
2. P99 延迟是核心指标,不允许只看 P50。
3. 不同资源类型可以独立选择协议,不必统一。
4. 新协议特性上线前要确认主流客户端实现状态。
5. HTTP/3 部署必须有 HTTP/2 降级方案,不能强制 HTTP/3。
6. 每月跑一次协议性能对比,数据驱动决策。

怎么在 Chrome 里观察真实的协议行为

除了 Wireshark 和命令行工具,Chrome DevTools 本身就是一个非常好的协议观察工具,大部分前端工程师只用了它的一小部分功能。打开 Network 面板,右键列头勾选 Protocol、Connection ID、Priority 这几列,刷新页面就能看到每个请求走的协议、用的连接、优先级。Connection ID 相同的请求是共享同一条 TCP 连接的,如果某条连接上挂了很多请求,就要警惕队头阻塞风险。

// 在浏览器控制台测试 HTTP/2 性能
async function testProtocolPerf(url, n=20) {
  const results = [];
  for (let i = 0; i < n; i++) {
    const start = performance.now();
    await fetch(url + '?cb=' + Math.random());
    results.push(performance.now() - start);
  }
  results.sort((a, b) => a - b);
  return {
    p50: results[Math.floor(n * 0.5)],
    p95: results[Math.floor(n * 0.95)],
    p99: results[Math.floor(n * 0.99)],
    max: results[n - 1]
  };
}

// 测试 HTTP/2 多路复用并发能力
async function testMultiplex(baseUrl, n=50) {
  const start = performance.now();
  const promises = [];
  for (let i = 0; i < n; i++) {
    promises.push(fetch(`${baseUrl}?i=${i}`));
  }
  await Promise.all(promises);
  return performance.now() - start;
}

Chrome 还有一个 net-internals 页面(地址栏输入 chrome://net-internals),里面有详细的 HTTP/2 和 HTTP/3 会话信息,可以看到每条连接的状态、每个流的优先级、丢包重传次数等等。这个页面对深度调试网络问题非常有用,但界面比较原始,需要一点学习成本。建议每个前端和运维工程师都花半天时间熟悉一下这个页面。

对未来网络协议的展望

网络协议的演进从来不是直线进步,而是不断在不同维度做取舍。HTTP/1.1 简单可靠但效率低,HTTP/2 高效但有队头阻塞,HTTP/3 解决队头阻塞但 CPU 开销大。下一代协议大概率会在 HTTP/3 的基础上做 CPU 优化,把加密和拥塞控制部分卸载到硬件,这是目前业界正在探索的方向。

另一个方向是更智能的拥塞控制算法。传统的 TCP CUBIC 算法在现代互联网环境下已经不够优秀,Google 推出的 BBR 算法在很多场景下表现更好。HTTP/3 因为是用户态实现,可以更灵活地切换拥塞控制算法,根据网络状况动态调整。这种灵活性是 TCP 时代不可能实现的,也是 QUIC 设计的精髓之一。

还有一个方向是跨层优化。HTTP/2 和 HTTP/3 都还是把网络协议和应用协议分开设计,未来可能出现更深度集成的方案,让应用层能直接感知和控制底层网络行为。这种方向虽然违背了 OSI 七层模型的分层原则,但在性能极致追求的场景下可能是必要的。技术演进往往就是这样,先分层简化,再合并优化,周而复始。

典型场景的协议选择决策表

把我们这段时间积累的经验整理成一张决策表,供同行参考。这个表不是绝对真理,只是基于我们的业务场景得出的实践总结,各位可以根据自己的情况调整。整体思路是按照资源类型和网络环境两个维度做决策,而不是简单地"全站用一种协议"。

API 类请求通常数量不多但延迟敏感,适合 HTTP/2 的连接复用和头部压缩。即使在弱网下,API 请求的总量也有限,队头阻塞影响相对小。我们项目的 API 全部走 HTTP/2,从 HTTP/1.1 切换过来之后,首次 API 调用平均快了 150 毫秒,主要是省了 TLS 握手开销。

静态资源密集型的页面适合 HTTP/1.1 多连接,特别是图片、字体这种小文件多的场景。一条连接出问题不会影响其他连接,弱网下表现稳定。如果你的页面有大量小图标、商品图、字体文件,先别急着升级 HTTP/2,在弱网压测里跑一下数据,可能会得到反直觉的结论。

视频流媒体场景适合 HTTP/3。视频对延迟敏感度低但对丢包敏感度高,QUIC 的独立流特性能够在丢包时保持视频帧的连续传输,避免卡顿。主流的视频平台目前都在大规模部署 HTTP/3,效果明显。如果你做的是视频业务,HTTP/3 几乎是必选项,不要犹豫。

实时通信场景比如直播、在线协作、游戏,这些场景对延迟和抖动都极度敏感,WebSocket 配合 HTTP/2 或者直接用 WebTransport(基于 QUIC)是更好的选择。这些协议比传统 HTTP 更适合长连接的实时通信,延迟可以做到几十毫秒以内。

给同行的几句心里话

做基础设施工作久了,越来越觉得协议层面的事情没有标准答案。每种协议都有自己的设计哲学和取舍,适用场景也不一样。盲目追新或者固守老技术都不可取,需要根据具体业务、具体网络环境、具体团队能力做综合判断。这种判断能力不是看几篇文章就能学会的,需要大量的实战经验和踩坑积累。

另一个心里话是不要害怕回退。我们这次从 HTTP/2 部分回退到 HTTP/1.1,在团队内部承受了不小压力,有人觉得"开倒车"。但数据说话,回退后的用户体验确实更好,这就足够了。技术决策应该数据驱动,不应该被"先进"或"落后"的标签绑架。能解决问题的方案就是好方案,不管它是新是旧。

最后想说的是,网络优化是个长期工程,没有一蹴而就的解决方案。每个项目都要根据自己的特点不断调整,持续观察,持续迭代。希望这篇文章能帮你少走一些弯路,在做协议选型时多一些数据支撑,少一些拍脑袋决定。如果你的项目正在考虑 HTTP/2 或 HTTP/3 升级,强烈建议先在弱网环境下做对照测试,数据会告诉你正确的方向。

事故复盘的几个深层反思

第一个反思是技术升级的决策机制需要改进。这次 HTTP/2 升级是运维团队提的建议,基于的是社区文章和最佳实践,但缺少针对我们具体业务的实测数据。后来我们建立了一个新流程,任何重大技术升级都要先做对照测试,在镜像环境跑至少一周,采集足够多维度的数据后才能上线。这个流程虽然增加了升级周期,但避免了一次又一次的"升级反而变慢"的尴尬。

第二个反思是真实用户监控的重要性。我们之前只看服务端的响应时间,看不到用户端的真实体验。后来在前端埋了 RUM(Real User Monitoring)代码,采集每个用户的首屏时间、资源加载时间、网络质量等指标。RUM 数据让我们第一次看到了真实用户的网络分布,弱网用户占比比想象中高得多,这彻底改变了我们的优化优先级。如果不做 RUM,你做的所有优化都是建立在猜测之上,效果再好也无法验证。

第三个反思是不同的角色对"快"的定义不同。产品经理关心首屏时间,后端关心服务端响应时间,运维关心 CDN 带宽利用率,用户关心整体感知速度。这些指标可能朝着不同方向变化,优化一个可能损害另一个。这次升级中,运维看到的连接数下降是好事,但用户感知的首屏时间变慢是坏事。技术决策必须建立在对齐目标的基础上,不然各方都觉得自己对,但事实证明大家都没看到全貌。

未来三年我们计划怎么做

基于这次事故的教训,我们规划了未来三年的网络基础设施演进路径。第一年的重点是把 RUM 体系完善,采集到足够多维度的真实用户数据,建立稳定的基线。有了基线之后,任何优化或变更都能用数据衡量效果,不再靠拍脑袋。第二年的重点是分场景部署 HTTP/3,先在视频和直播业务试点,验证效果之后逐步扩展到其他业务。第三年的目标是建立完整的协议自适应能力,根据用户的网络质量动态选择最优协议。

这个三年规划看起来很长,但网络基础设施的演进就是这样,不能一口吃成胖子。每一步都要有数据支撑、有备份方案、有回退路径。如果一次性切换太快,出问题的时候根本反应不过来。我们这次 HTTP/2 升级就是切换太快了,从灰度到全量只用了三天,导致问题暴露时已经影响了大量用户。如果灰度时间能长一些,可能就能在影响扩大前发现弱网退化问题。

另一个长期规划是培养团队的协议层调试能力。现在公司里能熟练抓包分析的人不多,大部分人遇到网络问题就只能看应用日志,看不出根本原因。我们准备每季度搞一次内训,讲讲 TCP、HTTP/2、TLS、QUIC 的底层细节,让更多人具备深度调试能力。这种能力短期看不出价值,但出大事时是救命稻草,值得长期投入。

总结

HTTP/2 的多路复用解决了 HTTP/1.1 的六连接限制,但带来了 TCP 队头阻塞放大的副作用。在弱网场景下,HTTP/2 反而比 HTTP/1.1 慢,这是协议升级前几乎没人提到的事实。HTTP/3 用 QUIC 替代 TCP 解决了队头阻塞,但 CPU 开销大、生态成熟度还在路上。最务实的做法是按场景选协议,API 走 HTTP/2,图片走 HTTP/1.1,视频考虑 HTTP/3,而不是一刀切升级。

这次事故让我深刻意识到,技术升级不是简单的版本号比较,而是复杂的场景适配。任何新技术上线前都要做充分的真实场景测试,不能只看理论指标。希望读完这篇你能对网络协议的选型有更现实的认知,在面对类似决策时多一份审慎,少一份盲目。技术世界里没有银弹,只有更适合当前问题的工具,找到那个最适合的工具就是工程师的核心价值所在。

—— 别看了 · 2026