页面请求瀑布计算器

页面加载瀑布（waterfall）模型：总耗时 ≈ ⌈请求数 ÷ 并行数⌉ × 平均单请求耗时 + 关键路径依赖。HTTP/1.1 时代浏览器对每域名限 6 个 TCP 连接，20 个请求要排 4 轮——「减少请求数」成为性能优化第一定律：CSS Sprite 拼图、JS/CSS 合并打包、小图内联，全是这个约束的产物。HTTP/2（2015）的多路复用把单一 TCP 变成百路并发通道，20 个请求理论上 1 轮跑完——雪碧图与合并的最佳实践随之反转（过度合并反而浪费缓存粒度）。

但请求数依然重要，只是瓶颈换了位置：① 队头阻塞从 HTTP 层下沉到 TCP 层（丢包时全流阻塞，HTTP/3 QUIC 才根治）；② 每个请求有固定开销（DNS/TCP/TLS 握手对新建连接 1-3 个 RTT，HTTP/2 连接复用后摊薄但不归零）；③ 浏览器渲染调度开销（每资源解析、优先级仲裁）。现代心法：请求数从「越少越好」变为「按缓存与优先级分层」——关键 CSS/JS 内联或 preload，路由级代码分割按需加载，静态资源细粒度拆分吃满长期缓存。本工具按协议版本、请求数、RTT 估算瀑布总时长，对比三种协议的差异。

6 连接限制的历史由来：HTTP/1.1 规范建议浏览器对单一域名最多保持 2 个持久连接（防止服务器被打垮），现代浏览器放宽到 6 个——这是「雪碧图、合并打包、域名分片」三大上古优化术的共同源头。域名分片（static1/static2 各 6 连接）把并行度翻倍，代价是每域名独立承担 DNS+TCP+TLS 握手开销，还有 Cookie 随请求放大的副作用。

HTTP/2 的多路复用机制：单一 TCP 连接被切分成上百个逻辑流（stream），请求与响应切成帧（frame）交错传输、按流 ID 重组——20 个请求不再排队，同一个连接里并发跑完。附加收益：头部压缩（HPACK）省掉重复的 Cookie/UA 字节、服务端推送（已废弃）、流优先级。但物理层仍是一条 TCP：丢包时所有流一起等待重传，队头阻塞从 HTTP 层下沉到了传输层。

HTTP/3 的根治方案：基于 QUIC（UDP 之上自建可靠传输），每个流的丢包重传互不影响——彻底消灭队头阻塞；连接建立合并传输与加密握手，最快 0-RTT（此前访问过的站点首包即带数据）；连接由 Connection ID 标识而非 IP 四元组，Wi-Fi 切 5G 不断连。全球部署率已过半（Cloudflare/Google 系默认开启），对高丢包移动网络收益最大。边缘节点策略见 CDN 缓存命中率计算器。

现代的请求分层策略：把资源按「何时需要」分三层——关键层（首屏渲染必需：关键 CSS、LCP 图、首屏 JS）走内联或 preload，优先拿带宽；重要层（首屏交互必需：路由 JS）正常加载；延迟层（非首屏组件、统计、客服挂件）一律 defer/动态 import。分层的目标不是减少请求数，而是让有限的带宽与渲染时间先喂给关键路径。

第三方请求的隐形账单：统计、广告、字体、客服挂件，每个第三方域名都是一次完整的 DNS+TCP+TLS 握手（3 RTT），还带来不可控的性能与隐私变量。治理动作：每季度清点第三方清单（删僵尸挂件）、字体等静态资源自托管、非关键第三方统一 defer 或用 facade（先放占位图，点击再加载真身）。每删一个域名，首屏省一段握手、少一分不确定性。