不像重大网络故障总让人猝不及防，不重要的故障总是会发生在风和日丽的日子，但刺类似故障网络工程师不可避免，拿来与大家分享。

某天接到公司新上业务系统SA的反馈，该应用基于HTTP打开主界面反应迟缓，疑似网络质量有问题，希望排查链路。由于其他应用都没有出现类似问题，大概判断是业务本什么问题。但是推断不能TrobleShooting的绝对依据，实实在在的数据更有说服力。

该应用是基于Web登录，打开页面首，先进入sso的用户认证。认证通过后，会返回包含各功能模块的主页面；

由于所有Client端访问该应用地址都有类似现象，顾在本机直接抓包，用以分析网页缓慢的问题点，本次使用wireshark分析：

1、TCP三次握手

TCP三次握手

通过时间戳之间的绝对时间可以清楚发现交互的时间非常短，可以断定，网络质量没有问题；

2、用户认证登录：

Client-Server用户认证交互

378行Client显示server端的登录信息回显，并使用浏览器的cookie来验证登录信息，可见上图红框；

以上抓包内容与实际使用中的状况完全一致：打开网页-跳转认证-输入用户名密码，相应速度都比较快速。接下来就是最重要的：Server认证完用户名密码后Client获取的index主页相应时间：

3、回显Web主页：

Index请求及响应

521行Cliet请求主页：使用Seq 8505 + Length长度947，因此522行Server Ack确认9394数据长度0，时间戳间的绝对时间非常短，网络交互没有任何问题，如下图：

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 该应用对主页的设计不足；

甩锅是一种技术，但是找到根本原因，解决问题才是关键。通过数据包的底层分析，不但有理有据更能深刻的理解TCP/IP各层协议。欢迎大家讨论交流。

转载来着今日头条：https://www.toutiao.com/i6696278587143619079/