tcp/ip关闭分两种情况 主动(同步)和被动(顺序)

关闭分两种情况 主动(同步)和被动(顺序)

主动：指两边同步发起关闭信号

1. 两边初始状态都是ESTABLISHED

2. server(apache)发送关闭信号FIN给client(WAS server)进入FIN WAIT1状态， 同时，client(WAS server)发送FIN信号给server(apache)进入FIN WAIT1状态

3. server(apache)收到FIN信号给client(WAS server)发送ACK信号进入CLOSING状态 ，同时，client(WAS server)收到FIN信号发送ACK信号给server(apache)进入CLOSING状态

4. 双方都收到前一个ACK的ACK信号 进入TIME WAIT状态

5. 双方都等待一段时间后，超时，进入 CLOSED状态

被动：关闭信号由client(WAS server)发起 这是通常情况，只有这种情况才会出现CLOSE_WAIT

1. 两边初始状态都是ESTABLISHED

2. client(WAS server)发送关闭信号FIN给server(apache) 进入FIN WAIT1状态

3. server(apache)收到FIN信号,发送确认信号ACK给client(WAS server) 进入CLOSE WAIT状态

4. client(WAS server)收到ACK信号 进入FIN WAIT2状态

5. server(apache)发送关闭信号FIN给client(WAS server) 进入LAST ACK状态

6. client(WAS server)收到FIN信号 发送确认信号ACK给server(apache) 进入 TIME WAIT状态

7. server(apache)收到ACK信号 进入CLOSED状态

8. client(WAS server)等待一段时间后，超时，进入 CLOSED状态

 

我看了一下 apache 和 WAS上netstat的状态

apache 不论内外网，基本上绝大部分连接都是CLOSE_WAIT状态 ，而WAS上基本上就三种状态ESTABLISHED，FIN_WAIT2,和TIME_WAIT

这说明出现CLOSE_WAIT是卡在了第5步 ，也就是apache根本无法发送FIN信号给WAS，继而进入等待最后一次确认的状态：LAST_ACK

举个例子 ：

我在10.10.4.217上 netstat发现如下：

netstat -anp|grep 8201|grep 5.166

tcp        0      0 ::ffff:10.10.4.217:8201     ::ffff:10.10.5.166:57731    FIN_WAIT2   - 

这时候去apache 10.10.5.166 上去看 发现

ps -ef|grep 57731
tcp        1      0 10.10.5.166:57731           10.10.4.217:8201            CLOSE_WAIT  21890/httpd 

然后过了一会再去看

10.10.4.217：

netstat -anp|grep 8201|grep “5.166:57731”
无记录

10.10.5.166：
ps -ef|grep 57731
tcp        1      0 10.10.5.166:57731           10.10.4.217:8201            CLOSE_WAIT  21890/httpd 

我推断，这说明4.217上的进程发送完FIN关闭信号给APACHE，在第4步收到APACHE的ACK信号后，还未等APACHE发送FIN信号，就中止了或者说无响应了(是被人为的kill -9了，还是程序收到第一个ACK信号就直接退出了，未知)，这就导致APACHE根本无法将FIN信号发送出去，于是一直处于CLOSE_WAIT状态。