内容纲要
标签：Browser,HTTP/1.1,HTTP/2,HTTP/3,并发连接,域名限制,前端性能,网络协议,Web优化,后端调优
一句话结论
- HTTP/1.1：现代主流浏览器通常对同一域名（同源）限制为 6 条并发连接（Chrome 官方企业文档明确写明每主机 6；Firefox 默认 6 的设置也长期存在业界共识）。(IETF Datatracker, daniel.haxx.se, kb.mozillazine.org)
- HTTP/2：不再靠“多连接”提速，而是在单连接内多路复用。并发上限由“并发流（streams）”控制：规范建议不少于 100，常见服务器默认 100–128（如 Apache=100，Nginx=128）。部分客户端还会有保护上限（社区报告 Chrome 约 256）。(IETF HTTP Working Group, httpd.apache.org, nginx.org, 谷歌群组)
- HTTP/3（QUIC）：同样依靠多路复用，建议同时允许至少 100 个请求流；不少实现的默认值=100（如 H2O）。(GitHub, h2o.examp1e.net)
“同一域名/同源”的常见定义是 scheme + host + port。HTTP/1.1 时代浏览器典型做法是“每源 6 连接”；HTTP/2/3 时代通常是一两条连接，里面跑很多流。(daniel.haxx.se)
为什么会有这个限制？
早期 RFC 2616（HTTP/1.1 旧规范）曾建议客户端每服务器不超过 2 条连接，后来实际实现普遍放宽为 6，以减轻队头阻塞并提升网页并行加载能力；而 HTTP/2/3 通过在**一条连接里开很多“流”**来并行请求，根本性缓解了“必须开多连接”的历史包袱。(IETF HTTP Working Group)
典型数值总览
| 协议 | 并发模型 | 典型客户端/服务端限制（常见默认） |
|---|---|---|
| HTTP/1.1 | 多条 TCP 连接并行 | 每主机 6（Chrome 官方文档）；Firefox 也长期默认 6（可调隐藏项）。(IETF Datatracker, kb.mozillazine.org) |
| HTTP/2 | 单连接内多路复用（并发流） | 规范建议 ≥100 流；Apache 100、Nginx 128 默认；部分客户端存在\~256 保护上限的社区报告。(IETF HTTP Working Group, httpd.apache.org, nginx.org, 谷歌群组) |
| HTTP/3（QUIC） | 单连接内多路复用（并发双向流） | 规范/实现普遍建议 ≥100 流；H2O 等服务器默认 100。(GitHub, h2o.examp1e.net) |
更细一点的解释
1) HTTP/1.1：6 条“每域名并发连接”从何而来？
- Chrome 官方企业网络文档写得很清楚：Maximum per Host = 6（同时还给出了每进程连接池上限 256、每代理 32等参数）。这就是你在实际抓包时常见的“同一主机顶多 6 条连接”现象的权威来源。(IETF Datatracker)
- Firefox 长期有
network.http.max-persistent-connections-per-server等隐藏配置，默认 6。(kb.mozillazine.org) - 业内文章也常用“每源 6 连接”来描述 HTTP/1.1 的现实实现。(daniel.haxx.se)
2) HTTP/2：看“连接数”已不准，要看“并发流”
- 多路复用把“并发”的颗粒度从“连接”变成了“流（streams）”。
- RFC 7540 / 9113 推荐：SETTINGS_MAX_CONCURRENT_STREAMS 不应小于 100。(IETF HTTP Working Group)
- 常见服务器默认：Apache=100、Nginx=128、nghttp2 工具链常见默认也在 100 左右。(httpd.apache.org, nginx.org, nghttp2.org)
- 客户端还会有保护上限：社区中有 “Chrome 约 256 并发流” 的讨论，意味着即使服务器给很高，客户端也可能收敛到内部阈值。(谷歌群组)
3) HTTP/3：语义相似，控制点不同
- HTTP/3 基于 QUIC（UDP），每个双向流独立，天然规避了 HTTP/2 在 TCP 上的应用层 HOL 阻塞。(gcore.com)
- RFC 9114及相关实现通常建议至少允许 100 个请求流；不少服务器（如 H2O）默认 100。(GitHub, h2o.examp1e.net)
实战建议（前端 & 后端）
前端/站点侧
- 优先启用 HTTP/2/HTTP/3，减少域名分片（domain sharding）。HTTP/2 下的 连接合并（connection coalescing） 能减少不必要的多连接。(daniel.haxx.se)
- 控制资源粒度：过多极小资源会在 HTTP/1.1 下撞“6 连接”天花板；在 H2/H3 下也会受“并发流”和优先级影响。合理打包、使用 HTTP/2 Push 的替代方案（Preload/早期提示）更稳。
- 善用浏览器提示（preconnect、dns-prefetch、preload）来让关键路径更顺畅（即便是 H2/H3 也有效）。
后端/运维侧
- 调好并发流上限：例如 Apache 的
H2MaxSessionStreams默认 100、Nginx 的http2_max_concurrent_streams默认 128，按站点画像酌情上调，但注意资源与 DoS 防护的平衡。(httpd.apache.org, nginx.org) - 关注安全公告：例如某些攻击（如 HTTP/2 Rapid Reset）会与流并发有关，厂商建议也会对并发参数提出保守值。(F5, Inc.)
- 压测再决定：并发流不是越大越好，CPU、内存、带宽与应用层队列都会成为瓶颈，上线前用真实资源图谱压测验证。
小结
- 如果你只想要一个数字：在 HTTP/1.1 下，“同一域名并发连接数”通常是 6。
- 在 HTTP/2/3 的世界里，请从“连接数”切换到“并发流”的思维：规范建议 ≥100，主流服务器默认 100–128，客户端也可能有自己的保护上限。
- 调优时兼顾前端加载策略与后端资源上限，以压测数据为准。
引用资料
- Google 官方：Chrome 企业网络参数（每主机 6、池 256、每代理 32）。(IETF Datatracker)
- RFC 7540 / HTTP/2：建议 SETTINGS_MAX_CONCURRENT_STREAMS ≥100。(IETF HTTP Working Group)
- Apache HTTP/2：
H2MaxSessionStreams默认 100。(httpd.apache.org) - Nginx HTTP/2：
http2_max_concurrent_streams默认 128。(nginx.org) - 社区案例：Chrome 并发流保护上限约 256 的讨论。(谷歌群组)
- RFC 9114 / HTTP/3 及相关实现：建议至少 100 并发流；H2O 默认 100。(GitHub, h2o.examp1e.net)
- “每源 6 连接”在 HTTP/1.1 的行业说明与 H2 连接合并解读。(daniel.haxx.se)
