通过观察服务端发送数据包序列号新增的图表我们可以发现，以10ms为间隔基本上都是15个包一组一起发送。
几乎大部分时间都是是一次发15个包（21900字节），虽然没有达到65K（服务端cwnd应该是能达到64K甚至更高，可能是链路中的其他网络设备的窗口限制住了，毕竟这个速度运营商是要控制的），不过其实20K的cwnd也还是不错的，不应该会成为瓶颈 。
不同的网络状态cwnd的稳定峰值可能有差异，多的时候能会超过40K。其实这个一次发送的量直接受带宽影响。
3:后面想到的就是数据包乱序，或丢包
因为无论是丢包还是乱序，最终都会反应到cwnd下降，发送效率降低，不过从数据包列图表来看并没有发生这些情况。
为了分析丢包及乱序对资源下载的影响，实际测试的时候有意创造了较差网络，分析了这些有很多乱序及重传的情况，如下图是一次有乱序的流量。（与前文中的截图不是同一个流量数据，该图是专门选取的网络条件较差的情况）
可以明显看出来，即使发生了丢包及乱序，TCP恢复的都非常的快，绝不会把下载速度拖到超过1s。
收多次2481的乱序包后，马上就来了重传包（当然这里很可能只是迟到了的包，因为我们看到从第3个乱序ACK从发出到收到“重传”只有5ms，不到一个RTT。一般发送端会在收到3个以上的重传包以后才会认为发生丢包，上图中远不到一个RTT，是来不及收到第3个dup，然后再把重传包发送到接收方的）
而且看后面报文发送的情况，而且这些乱序并没有导致服务端发包的量及速率并没有明显下降（上面也提到了理论上cwnd应该已经到达了65k以上，不过实际上一次发送的量因为其他限制一直被控制在20K内，所以即使服务端认为自己确实发生乱序而降低cwnd，也不会影响到现在的发送速率）
确认问题 明确原因
反复查看了多组测试数据包，怎么看都觉得流量是正常的，链路上的数据包及他们的确认包，还包括他们从异常状态中的恢复过程都很正常，完全看不不同寻常的东西。
有的时候陷进去了是很难拔出来的，之前一直认为是运维的问题，所以竭尽全力的去寻找网络上的问题。
会不会是最开始判断错了，恍然大悟，如果网络都是正常的那不可能是超过1s的传输时间啊，200多个包一次15个间隔大概10ms，那发送及确认的时间绝不会超过200ms才对！
这个时候我才开始怀疑chrome的数据（因为之前计算TTFB的时间chrome与wireshark的时间一致，后面就再也没有怀疑过chrome的时间，也没有特意去对比后面的时间点）
如上图是这个response最后的报文段，从最开始发送response的第一个包（响应的首字节）的No 1031（35.875692），到上图的No 1374（36.045216）客户端确认最后一个服务端发来的数据包的时间差分明只有170ms。
其实前面的流量图表上也有体现序列号都是在200ms内加上去的，只是当时没有关注到 （陷入先入为主的思维里了，一开始自己就认定是网络问题，加上最开始核对chrome的开始时间及TTFB都是对的，就放松了对chrome本身的警惕）
现在基本上已经可以判断就是客户端（chrome）方面有问题。
验证问题
为了验证这个的结论可以使用使用了常用的代理软件（charles及fiddler）他们都会有独立的时间线统计功能。
可以看到代理上的时间明显比chrome上显示的时间少很多（一个162ms，一个2200ms）