昨天，当我美滋滋的在划水等着下班迎来我“五一”小长假的时候，突然有人找上来了。
有人跟我反馈一个问题，是说“浏览器在对同一页页面tab超过五个的时候，就出现了明显的卡顿，加载慢的问题”
本着对非专业人员表达能力质疑的态度，我重试了一下她的骚操作，发现他们反馈的话果然不能完全信，但也不能完全不信。并不存在卡顿，CPU也没有明显升高，但确实出现了加载慢的问题
image.png
于是我试着慢动作开tab，每个tab在间隔5秒的时间再去新开，发现加载速度明显上来了。这不禁让我对之前“浏览器对同一个域名的最大并发请求数”的理解出现了质疑。
一直以来我理解的是：浏览器对同一个域名的最大并发请求数的相对于一个进程而言。但是我质疑了，到底这个最大并发请求数指的是“整个浏览器”还是对于某一个进程的？
image.png
我细看了每个请求，确定了之前我的理解是正确的，因为这个时候并不是浏览器阻塞了请求发出，请求的queueing 只花了0.93ms，而connection后才是花了大量的时间。
但是这个耗费了那么多时间的stalled，到底是什么东西？
Time the request spent waiting before it could be sent. This time is inclusive of any time spent in proxy negotiation.Additionally, this time will include when the browser is waiting for an already established connection to become available for re-use, obeying Chrome’s maximum six TCP connection per origin rule.
准确的说，就是从TCP连接建立完成，到真正可以传输数据之间的时间差。而此时在Stack Overflow上我看到有前端在Chrome浏览器上同样面临着这个问题，为了不被后台打脸，我点进去看了下
this behavior is due to Chrome locking the cache and waiting to see the result of one request before requesting the same resource again. The answer is to find a way to make the requests unique. I added a random number to the query string, and everything is working now.
显然这不是我的问题，因为我早已经对每个请求都增加了?r=随机数的操作，而且这种情况只会出现在Chrome浏览器，但是我的问题是在任何浏览器都会重现
最后总结：
stalled阶段是TCP连接的检测过程，如果检测成功就会继续使用该TCP连接发送数据，如果检测失败就会重新建立TCP连接。所以出现stalled阶段过长，往往是丢包所致，这也意味着网络或服务端有问题。
最后证明确实是后台的问题，说是实习生在做这个操作的时候并没有加索引导致查询很慢。
参考：
网友评论