问题描述：基于HTTP代开主界面反应迟缓，疑是网络质量有问题，希望排查链路。由于其它应用都没有类似问题，大概判断是业务本身没有出现类似问题。但是推断不能TrobleShooting的绝对依据，实实在在的数据更有说服力。
该应用是基于Web登陆，代开页面首页，先进入sso的用户认证。认证通过后，会返回包含各功能模块的主页面；
由于所有Client端访问该应用地址都要类似现象，顾在本机直接抓包，用以分析网页缓存慢的问题点，本次使用wireshark分析：
1、TCP三次握手
TCP三次握手
通过时间戳之间的绝对时间可以清除发现交互的时间非常短，可以断定，网络质量没有问题。
2、用户认证登陆：
Client-Server用户认证交互
378行Client显示Server端的登陆信息回显，并使用浏览器的cookie来验证登陆信息，可见上图红框；
以上抓包内容与实际使用中的状况完全一致：打开网页--跳转认证--输入用户名密码，相应速度都比较快速。接下来就是最重要的：
Server认证完用户名密码后Client获取的index主页相应时间：
3、回显Web主页：
Index请求及响应
521行Client请求主页：使用Seq 8505 + Length 长度947，因此时间戳的绝对时间非常短，网络交互没有任何问题，如下图：
Server确认主页请求
但是在522-564之间，也就是Server确认Client的index请求，并将主页信息返回给Client端用了将近10s （30.269-20.4808），并且此过程不涉及Client-Server的网络交互，完全是Server在Ack+len0后，处理返回的数据，问题点完全在Server处理数据的能力：如下图：
Server返回主页内容
尽管在565行TCP使用了PSH置为（简单说一下TCP的PSH置为TCP的发送方在数据包过大时会使用分片技术，接受方收到数据后会缓存起来，直到整个数据传完再上传给应用层处理，而PSH位可以让接收方收到该数据片后，立即上交应用层）但是Server本身处理过程过久，无关Client如果处理收到的数据。
Flags: PSH
根据以上对数据包的分析：
1.无关网络问题；
2.Server处理该应用能力不足；
3.该应用对主页的设计不足；
