HTTP 协议版本演进：从 TCP 连接到 QUIC

一、基础认知：TCP 连接与 HTTP 请求的关系

核心结论

一个 TCP 连接内可以发起多次 HTTP 请求，但具体行为取决于 HTTP 协议版本：

协议版本	连接复用	请求方式	队头阻塞	补充说明
HTTP/0.9	不支持（每次断开）	串行	存在	无 Header，仅 GET
HTTP/1.0	默认关闭	串行	存在	通过 `Connection: keep-alive` 实验性复用
HTTP/1.1	默认开启	串行（管道失败）	存在	管道要求响应按序返回，实际未普及
HTTP/2	单连接多路复用	并行	部分解决（TCP 层仍有）	二进制分帧 + 流优先级（支持不一）
HTTP/3 (QUIC)	单连接多路复用	并行	彻底解决	基于 UDP + 连接迁移 + 0-RTT

二、HTTP/1.x 时代：连接的困境与改进

HTTP/0.9（1991）

只有 GET 方法，无 Header，无状态码
响应必须是 HTML
每次请求完立即关闭 TCP 连接

HTTP/1.0（1996）

引入 POST、HEAD、状态码、Header
默认非持久连接：每个请求都需要新的 TCP 三次握手 + 慢启动
可通过 Connection: keep-alive 尝试复用（非标准，兼容性差）

HTTP/1.1（1997）

持久连接 （Persistent Connection）默认开启，通过 Connection: keep-alive 复用 TCP
但请求必须串行：发送请求 A → 等待响应 A → 发送请求 B
这就是队头阻塞（Head-of-Line Blocking）：一个慢请求会堵住后面所有请求

管道的失败尝试

HTTP/1.1 规范支持管道（Pipelining）：

客户端可以连续发送多个请求，不用等响应
但响应必须按请求顺序返回（致命缺陷）
实践中几乎没有浏览器开启（Opera 除外），服务器支持极差

管道是 HTTP/1.1 尝试解决队头阻塞的失败设计，最终被 HTTP/2 的多路复用取代。

三、浏览器的并发限制：为什么不是单一连接？

实际数据

现代浏览器对同一域名 通常会限制 6-8 个并发 TCP 连接。

为什么不用一个连接搞定？

理论上，HTTP/2 的一个连接可以处理所有请求，但现实中需要多个连接的原因：

跨域隔离：不同域名必须使用不同连接（浏览器安全策略）
协议降级：需要同时支持 HTTP/1.1（老旧的 CDN、第三方服务）
容错设计：单个连接故障不至于完全卡死页面
历史包袱：域名分片等旧优化策略仍在沿用
资源隔离：WebSocket、大文件上传等特殊场景

实践证明

经过大量测试，6-8 个连接是性能和资源消耗的最佳平衡点。更少则并发不足，更多则连接竞争带宽反而变慢。

常见错误优化

复制代码

// 错误：以为开多个子域名能提高 HTTP/2 并发
// 实际上 HTTP/2 一个连接就够，多子域名反而增加 DNS 和连接成本

正确做法：

HTTP/1.1 → 域名分片（多个子域名）
HTTP/2 → 尽量少域名，利用多路复用
HTTP/3 → 单一连接 + 连接迁移

四、一个常见的误解：fetch 能隔离连接吗？

错误示例

复制代码

// 这段代码不会创建新连接！
const highPriorityFetch = fetch('/api/critical');
const uploadStream = fetch('/upload');

这两次请求会复用同一个 TCP 连接（相同域名下）。普通 Web API 无法控制是否新建连接，这是浏览器的内部决策。

真正能隔离连接的方法

复制代码

// 方法1：不同子域名（不同连接）
const critical = fetch('https://api-primary.com/critical');
const upload = fetch('https://upload-api.com/upload');

// 方法2：不同端口（不同连接）
const fetch1 = fetch('https://example.com:443/api');
const fetch2 = fetch('https://example.com:8443/api');

// 方法3：WebSocket（独立连接）
const ws = new WebSocket('wss://example.com/ws');

开发者的无奈

连接隔离不是免费的------它意味着多个域名 = 多个后端/多个部署。

小项目：单个域名，接受共享连接（够用就好）
中项目：2-3 个子域名，主要分离静态资源
大项目：微服务架构，大量子域名（Google、Facebook 级别）

五、HTTP/2 的突破：多路复用

核心特性

HTTP/2 在一个 TCP 连接内实现了多路复用（Multiplexing）：

多个请求可以同时发送
响应可以交错返回
彻底解决了 HTTP/1.1 的应用层队头阻塞

二进制分帧

HTTP/2 将请求/响应拆分为独立的帧（Frame），每个帧属于特定的流（Stream）。不同流的帧可以交错传输，接收端再重新组装。

优先级和依赖树（很少被讲清楚）

每个流可以指定权重（1~256）和依赖（另一个流 ID）
客户端可以告诉服务器："先发 CSS，再发图片"
实践中很多服务器忽略优先级，且 HTTP/2 标准未强制要求

实际经验：不要过度依赖 HTTP/2 优先级 ，关键资源还是用 <link rel=preload> 或直接放在 HTML 中更可靠。

但仍有遗憾：TCP 层队头阻塞

一个 TCP 连接中，数据是串行传输的。如果一个数据包丢失（即使只属于流 1）：

流 2、流 3 的数据已到达接收端缓存
但 TCP 的有序交付机制不允许上层读取，直到丢包重传完成
整条连接的所有请求都得停下来等待

在丢包率 1%~2% 的弱网下，HTTP/2 可能比 HTTP/1.1 多连接更慢（因为 1.1 的多连接天然隔离了丢包影响）。

六、HTTP/3 的革命：QUIC 协议

核心思想

放弃 TCP，改用 UDP + 用户态可靠传输协议（QUIC）

关键实现

1. 更快的连接建立

首次连接：1 个 RTT（比 HTTP/2 少 1-2 轮握手）
再次连接：0-RTT，直接发送数据

2. 彻底解决队头阻塞

QUIC 为每个请求提供独立的流（Stream）：

每个流内部有序
流之间相互隔离
一个流丢包不影响其他流

3. 连接迁移（移动网络神器）

使用连接 ID（Connection ID）而不是 IP+端口标识连接：

Wi-Fi 切 5G：连接不断
地铁换乘：视频不卡
高铁/地铁场景：IP 频繁变化，TCP 必断（需 1-2 RTT 重连），QUIC 无感知

4. 灵活的拥塞控制

QUIC 在用户态实现拥塞控制：

可以像更新 App 一样更新算法
可以根据网络环境动态切换
无需升级操作系统内核

架构对比

特性	HTTP/1.1	HTTP/2	HTTP/3
传输层	TCP	TCP	QUIC (UDP)
连接建立	多次 RTT	多次 RTT	0-1 RTT
队头阻塞	存在	存在（TCP层）	已解决
连接迁移	不支持	不支持	支持
协议更新	慢（内核级）	慢（内核级）	快（用户态）
TLS 要求	可选	强制（浏览器）	强制 TLS 1.3

实际效果

Google 测试数据 ：HTTP/3 在弱网下比 HTTP/2 降低 30%+ 延迟
主流浏览器和服务器（Nginx 1.25+、Cloudflare）均已支持
Facebook：75%+ 流量使用 HTTP/3
阿里巴巴：双十一大规模应用

安全与兼容提醒

HTTP/2 必须使用 TLS（虽然规范允许明文 h2c，但浏览器不支持）
HTTP/3 强制 TLS1.3，且 UDP 可能被企业防火墙/运营商 QoS 降速（仍需降级到 HTTP/2）
Nginx 1.25+ 支持 HTTP/3，但配置复杂度高于 HTTP/2

七、实践决策树与建议

决策流程图

复制代码

是否需要支持 IE11 / 老旧系统？
├─ 是 → 使用 HTTP/1.1 + 域名分片（最多 6 个）+ 打包合并请求
└─ 否 → 是否主要用户为移动端/弱网？
    ├─ 是 → 优先支持 HTTP/3（QUIC），降级到 HTTP/2
    └─ 否 → HTTP/2 足够，关注 TCP 队头阻塞（丢包率 < 0.5% 时可忽略）

场景建议

场景	建议方案
中小型项目	单域名 + HTTP/2，接受共享连接
大文件上传	分片上传 + 异步处理，避免阻塞关键 API
关键 API	独立子域名（如有预算），或使用 HTTP/2 优先级
实时通信	WebSocket 独立连接
移动端/弱网	优先支持 HTTP/3
静态资源	独立域名 + CDN（天然隔离）
内网服务（丢包率极低）	HTTP/2 性能接近 HTTP/3，升级收益不大
跨国/卫星/4G 弱信号	HTTP/3 收益明显（30-50% 延迟降低）
长连接场景（WebSocket、SSE、GRPC Stream）	HTTP/3 的 0-RTT 重连优势巨大

八、核心知识点回顾

一个 TCP 连接可以发多次 HTTP 请求，但协议版本决定方式
浏览器限制 6-8 个并发连接是多方面因素平衡的结果
普通 fetch 无法控制连接隔离，需要跨域/跨端口
HTTP/2 解决应用层队头阻塞，但 TCP 层仍在
HTTP/3 用 QUIC 彻底重构，弱网环境提升 30%+
管道（Pipelining）是 HTTP/1.1 的失败设计
HTTP/2 优先级在实践中支持不一，不要过度依赖
内网 vs 公网、弱网 vs 光纤 的选择维度不同

九、一句话总结

HTTP/1.1 解决的是连接成本，HTTP/2 解决的是请求顺序，HTTP/3 解决的是传输层的生死依赖。

每一次升级都在剥离上一代的隐含假设：网络不再可靠，延迟不再固定，而你的应用必须感知这一切。