浏览器域名分片

早期通过拆分静态资源到多个域名来绕过并发限制的性能优化手段，现多与 CDN、HTTP/2 组合讨论。

#type / concept #status / seed #tech / dev / frontend

[!info] related notes

所属 MOC: http-and-frontend-networking-moc, frontend-performance-optimization-moc

相关协议: HTTP1.1 vs HTTP2

相关技术: CDN 加速

浏览器域名分片

浏览器域名分片（Domain Sharding）：将页面中的静态资源（图片、CSS、JS 等）分散到多个子域名下加载，以绕过浏览器对单域名并发连接数的限制，从而提升页面加载速度。

为什么需要域名分片

HTTP/1.1 时代的限制：

浏览器对单域名的并发连接数限制：

Chrome  → 6 个
Firefox → 6 个
Safari  → 6 个
IE      → 6~8 个（视版本）

当一个页面有 30 个资源，单域名下只能同时下载 6 个，其余排队等待。域名分片通过增加域名数量来扩展并发通道：

不分片: 6 个连接 × 1 个域名 = 并发 6 个资源

域名分片:
  static1.example.com  → 6 个连接
  static2.example.com  → 6 个连接
  static3.example.com  → 6 个连接
  → 并发 18 个资源

实现模式

<!-- 将资源分散到多个子域名 -->
<img src="https://static1.example.com/images/a.png">
<img src="https://static2.example.com/images/b.png">
<link href="https://static1.example.com/css/main.css">
<script src="https://static2.example.com/js/app.js">

通常使用 2~4 个子域名，过多反而增加 DNS 查询和连接建立的开销。

为什么 HTTP/2 让它过时

HTTP/2 引入了多路复用（Multiplexing）：

HTTP/1.1（需要域名分片）:
  连接1: [====资源A====]
  连接2: [====资源B====]
  连接3: [====资源C====]    → 需要多个连接来并发
  ...

HTTP/2（单连接多路复用）:
  连接1: [A1][B1][C1][A2][B2][C2][A3]...  → 一个连接即可并发所有资源

对比项	HTTP/1.1 + 域名分片	HTTP/2
TCP 连接数	多个（每个域名一个）	通常 1 个
DNS 查询	多次	少量
TLS 握手	每个连接各一次	仅一次
队头阻塞	仍存在（每连接内）	大幅缓解（帧级别）
资源优先级	无法精细控制	支持流优先级
额外开销	多个连接的内存和 CPU	单连接，更高效

HTTP/2 下域名分片反而有害：多个域名 = 多个 TCP 连接 = 失去了多路复用的优势，还额外增加了 DNS 查询和 TLS 握手的开销。

现在何时可能仍然适用

兼容 HTTP/1.1 的老旧客户端/CDN：某些场景仍需兼容旧协议
CDN 域名数量限制：部分 CDN 对单域名有带宽限制，可能需要分片
特定浏览器限制：极少数嵌入式浏览器仍遵循旧的连接限制
HTTP/3 (QUIC) 进一步消除了这个问题：基于 UDP，无 TCP 队头阻塞

边界与常见误解

域名分片不是越多越好：每个额外域名意味着额外的 DNS 查询 + TCP 连接 + TLS 握手，通常 2~4 个最优
HTTP/2 下不需要手动分片：浏览器和服务器会自动处理多路复用
域名分片和 CDN 是不同概念：CDN 是内容分发，域名分片是并发优化；CDN 自然带有多域名特性
CSS sprite / 内联资源 也是减少并发需求的替代方案

浏览器域名分片

为什么需要域名分片

实现模式

为什么 HTTP/2 让它过时

现在何时可能仍然适用

边界与常见误解

相关笔记