TCP四次挥手及原因_tcp为什么要4次挥手

一、TCP四次挥手

MSL是TCP报文里面最大生存时间，它是任何报文段被丢弃前在网络内的最长时间。

第一次挥手：A->B，A向B发出释放连接请求的报文，其中FIN（终止位） = 1，seq（序列号）=u；在A发送完之后，A的TCP客户端进入FIN-WAIT-1（终止等待1）状态。此时A还是可以进行收数据的

第二次挥手：B->A：B在收到A的连接释放请求后，随即向A发送确认报文。其中ACK=1，seq=v，ack（确认号） = u +1;在B发送完毕后，B的服务器端进入CLOSE_WAIT（关闭等待）状态。此时A收到这个确认后就进入FIN-WAIT-2（终止等待2）状态，等待B发出连接释放的请求。此时B还是可以发数据的。

(如果 B 直接跑路，则 A 永远处与这个状态。TCP 协议里面并没有对这个状态的处理，但 Linux 有，可以调整 tcp_fin_timeout 这个参数，设置一个超时时间。)

第三次挥手：B->A：当B已经没有要发送的数据时，B就会给A发送一个释放连接报文，其中FIN=1，ACK=1，seq=w，ack=u+1，在B发送完之后，B进入LAST-ACK（最后确认）状态。

第四次挥手：A->B；当A收到B的释放连接请求时，必须对此发出确认，其中ACK=1，seq=u+1,ack=w+1;A在发送完毕后，进入到TIME-WAIT （时间等待）状态。B在收到A的确认之后，进入到CLOSED（关闭）状态。在经过时间等待计时器设置的时间之后，A才会进入CLOSED状态。
 

二、为什么需要四次挥手

其实是客户端和服务端的两次挥手，也就是客户端和服务端分别释放连接的过程。可以看到，客户端在发送完最后一次确认之后，还要等待2MSL的时间。主要有两个原因，一个是为了让B能够按照正常步骤进入CLOSED状态，二是为了防止已经失效的请求连接报文出现在下次连接中。

解释：

1）、由于客户端最后一个ACK可能会丢失，这样B就无法正常进入CLOSED状态。于是B会重传请求释放的报文，而此时A如果已经关闭了，那就收不到B的重传请求，就会导致B不能正常释放。而如果A还在等待时间内，就会收到B的重传，然后进行应答，这样B就可以进入CLOSED状态了。

2）、在这2MSL等待时间里面，本次连接的所有的报文都已经从网络中消失，从而不会出现在下次连接中。
 

三、有三次挥手的情况么？该情况是在协议中实现的么？

如果是三次挥手，会怎么样？三次的话，被动关闭端在收到FIN消息之后，需要同时回复ACK和Server端的FIN消息。如果Server端在该连接上面并没有Pending的消息要处理，那么是可以的，如果Server端还需要等待一段时间才可以关闭另外一个方向的连接，那么这样的三次挥手就不能满足条件。