chrome的timeline中stalled问题解析

原文地址 ：http://foio.github.io/chrome-stalled/

在公司国做一个运营活动，上线后PM总是抱怨访问速度过慢，影响运营效果。然而从前端的角度来说我已经做了如下优化： css、js合并压缩、图片压缩、雪碧图、静态资源全部上CDN。但是依然很慢，实在s是困惑，通过chrome的timeline分析，发现有些请求确实很慢，但是大部分时间消耗在stalled阶段。如下图:

下文来分析具体原因。

---

什么是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连接建立完成，到真正可以传输数据之间的时间差。先让我们要分析TCP连接为什么要等待这么久才能用？我用Wireshark抓包发现(如下图)，TCP连接过程中有多次重传，直到达到最大重传次数后连接被客户端重置。

为什么会发生重传呢？

The sender waits for an ACK for the byte-range sent to the client and when not received, resends the packets, after a particular interval. After a certain number of retries, the host is considered to be “down” and the sender gives up and tears down the TCP connection.

TCP三次握手后，发送端发送数据后，一段时间内（不同的操作系统时间段不同）接收不到服务端ACK包，就会以 某一时间间隔(时间间隔一般为指数型增长)重新发送，从重传开始到接收端正确响应的时间就是stalled阶段。而重传超过一定的次数（windows系统是5次），发送端就认为本次TCP连接已经down掉了，需要重新建立连接。 对比以下，没有重传的http请求过程。如下图：

总结一下：stalled阶段时TCP连接的检测过程，如果检测成功就会继续使用该TCP连接发送数据，如果检测失败就会重新建立TCP连接。所以出现stalled阶段过长，往往是丢包所致，这也意味着网络或服务端有问题。