关于Chrome浏览器瀑布流

Watefall即Chrome的瀑布流，可以看到请求花费时间具体到了那些部分，就是将一次HTTP请求所花的时间做了拆解，从而有助于分析和定位问题所在。

瀑中有好几种颜色：浅灰，深灰，橙色，绿色，蓝色结合上面的解释，大概知道这些颜色代表的含义了：

• 浅灰：查询中
• 深灰：停滞，代理转发，请求发送
• 橙色：初始连接
• 绿色：等待中
• 蓝色：内容下载

瀑布图提供了三个直观的东西来帮助我们进行前端性能优化

首先，减少所有资源的加载时间。亦即减小瀑布图产品的宽度。瀑布图越窄，网站的访问速度越快

其次，减少请求数量也就是降低瀑布图的高度。瀑布图越矮越好

最后，通过优化资源请求顺序来加快渲染时间。从图上看，就是将绿色的“开始渲染”线向左移。这条线向左移动的越远越好

知道上面这些,来看我做的首页统计接口。

上面还可以,最后两条的等待时间很长,导致拖慢了我们接口的响应时间。这是为什么呢

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

又有问题了!! 明明我的网络很好,为什么会发生重传呢？

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

 

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

上面也说过,网络是没有问题的,同时也确认过服务端没有问题,那么总结的不就是有问题的吗? 我们在分析下一般情况下stalledstalled的原因有哪些呢?

浏览器得到要发出这个请求的指令，到请求可以发出的等待时间，一般是代理协商、以及等待可复用的TCP连接释放的时间，不包括DNS查询、建立TCP连接等时间等。
浏览器对同一个主机域名的并发连接数有限制，因此如果当前的连接数已经超过上限，那么其余请求就会被阻塞，等待新的可用连接；此外脚本也会阻塞其他组件的下载；

也就是说根本问题是在于浏览器的底层上
浏览器对同一个主机域名的并发连接数有限制，因此如果当前的连接数已经超过上限，那么其余请求就会被阻塞，等待新的可用连接
我们还需注意的是脚本也会进行阻塞

浏览器对同一域名进行请求的最大并发连接数

浏览器版本	HTTP 1.0 服务器（宽带连接）	HTTP 1.1 服务器（宽带连接）	HTTP 1.0 服务器（拨号连接）	HTTP 1.1 服务器（拨号连接）
Internet Explorer 7 和早期版本	4	2	4	2
Internet Explorer 8	6	6	4	2
Internet Explorer 9	10	10	-	-
Internet Explorer 10	6	6	-	-
Internet Explorer 11	6	6	-	-
chrome、firefox	6	6	-	-

因为谷歌浏览器是最高6个并发,所以我的第七,第八个请求需要等待。

原因知道了,有什么好的解决办法吗