队头阻塞问题其实在 [[016.HTTP 各版本差异|HTTP 各版本差异]] 中已经写的很详细了，本文再单独拿出来说一下

什么是队头阻塞问题？

队头阻塞是指在网络传输过程中，第一个数据包被阻塞导致后续所有数据包无法处理的性能瓶颈现象。这种问题发生在两个层面：

• HTTP 层：请求/响应队列阻塞
• TCP 层：单个丢包延迟后续数据

HTTP/1.1 中的具体表现：

• 浏览器限制 6 个 TCP 连接/域名
• 每个连接只能处理一个请求响应周期
• 前一个请求未完成时阻塞后续请求

HTTP/1.1 时代的优化策略

在 HTTP/2 普及前，工程师们使用多种策略缓解队头阻塞：

域名分片 (Domain Sharding)

// 通过多个子域名绕过连接限制
const assets = [
  'https://static1.example.com/image1.jpg',
  'https://static2.example.com/image2.jpg',
  'https://static3.example.com/image3.jpg'
];

效果：将 6 连接限制扩展到 18 个（3 个子域名 × 6）

资源合并 (Concatenation)

/* 合并多个 CSS 文件 */
@import url('reset.css');
@import url('header.css');
@import url('main.css');

精灵图 (Spriting)：

.icon {
  background-image: url('sprite.png');
}
.icon-home {
  background-position: 0 0;
  width: 32px;
  height: 32px;
}

核心思想：减少 HTTP 请求数量

HTTP/2 革命性突破

HTTP/2 协议从根本上解决了 HTTP 层的队头阻塞问题：多路复用 (Multiplexing) 机制

核心技术：

• 二进制分帧层
• 请求/响应流并行传输
• 流优先级控制

HTTP/3 与 QUIC 协议

HTTP/3 基于 QUIC 协议解决 TCP 层队头阻塞问题

关键创新点：

1. 基于 UDP 而非 TCP：绕过操作系统 TCP 协议栈，避免 TCP 队头阻塞
2. 独立流控制：一个流丢包和重传都不影响其他流的正常传输
3. 改进的拥塞控制：BBR (Bottleneck Bandwidth and Round-trip) 算法，更准确评估网络带宽

未来展望

WebTransport

WebTransport 可以理解为基于 HTTP/3 的 [[018.WebSocket|WebSocket]]

const transport = new WebTransport('https://example.com:443/');
const writer = transport.datagrams.writable.getWriter();
writer.write(new Uint8Array([...]));

机器学习预测优化

• 基于用户行为的资源预加载
• 动态调整并发流数量

客户端提示增强

Sec-CH-HTTP3-RTT: 150 
Sec-CH-Network-Efficiency: fast-3g