3. 网络基础：HTTP/1.1、HTTP/2、HTTP/3 协议对比与延迟优化
做抢单系统，最怕什么？
不是并发高，是延迟大。你想想看，用户手指点下去，结果转圈转了3秒，单子早被别人抢走了。我这些年调过的抢单系统，十有八九的瓶颈不在数据库，而在网络层。说白了，网络协议选不对，后面再怎么优化都是白搭。
今天我们就来聊聊 HTTP 协议的三个版本。我会结合自己在抢单场景下的实战经验，帮你理清楚每个版本的优缺点，以及怎么选型才能把延迟压到最低。
核心观点：抢单系统的网络延迟优化，本质上是「减少握手次数 + 降低队头阻塞 + 压缩传输体积」。HTTP/3 在这三点上做得最好，但迁移成本也最高。
3.1 HTTP/1.1：老当益壮，但坑不少
HTTP/1.1 是 1997 年的协议了。说实话，到现在还有大量系统在用。它的核心问题是：一个连接同时只能处理一个请求。
什么意思呢？就是你发一个请求，必须等响应回来，才能发下一个。如果中间有网络延迟，那就干等着。浏览器为了解决这个问题，搞了个「管线化」（Pipelining），但实际效果很差——因为队头阻塞（Head-of-Line Blocking）依然存在。
我记得有一次帮一个电商团队排查抢单接口，发现他们的 HTTP/1.1 连接数开到了 30 个。我问为什么，他们说「一个连接不够用啊」。嗯，这就是典型的用数量换质量。但连接数多了，TCP 的慢启动和拥塞控制又会拖慢速度。
我的建议：如果系统还在用 HTTP/1.1，至少要做到两点：一是开启 Keep-Alive 复用连接，二是把静态资源和 API 请求分开域名。这样能减少连接建立的开销。
HTTP/1.1 的延迟瓶颈，我总结为三点：
- 串行请求：一个连接一次只能处理一个请求，后面的请求排队等
- 头部冗余：每次请求都带一堆重复的 Header，Cookie 动不动几 KB
- 队头阻塞：一个请求卡住，后面所有请求都跟着遭殃
在抢单场景下，HTTP/1.1 的延迟通常在 200ms-500ms 之间（取决于网络环境）。这个数字对于秒杀来说，太慢了。
3.2 HTTP/2：多路复用，但 TCP 拖了后腿
HTTP/2 在 2015 年成为标准。它最大的改进是多路复用——一个连接可以同时处理多个请求，不再需要排队了。
怎么做到的？它把请求和响应都拆成一个个「帧」（Frame），然后在同一个 TCP 连接里交错传输。你发请求 A 和请求 B，服务器可以同时处理，然后按顺序或者乱序返回。客户端再根据帧的标识重新组装。
听起来很完美对吧？但我在项目中遇到过一个问题：TCP 层面的队头阻塞。
为什么会这样？因为 HTTP/2 虽然解决了应用层的队头阻塞，但底层还是 TCP。TCP 是保证有序传输的，如果某个数据包丢了，它必须重传，重传期间后面的数据包都得等着。哪怕这些数据包属于不同的请求，也得等。
我举个例子：你同时发了 10 个抢单请求，其中一个请求的某个包丢了。TCP 会卡住，直到那个包重传成功。其他 9 个请求明明数据都到了，但就是不能处理。你说气不气人？
避坑指南：我曾经在一个抢单项目里用了 HTTP/2，结果发现弱网环境下延迟反而比 HTTP/1.1 还高。后来排查发现，就是因为 TCP 的丢包重传机制。如果你的用户群体中有大量移动端（4G/5G 信号不稳定），HTTP/2 不一定比 HTTP/1.1 好。
HTTP/2 的其他改进：
- 头部压缩：用 HPACK 算法压缩 Header，体积能减少 80% 以上
- 服务器推送：服务器可以主动把客户端可能需要的资源推过去（但抢单场景用得少）
- 二进制分帧：不再是文本协议，解析效率更高
在抢单场景下，HTTP/2 的延迟可以降到 100ms-200ms。但前提是网络质量好，丢包率低于 0.1%。
3.3 HTTP/3：基于 QUIC，专为低延迟而生
HTTP/3 是 2022 年才正式成为标准的。它最大的变化是：底层不再用 TCP，而是用 QUIC。
QUIC 是基于 UDP 的。UDP 本身不保证可靠传输，但 QUIC 在 UDP 之上自己实现了可靠传输、拥塞控制、加密等功能。这样一来，它绕过了 TCP 的很多固有限制。
HTTP/3 的核心优势：
- 0-RTT 握手：第一次连接只需要 1 个 RTT，后续连接可以做到 0-RTT。对比 HTTP/1.1 和 HTTP/2 的 3 次握手 + TLS 握手（至少 2-3 个 RTT），差距巨大
- 无队头阻塞：QUIC 的传输单位是「流」（Stream），每个流独立。一个流丢包了，不影响其他流
- 连接迁移：IP 地址变了（比如从 WiFi 切到 4G），连接不会断开。抢单场景下用户可能边走边抢，这个特性很实用
我记得有一次帮一个金融客户做抢单系统优化，他们要求延迟必须低于 50ms。我们试了 HTTP/1.1 和 HTTP/2，都不达标。最后切到 HTTP/3，延迟直接降到了 30ms 左右。嗯，效果立竿见影。
我的建议：如果你的抢单系统面向的是全球用户，或者移动端用户占比高，强烈建议上 HTTP/3。虽然迁移成本高（需要服务端支持 QUIC，客户端也要适配），但延迟收益非常明显。
3.4 三版协议对比：一张表看懂
| 特性 | HTTP/1.1 | HTTP/2 | HTTP/3 |
|---|---|---|---|
| 底层协议 | TCP | TCP | QUIC (UDP) |
| 多路复用 | 不支持 | 支持 | 支持 |
| 队头阻塞 | 应用层 + 传输层 | 传输层 (TCP) | 无 |
| 握手延迟 | 2-3 RTT | 2-3 RTT | 0-1 RTT |
| 头部压缩 | 不支持 | HPACK | QPACK |
| 连接迁移 | 不支持 | 不支持 | 支持 |
| 抢单场景延迟 | 200-500ms | 100-200ms | 30-80ms |
| 迁移成本 | 低 | 中 | 高 |
3.5 核心逻辑：一张图看懂
下面这张 SVG 图展示了三个协议在抢单场景下的核心差异。我把它画成了从「用户点击」到「服务端处理」的完整链路，你可以直观地看到每个版本的延迟瓶颈在哪里。
3.6 抢单场景下的选型建议
说了这么多，到底该选哪个？我直接给结论：
- 新系统，从零开始：直接上 HTTP/3。虽然前期适配工作多，但后面省心。我最近两个项目都是这么干的。
- 已有系统，网络稳定：升级到 HTTP/2。改动量不大，延迟能降一半。但要注意，如果用户群体在弱网环境多，HTTP/2 可能不如 HTTP/1.1。
- 已有系统，网络不稳定：继续用 HTTP/1.1，但要做好连接池优化和域名拆分。同时规划向 HTTP/3 迁移。
- 极端低延迟要求（<50ms）：别犹豫，直接上 HTTP/3。配合边缘计算节点（CDN），延迟能压到 20ms 以内。
注意：HTTP/3 目前还不是所有中间件都支持。比如一些老旧的负载均衡器、防火墙、代理服务器，可能对 QUIC 协议处理不好。我在一个项目中就遇到过，切到 HTTP/3 后，某个中间件把 QUIC 包当成了 UDP 攻击流量给丢了。嗯，排查了整整两天。
最后说一句：网络协议优化只是抢单系统的一部分。后面我们还会聊到连接池、序列化、CDN 加速等内容。但如果你能把 HTTP 协议选对，延迟优化就已经成功了一半。
一句话总结：HTTP/1.1 是马车，HTTP/2 是汽车，HTTP/3 是高铁。抢单系统要跑得快，选高铁准没错。
公众号:蓝海资料掘金营，微信deep3321