Chrome中HTTP请求Stalled/Initial Connection耗时及多线程问题排查

一、什么时候会在这两个阶段耗时？ #

1. Stalled阶段卡壳的常见情况 #

• 浏览器同源并发限制：Chrome对同一个域名默认最多允许6个TCP连接同时工作，超出的请求会排队等位置，直接导致Stalled耗时
• 缓存相关阻塞：浏览器在发请求前要检查缓存是否可用，或者缓存锁被其他请求占用，得等锁释放
• 优先级抢占：页面的核心资源（比如CSS、JS）优先级更高，低优先级请求会被暂时卡住
• 代理/VPN拖后腿：代理服务器在转发请求前的协商、处理过程慢
• 预连接池不够用：浏览器提前建立的连接被占满，新请求得等空闲连接

2. Initial Connection阶段耗时的原因 #

• TCP三次握手慢：网络链路差（延迟高、丢包），或者服务器的TCP连接队列满了（没多余位置接新连接）
• DNS解析慢：如果域名没被浏览器缓存，DNS查询过程会拖慢这个阶段
• HTTPS握手耗时：SSL/TLS证书验证、密钥交换过程慢，比如证书链太长，或者服务器TLS配置低效
• 服务器响应慢：服务器负载太高，没法及时处理新的连接请求

3. 这两个阶段会导致同一请求多线程吗？ #

不会。这俩都是单个请求在连接建立前的等待/准备环节：

• Stalled是请求在浏览器端排队等可用连接，这时候请求根本没发到服务器，后端不可能创建线程
• Initial Connection是浏览器和服务器建立单个TCP连接的过程，正常情况下只会对应后端一个处理线程——除非后端有特殊的连接复用或线程池配置，但跟这两个阶段没关系

二、你的Angular+SpringBoot偶发问题排查方向 #

你说的“请求卡在这两个阶段时，后端出现同一请求多线程”，核心问题其实是浏览器端请求没正常发送/触发了重试，导致后端收到多个重复请求，才创建了多线程，不是这两个阶段直接搞出来的多线程。给你几个排查点：

1. 前端请求重试机制查一查 #

• 看Angular的HTTP拦截器或者HttpClient配置：是不是开了自动重试（比如用了retryWhen操作符）？当请求在Stalled阶段超时，就会自动重试，后端自然收到多个相同请求
• 检查浏览器自带的重试：TCP连接超时后，有些浏览器会自动重试请求
• 看Chrome DevTools的「Initiator」列：确认多个请求是前端代码主动发的，还是浏览器自己重试的

2. 后端SpringBoot配置排查 #

• 检查内嵌容器（比如Tomcat）的连接配置：server.tomcat.max-connections、server.tomcat.accept-count是不是设小了？连接队列满了的话，新连接会被拒，浏览器就可能重试
• 看请求处理线程池：server.tomcat.threads.max如果太小，请求会在后端排队，前端等不及就重试
• 核对log4j里的请求ID：确认多个线程对应的是同一个请求ID（就是重复请求），还是不同请求但业务参数一样，别搞混了

3. 网络和基础设施排查 #

• 测测客户端到服务器的网络稳定性：用ping、traceroute看看有没有间歇性丢包、高延迟，这会导致连接建立超时，触发重试
• 如果有负载均衡器：检查会话保持是不是失效了，健康检查有没有问题，会不会把请求重复转发
• 查CDN或代理服务器：有没有重复转发请求的情况

4. 偶发问题的复现技巧 #

• 前端加请求日志：记录每个请求的发送时间、状态、有没有重试，和后端日志的时间对比，看看重试是啥时候触发的
• 后端加全局请求ID：用拦截器生成唯一标识，打印到log4j里，清清楚楚区分重复请求和并发请求
• 抓包分析：问题发生时用Wireshark抓网络流量，看看是不是有重复的HTTP请求或者TCP连接重试

内容的提问来源于stack exchange，提问作者ADKL