(二)相关知识
tcp连接有3次握手,断开有四次挥手。
三次握手中第一次,是主动端发出SYN信号给正在listen的被动端,然后自己变成了SYN-SENT状态;第二次是被动端发送ACK确认收到信号和SYN信号;第三次是主动端发出ACK信号确认已经收到了被动端的SYN。然后双双进入了enblished状态,便是已经连接成功。
四次挥手中的第一次就是主动端断开,发送FIN信号,变成FIN-WAIT-1状态;第二次是被动方收到FIN信号,就变成CLOSE-WAIT状态,然后赶紧发送ACK信号给主动方确认,这是时候主动方变为FIN-WAIT-2状态;第三次还是被动方等自己的应用断开连接的时候,发送FIN信号给主动方,被动方的状态变成LAST-ACK;第四次是主动方收到被动方的FIN信号,然后发送的ACK信号,瞬间自己变成TIME-WAIT状态,然后等待回收。
就是说,谁有TIME-WAIT,谁就是主动方。这点可以排除用户频繁关闭网页的可能。意思就是说这都是服务器主动请求断开连接的,而TIME-WAIT状态的链接也没有回收。
二、问题推测
(一)网络
网络上面的就是网络不好,或者被攻击。
(二)应用
中间件的参数不对,导致有中间件断开的连接,或者应用程序错误造成的主动断开连接。或者也是应用方面导致消耗资源太多。
三、排查
这个服务器有三个项目,每个项目的架构都是lanmp。问题复杂在于服务器里面好几个项目,每个项目用都一个反向代理。好的一点是后端是docker容器,分开的。
(一)TCP连接上的IP
1.下图是容器的IP
命令:
for i in $(docker ps|awk 'NR!=1 {print $NF}');do echo -e $i "\c";docker inspect --format '{{ .NetworkSettings.IPAddress }}' $i;done
2.下图是连接中本地的IP
命令:
netstat -tn|grep TIME_WAIT|awk '{print $4}'|sort|uniq -c|sort -nr|head
排名第一这个是我们本地IP,6601是api项目的监听端口,从这里可以看出在所欲的TIME_WAIT状态的TCP里面,API项目的后端是被请求最多的那个。估计反向代理服务器也被请求了很多。
3.下图是连接本地API项目的主动IP
命令:
netstat -ant|grep 10.25.20.251:6601