服务端进程被杀掉，tcp连接处于FIN_WAIT2状态，为啥客户端调用socket发送数据还是成功的。

Posted 2023-04-13

参考技术A 我来告诉你标准答案!进程被kill的时候，会对所有已经打开的文件描述符执行close。
而这个close发起tcp连接断开时的四次握手。
就这个例子来说
第一次：服务端发FIN给客户端。而这个FIN表示服务端已经没有数据要发送了。
第二次：客户端接受FIN后，由系统的tcp/ip协议栈自动发送ack给客户端。表示我知道你没有数据要给我了。
第三次：客户端应用程序执行close。这个是进程自己控制的。跟第一次的意义一样（我也没有数据发送了）。
第四次：服务器端发ack给客户端表示确认。
上面的步骤就说明了。在客户端执行第二步以后。是可以给服务端发数据的。具体这些数据能不能正常被处理要依赖于具体的实现。
详细的细节你可以参考《unix网络编程》2.5节TCP连接的建立和终止

TCP3次握手4次挥手

TCP连接客户端状态转变过程

closed——>SYN_sent——>ESTABLISHED——> Fin_wait1——>Fin_wait2——>Time_wait——>closed

TCP连接服务端状态转变过程

closed——>listen——>SYN_recvd——>ESTABLISHED——>close_wait——>Lask_Ack——>closed

为什么TCP连接3次握手，断开要4次挥手呢？

因为在TCP断开的时候，客户端向服务端发送FIN=1的断开请求时（第一次挥手），自身进入只收不发的状态（Fin_wait1），但服务端可能还有数据没有收发完，所以服务端会回复ACK（第二次挥手）给客户端表示收到断开请求，此时客户端状态变为Fin_wait2，当服务端准备好之后，发送Fin（第三次挥手）表示断开连接同时自身进入Lask_Ack状态，客户端收到Fin之后发送Ack（第四次挥手）给服务端自身变为Time_wait状态。等待MSL时间过去客户端服务端重新变为closed状态。

为什么TCP4次挥手之后不是直接进入closed状态，而是等MSL时间到了之后才变呢？

因为计算机认为自身是不可靠的，也有第4次挥手的ACK报文服务端没收到的原因，所以会等MSL时间过去双方才变为closed状态。