一次wireshark工具分析问题记录

一、背景

号码转接压测过程，单个业务接口调用没有问题。但是当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

附件：
参考连接：http://www.elinkcloud.cn/article/20210922103549.html