“与首页一起打开” 的含义是指用户进入WEB系统后会首次加载的主页面，该主页会提前请求customQuery数据，以用于显示首页中的列表数据。
正常的想法会第一时间认为是刚进入首页请求多，导致的下载速度慢，这个自然不是这个原因，要不然也不会专门写这些内容，后面会讲到。
下文中我会尽量仅针对问题本身，不掺杂业务逻辑进行表述，并尽可能的做到描述清晰，准确。不过个人表达力及知识储备难免会有盲区，下文如有描述不当或有事实错误的地方，希望大家可以直接悉心指出。
这里需要单独说明下因为之前已经发过一篇关于customQuery请求gzip压缩的帖子，而这里讲的是2个没有关系的东西，不用联系在一起。
先直接上问题请求的截图
如上图323K的数据下载用了近2s，明显是出问题了。
该接口有在数据翻页时也会触发，不过下载时间表现正常。（如下图，同样的软硬件条件，在其他场景下，同样的参数拉取同一个接口的情况）
上图是翻页的场景（因为是列表数据，默认进入打开第一页，也可以自己触发翻页到其他页或回到第一页），也就是说只有在首页中被调用时下载时间异常，在正常TAB页中切换翻页数据下载表现都很正常。
还有一个细节，这个接口在测试或预发环境表现都是正常的，没有出现下载时间过长的问题，这也从侧面证明了并不是因为首页数据量大导致下载慢，通过查看各个整个过程的请求时间线也能明显看出，在出问题的时间断，并没有很多数据资源正在传输。
排除服务端问题为了排除服务端的问题，自己构建了测试程序简单模拟了下面场景。
同一请求顺序发送10次，结果如下（下载时间全部保持在300ms以下）
以下是5个一组一起发送的情况，可以看到下载时间基本上也是维持在了500ms以下（因为该请求其实很大，一个response有超过300kb，5个会有近2Mb，这个时候已经对带宽有一定的压力了，下载速度下降是正常的，而在首页加载的场景下不会有这么大的带宽压力）
通过上面的测试不难看出无论是顺序发送，或同一个客户端同时并行请求该请求资源的情况下，下载速度都不会下降到超过1s的水平。
Chrome DevTools 里可以看到当前浏览器默认同一个域名虽也是同时维持着6个http1.1链接，但除了目标接口，其他5个请求都会非常快的完成（其他响应大多小于1kb,不会占用太多带宽）
虽然这样想，但是现在也只能暂时怀疑是网络方面的问题了，为了证实自己的猜想，需要分析TCP原始报文。
注：本文并不阐述如何解决问题，主要通过各种事实数据证明问题出现在哪一个点，从而将问题转到正确的责任人。因为一般比较诡异的问题如果不能确认是问题具体是出在哪一块（服务端，运维，前端，嵌入式），那任何一方在工作压力已经如此大的情况下难免会本能的认为是其他人的问题，最后的结果就是，问题长时间都得不到解决。不过如果有充足是事实证据证明问题出在哪里，那通常负责那一块的同学还是会尽力去解决的。
排查网络问题 准备工作
为了配合Wireshark分析TCP报文我们需要使用Chrome的【Capture Network Log】直接在chrome中访问 chrome://net-export/ 即可以打开。
（Capture Network Log 的使用见 https://support.google.com/chrome/a/answer/3293821?hl=en 仅仅是用还是比较容易的）
如下图，在把Capture Network Log启动后，再次触发首页加载，DevTools显示下载时间依然很长。