为何TCP挥手是四次 TCP挥手为何需要四次握手？

为何TCP挥手是四次

您可能不了解为何TCP挥手是四次的内容，接下来就是全面介绍。

TCP是一种可靠的、面向连接的协议，用于实现可靠的数据传输。它通过确认机制、重传机制和流量控制机制等机制来保证数据的可靠传输。

那么TCP连接的销毁，为何是四次挥手，而不是三次挥手呢？今天我们一起聊一聊。

为何不使用三次挥手

我们来看看，采用如下的方式，进行三次挥手操作：

我们知道TCP握手是三次，那么挥手为何不采用三次的方式呢。

看上图，我们按照服务端ACK和FIN合并一起发送至客户端的方式，即在服务端收到客户端的FIN请求后，服务端一次性发起数据请求，确认客户端的FIN请求已收到，同时向客户端发起FIN请求。

此时，若服务端仍存在数据需要发送至客户端，因服务端已准备关联，不能再发数据，所以数据是无法发到客户端的。

例如：服务端需要给客户端的数据有三部分：A部分、B部分、C部分，在A部分和B部分发到客户端后，C部分还未发送，收到了客户端的FIN请求，服务端回复了客户端ACK确认和FIN请求，那么C部分的数据，是无法发送至客户端的，此时，客户端仅收到了A部分和B部分的数据，收到的数据不完整。

可见，直接采用三次挥手的方式，是存在明显的问题的。

四次挥手

先看看四次挥手的图示：

发起方：主动发起链路关闭的一方，一般为客户端，但也可能为服务端，上图是以客户端为发起方举例。

接收方：被动接受链路关闭的一方，一般为服务端，但也可能为客户端，上图接收方为服务端举例。

第一次挥手：发起方发起链路关闭请求，seq=a，代表发起方使用的请求序号为a，FIN请求发送后，发起方不能再发送数据到接收方，此时发起方状态变为FIN-WAIT1。

第二次挥手：接收方在收到发起方的第一次挥手后，向发起方发起第二次挥手操作，seq=b，代表接收方使用的请求序号为b；ack=a+1，即值为发起方请求序号+1。接收方发送第二次挥手后，状态变为CLOSE-WAIT状态，此时接收方仍可以发送数据到发起方。发起方在收到第二次挥手后，状态变为FIN-WAIT2。

第三次挥手：接收方等待一定的时长，一般最大时间TCP_DELACK_MAX=200MS，最短时间TCP_DELACK_MIN=40MS，具体时间根据何时有数据需发送而定。延时确认结束后，接收方向发起方发起第三次挥手，seq=b，代表接收方使用的请求需要序号为b；ack=b+1，即值为发起方请求序号+1。接收方在发起第三次挥手后，状态变为LASK-ACK。

第四次挥手：发起方在收到接收方的第三次挥手后，向接收方发起第四次挥手，seq=a+1，代表发起方使用的请求序号为a+1，即第一次发起挥手序号+1；ack=b+1，接收方第三次挥手的请求序号为b，所以确认时值为b+1。发起方发送完ACK请求后，状态变为TIME-WAIT，在等待两个MSL的时间后，状态再变为CLOSE。接收方在收到发起方的第四次挥手后，状态变为CLOSE。

ESTABLISHED状态：链路是正常的，可以发送数据和接收数据。发起方和接收方均有这个状态。

CLOSE状态：链路已关闭，原来占用的端口，可以被回收，重新使用。发起方和接收方均有这个状态。

发起方的三个专属状态：

FIN-WAIT1状态：发起方发送FIN请求后的状态，此时，发起方不能再向接收方发送数据。

FIN-WAIT2状态：发起方在收到接收方第二次挥手后的状态。

TIME-WAIT状态：发起方发起第四次挥手后的状态。接收方两个专属状态：

CLOSE-WAIT状态：接收方在收到发起方的第一次挥手，即接收到FIN请求后的状态。

LAST-ACK状态：接收方在发起第三次挥手，即发起FIN请求后的状态。另外还有个状态：

CLOSING状态：CLOSE之前的状态，时间较短，很难看到。此状态有种特殊的场景下会出现，即客户端和服务端同时发起第一次挥手操作的情况下，两边均进入FIN-WAIT1状态，期待接收到对方的ACK包，进入FIN-WAIT2状态，但却先接收到了对方的FIN包，这时就会进入CLOSING状态，然后给对方一个ACK，在收到对方的ACK包后，直接进入CLOSE状态。

四次挥手抓包