背景
最近测试同事反馈测试环境卡顿频繁问题,第一时间反应可能是数据量大,查询慢所导致,但是使用Jmeter压测后发现并无异常,于是有了下面的记录。
问题排查过程
①重现场景(使用的浏览器为chrome)
经过一顿页面点击操作之后,果然出现了有一个接口返回很慢,但是该接口只是获取部门结构树,单表查询不存在查询慢的问题。F12查看该接口的请求信息,切换到 Timing tab,发现该请求的耗时如下:
发现接口耗时最长在Stalled过程,锁定是建立链接发生了错误,接下来使用Wireshark抓包看一下到底发生了什么,下载地址可百度。
工具准备阶段
由于很多人都是使用Fiddler,相信不陌生,这里阐述Wireshark的工具准备过程。
由于我需要抓的是https请求,需要把请求抓取到本地再由wireshark去解析,所以需要做一下配置,首先在任意位置创建两个文件,注意后缀要使用.log,如下
配置系统环境变量SSLKEYFILELOG,对应值为上面配置的sslkey.log的位置,如下:
接着在wireshark的首选项里面配置文件的位置 首选项》Protocos》TLS,如下:
开始抓包
然后在wireshark的捕获选项配置自己要抓包的接口 和 过滤规则。比如想抓取的https://baidu.com,(使用过滤规则host提示报错,我改用ip.addr)
首先Ping一下拿到ip地址,不会的请手动敲自己。
然后在wireshark的过滤条件 输入 ip.addr == 百度的真实ip,如下图:
捕获到请求后入上图,框1就是耗时、协议等信息,框2就是对应的OSI信息,框3就是对应的ASCII内容。
回到最上面的问题,接口出了什么问题呢,下面附上一张图:
这里大家回想一下TCP三次握手的过程,首先是客户端会发送SYN要建立,服务端回一个ACK和SYNC说准备好了,可以下一步,正当客户端兴冲冲跑过来回复说我也好了(ACK),我可是带了一点东西的(PSH),发现服务端没反应,并且连续重试5次都没得到服务端的回应(Windows下是5次,加起来是6次),我只能重置这个链接(RST)准备发起下一次握手请求。
以上情况就是我们经常听到的丢包,由于是发生在服务端回了ACK后,客户端带着PSH再请求发生的丢包,可以确定为是网络问题,这种情况让网管去处理就好了;如果wireshark显示ZEROWINDOW,那就是发送的数据太多了,接收端搞不赢,可以及时去缓冲区取数据。
PS:写的可能不准确,请提出纠正,这只是个人的一次记录。