记录一次请求慢的问题排查

背景

   最近测试同事反馈测试环境卡顿频繁问题，第一时间反应可能是数据量大，查询慢所导致，但是使用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:写的可能不准确，请提出纠正，这只是个人的一次记录。