其实到现在已经可以下结论是客户端的的问题（前端）。不过因为这个请求其实在浏览器除首页的其他场景或着使用其他客户端直接请求下载速度都是正常的，出问题的那次请求又是预加载的请求（同时还会有好几个请求会被一起发送），所以乍一看总会觉得是网络方面的问题，当然这个上文中的内容已经证明了，完全不是网络的问题。不过要让前端同学“诚恳”的接受这个是自己的问题并想办法修复它，可能还需要我们进一步指出问题出在了什么地方（万一有同学把问题直接推给chrome那不就无解了么）。
通过上文的描述我们可以发现响应回包已经在200ms内全部被客户端socket确认，但是chrome似乎认为是1，2s。
通过观察多个被chrome统计称2s的流量的滑动窗口win数值的变化，发现了一个共性，那就是在接受该请求时客户端win的大小呈现出趋势性的下降（而正常的下载时间的场景没有这个趋势）
开始因为这个窗口最低也只将到了200kb，实际发送方一直在以20kb的量在传输，200kb的win根本不会阻塞流量，所以自己也一直没有觉得有什么问题，而这个趋势实际上是不正常的，因为其实数据的ACK其实很快就回复了。
那这个变化趋势的产生的原因可能也是chrome里下载时间明显变长的原因。
我们知道win的窗口大小是用来告知对方当前链接自己还能接受多少数据的一个标记，服务端发送过来的数据会占用这个win，客户端在回复ACK的时候会告知对方当前自己的win大小，通常socket收到的数据被确认后会马上被应用程序读取，这个win会迅速恢复，不会持续下降。这里的持续下降大概率就是数据没有被应用层读取。通常应用层读取本地socket接收缓存的速度比包在广域网络里传输的速度快几个量级，这里大量数据没有及时被应用读取，那就极可能是应用程序自己遇到了“非常”的情况。
排除其他因素
到这一步可以说是前端应用的锅已经稳了,不过为了严谨我们还要排除是统计问题，会不会只是是chrome算时间算错了。
其实这个还是比较好确认的，最简单的就是录屏逐帧查看是不是要等2s的下载完成后才加载数据，当然其实chrome的DevTools里的Performance工具可以帮我们完成分析（同时也会录屏）
通过Performance可以看出下载那段时间是没有渲染出数据的（其实下载完成后也还需要一段时间才能展示出数据）
chrome看起来统计下载时间是按应用自己读取时间来的，因为“某些”异常导致读取明显滞后，最终表现在网页上就是下载时间超长。
总结
应该是前端应用在预加载请求上的写法给chrome的执行照成了问题，整体上肯定是应用代码的问题跑不掉了。
现在就需要前端同学去确定具体是什么“异常”了。
还有一个细节，因为下载时间变长在测试或预发环境表现正常，因此一开始我按自己的经验认为是运维的问题（服务器，网络，nginx）所以一直在试图证明自己的错误的想法，偏执的去找数据流量的茬，同时也没有怀疑过chrome统计的数据可能不是真实的网络时间，导致整个过程花了很长时间。