Wireshark抓包定位系统网页响应慢的问题

文章来源：https://m.toutiaocdn.com/item/6696278587143619079/?app=news_article&timestamp=1564133671&req_id=20190726173430010027041153996E729&group_id=6696278587143619079

问题描述：基于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.该应用对主页的设计不足；