一、背景
号码转接压测过程,单个业务接口调用没有问题。但是当tps调整为500的时候,发现大量的超时调用。
所以先用tcpdump去抓包,wireshark去分析。本次记录一条数据的传输过程。
抓包命令:tcpdump -i eth0 dst host 61.164.41.76 and port 15051 -vv -s 0 -w 1501.pcap
为什么握手3次,挥手4次?
https://baijiahao.baidu.com/s?id=1695910428789927548&wfr=spider&for=pc
二、数据流程
概念:
SYN:建立连接信号
ACK:确认信号
FIN:中断连接信号
Seq: 客户端接收到的数据offSet
Ack: 服务端接收到的数据offSet
第一步:客户端向服务端发送SYN Seq=0. 期望建立连接,序号为0
信号: [SYN] Seq=0
4788 17.836345 188.105.65.159 61.164.41.76 TCP 74 33925 → 15051 [SYN] Seq=0 Win=29200 Len=0 MSS=1460 SACK_PERM TSval=1531386920 TSecr=0 WS=128
第二步:服务端向客户端响应【SYN,ACK】seq=0,ack=1. 表示认可建立客户端往服务端方向的连接,并且期望和客户端方向建立连接。
**信号:[SYN, ACK] Seq=0 Ack=1 **
4961 18.653964 61.164.41.76 188.105.65.159 TCP 74 15051 → 33925 [SYN, ACK] Seq=0 Ack=1 Win=28960 Len=0 MSS=1460 SACK_PERM TSval=3909891227 TSecr=1531386920 WS=128
第三步:客户端响应服务端说可以。建立服务端至客户端方向的连接。
**信号:[ACK] Seq=1 Ack=1 **
4962 18.653994 188.105.65.159 61.164.41.76 TCP 66 33925 → 15051 [ACK] Seq=1 Ack=1 Win=29312 Len=0 TSval=1531387738 TSecr=3909891227
第四步:客户端向服务端发送post请求报文。
4963 18.654039 188.105.65.159 61.164.41.76 HTTP/JSON 599 POST /business/queryControl HTTP/1.1 , JavaScript Object Notation (application/json)
第五步:服务端向客户端响应,数据报文已收到。期待下一个报文序号为534
**信号:[ACK] Seq=1 Ack=534 **
5145 19.713467 61.164.41.76 188.105.65.159 TCP 66 15051 → 33925 [ACK] Seq=1 Ack=534 Win=30080 Len=0 TSval=3909892249 TSecr=1531387738
第六步:服务端向客户端响应报文。
5146 19.719261 61.164.41.76 188.105.65.159 HTTP/JSON 601 HTTP/1.1 200 , JavaScript Object Notation (application/json)
第七步:客户端向服务端响应,收到服务端的响应报文。
**信号: [ACK] Seq=534 **
5147 19.719287 188.105.65.159 61.164.41.76 TCP 66 33925 → 15051 [ACK] Seq=534 Ack=536 Win=30336 Len=0 TSval=1531388803 TSecr=3909892252
第八步:客户端向服务端发出命令,我想中断【客户端至服务端】的连接。
**信号: [FIN, ACK] Seq=534 **
问题1:注意:此时从客户端接收到响应到发出中断连接信号,有2.9秒时差,大致是我们的超时时间,说明没有主动释放连接。后续通过修复http请求主动释放解决长连接问题。
原因分析:客户端没有主动释放连接,等超时才释放。
5717 22.620976 188.105.65.159 61.164.41.76 TCP 66 33925 → 15051 [FIN, ACK] Seq=534 Ack=536 Win=30336 Len=0 TSval=1531391705 TSecr=3909892252
第九、十步:因为服务端一直未响应,客户端向服务端再次发出2次中断连接请求。因为发送了2次Ack=534前进2步。
信号:[FIN, ACK] Seq=534 Ack=536
问题2:从第一次中断到第三次,中间耗时4.2秒。只能怀疑网络原因。
问题原因:猜测为服务端带宽问题
6332 24.319913 188.105.65.159 61.164.41.76 TCP 66 [TCP Retransmission] 33925 → 15051 [FIN, ACK] Seq=534 Ack=536 Win=30336 Len=0 TSval=1531393404 TSecr=3909892252
7361 26.811923 188.105.65.159 61.164.41.76 TCP 66 [TCP Retransmission] 33925 → 15051 [FIN, ACK] Seq=534 Ack=536 Win=30336 Len=0 TSval=1531395896 TSecr=3909892252
第十一步:服务端回复客户端,可以关闭。Ack回的是535,说明回复的是第八步的内容。第9,10重复发送无用。
信号:[FIN, ACK] Seq=536 Ack=535
7463 27.225168 61.164.41.76 188.105.65.159 TCP 66 15051 → 33925 [FIN, ACK] Seq=536 Ack=535 Win=30080 Len=0 TSval=3909899672 TSecr=1531393404
第十二步:客户端向服务端回复,我已经关闭了。从此【客户端往服务端方向】的连接中断。
**信号: [ACK] Seq=535 Ack=537 **
7464 27.225193 188.105.65.159 61.164.41.76 TCP 66 33925 → 15051 [ACK] Seq=535 Ack=537 Win=30336 Len=0 TSval=1531396309 TSecr=3909899672
第十三步:服务端向客户端发起异常中断。中断了【服务端往客户端方向】的连接。
信号:Seq=536
问题3:此时服务端应该向客户端发起中断连接的信号,但是可能客户端被丢包了,未被抓到。服务端就主动异常中断。
问题原因:猜测为服务端带宽问题
7683 27.790800 61.164.41.76 188.105.65.159 TCP 60 15051 → 33925 [RST] Seq=536 Win=0 Len=0
三、httpClient及时释放链接
解决方案一:httpClient主动释放连接
参考连接https://www.cnblogs.com/l-h-Blog/p/5976041.html
还看到一个神奇的问题:该代码永远不会执行。
HttpClient client = new HttpClient(new HttpClientParams(),new SimpleHttpConnectionManager(true) );
postMethod.releaseConnection();
解决方案二:Linux服务器配置修改
net.ipv4.ip_forward=1
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 1
net.ipv4.tcp_fin_timeout=30
四、如何优化TCP_WAIT
4.HttpClient 连接池
HttpClient 我们经常用来进行 HTTP 服务访问。我们的项目中会有一个获取任务执行状态的功能使用 HttpClient,一秒钟请求一次,经常会出现 Conection Reset 异常。经过分析发现,问题是出在 HttpClient 的每次请求都会新建一个连接,当创建连接的频率比关闭连接的频率大的时候,就会导致系统中产生大量处于 TIME_CLOSED 状态的连接,这个时候使用连接池复用连接就能解决这个问题。
https://zhuanlan.zhihu.com/p/496804881
https://blog.csdn.net/zhangzhen02/article/details/105119309
HttpClient优化
HttpClient优化思路:
1、池化
2、长连接
3、httpclient和httpget复用
4、合理的配置参数(最大并发请求数,各种超时时间,重试次数)
5、异步
6、多读源码
1.背景
我们有个业务,会调用其他部门提供的一个基于http的服务,日调用量在千万级别。使用了httpclient来完成业务。之前因为qps上不去,就看了一下业务代码,并做了一些优化,记录在这里。
http://t.zoukankan.com/651434092qq-p-11050063.html文章来源:https://www.toymoban.com/news/detail-417927.html
附件:
参考连接:http://www.elinkcloud.cn/article/20210922103549.html
文章来源地址https://www.toymoban.com/news/detail-417927.html
到了这里,关于一次wireshark工具分析问题记录的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!