Stalled/Blocking
在请求能够被发出去前的等等时间。包含了用于处理代理的时间。另外，如果有已经建立好的连接，那么这个时间还包括等待已建立连接被复用的时间，这个遵循Chrome对同一源最大6个TCP连接的规则。
「拿我们的情况来说，上面出错所有的耗时也是算在了这部分里面。网络面板中显示的其余时间比如DNS查找，连接建立等都是属于最后那次成功请求的了」
Proxy Negotiation
处理代理的时间。
DNS Lookup
查找DNS的时间。页面上每个新的域都需要一次完整的寻路来完成DNS查找。
Initial Connection / Connecting
用于建立链接的时间，包括TCP握手及多次尝试握手，还有处理SSL。
SSL
完成SSL握手的时间。
Request Sent / Sending
发起请求的时间，通常小到可以忽略。
Waiting (TTFB)
等待响应的时间，具体来说是等待返回首个字节的时间。包含了与服务器之间一个来回响应的时间和等待首个字节被返回的时间。
Content Download / Downloading
用于下载响应的时间
结论我相信很多同学是直接跳到这里来了的。事实上我给不出什么解决方案，但能排除前端代码引起问题的可能性。
具体来说，能够得到的结论有以下几点：
- 请求成功构造，失败情况下也可以看到正常的请求头被打印出来了的
- 可以肯定的是在与服务器建立连接时被Shut down了，参考上面关于连接重置的部分会更有意义一些
- 参考上面「进一步解读日志文件」部分，来自Chromium开发者的回复中对日志文件的解读更加合理些，浏览器与服务器的连接不正常断开是导致问题的根源，以至于影响了后面对连接的重用
- 21秒的等待仍然是个未知数，不知道有何不可抗拒的外力促使浏览器21秒后才收到服务器的重置信息。此处浏览器与服务器的失联原因有待查证。
点赞 转发，让更多的人也能看到这篇内容（收藏不点赞，都是耍流氓-_-）
关注 ｛我｝，享受文章首发体验！
每周重点攻克一个前端技术难点。更多精彩前端内容私信 我 回复“教程”
原文链接：http://fex.baidu.com/blog/2015/01/chrome-stalled-problem-resolving-process/
作者：wayou
