chrome的timeline中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阶段过长，每每是丢包所致，这也意味着网络或服务端有问题。