相关文章：数通 8
TCP断联四次挥手
- 第一次挥手👋： 客户端进程发出连接释放FIN报文，并且停止发送数据。释放数据报文首部，FIN=1，其序列号为seq=x,此时，客户端进入FIN-WAIT-1（终止等待1）状态。
- 第二次挥手👋： 服务端进程收到连接释放FIN报文，发出确认ACK报文，ACK=1，ack=x+1，并且带上自己的序列号seq=y，此时，服务端就进入了CLOSE-WAIT（关闭等待）状态。此时，服务端通知高层的应用进程，客户端向服务端的方向就释放了，这时候处于半关闭状态，即客户端已经没有数据要发送了，但是服务端若发送数据，客户端依然要接受。这个状态还要持续一段时间，也就是整个CLOSE-WAIT状态持续的时间。客户端收到服务端的确认请求后，此时，客户端就进入FIN-WAIT-2（终止等待2）状态，等待服务器发送连接释放报文，在这之前依然可以接收服务端发送过来的最后的数据。
- 第三次挥手👋： 服务端将最后的数据发送给客户端完成后，就向客户端发送连接释放FIN报文，FIN=1，ack=x+1，此时的序列号为seq=z，此时，服务端就进入了LAST-ACK（最后确认）状态，等待客户端的确认。
- 第四次挥手👋： 客户端接收到服务端的连接释放FIN报文后，必须发出确认报文，ACK=1，ack=z+1，而自己的序列号是seq=x+1，此时，客户端就进入了TIME-WAIT（时间等待）状态。此时服务端收到客户端发送过来的确认报文，就立即撤销自己的传输控制块TCB,进入CLOSED状态，注意此时的TCP连接还没有释放，必须经过2MSL（最长报文段寿命）的时间后，客户端没有收到服务端发来的任何数据，证明服务端已正常关闭，此时客户端会撤销相应传输控制块TCB后，进入CLOSED状态。至此，TCP的连接才真正的断开了。（服务端结束TCP连接的时间要比客户端稍微早一些）
为什么TIME_WAIT状态还需要等2*MSL（Max SegmentLifetime，最大分段生存期）秒之后才能返回到CLOSED状态呢？
因为虽然双方都同意关闭连接了，而且握手的4个报文也都发送完毕，按理可以直接回到CLOSED状态（就好比从SYN_SENT状态到ESTABLISH状态那样），但是我们必须假想网络是不可靠的，你无法保证你最后发送的ACK报文一定会被对方收到，就是说对方处于LAST_ACK状态下的SOCKET可能会因为超时未收到ACK报文，而重发FIN报文，所以这个TIME_WAIT状态的作用就是用来重发可能丢失的ACK报文。
为什么断开连接需要四次挥手👋呢，像建立连接的时候一样，三次行不行呢？
TCP协议是一种面向连接的、可靠的、基于字节流的运输层通信协议。TCP是全双工 模式，这就意味着，在客户端想要断开连接时，客户端向服务端发送FIN报文，只是表示客户端已经没有数据要发送了，但是这个时候客户端还是可以接收来自服务端的数据。 当服务端接收到FIN报文，并返回ACK报文，表示服务端已经知道了客户端要断开连接，客户端已经没有数据要发送了，但是这个时候服务端可能依然有数据要传输给客户端。 当服务端的数据传输完之后，服务端会发送FIN报文给客户端，表示服务端也没有数据要传输了，服务端同意关闭连接，之后，客户端收到FIN报文，立即发送给客户端一个ACK报文，确定关闭连接。在之后，客户端和服务端彼此就愉快的断开了这次的TCP连接。 或许会有疑问，为什么服务端的ACK报文和FIN报文都是分开发送的，但是在三次握手的时候却是ACK报文和SYN报文是一起发送的，因为在三次握手的过程中，当服务端收到客户端的SYN连接请求报文后，可以直接发送SYN+ACK报文。其中ACK报文是用来应答的，SYN报文是用来同步的。但是在关闭连接时，当服务端接收到FIN报文时，很可能并不会立即关闭SOCKET，所以只能先回复一个ACK报文，告诉客户端，你发的FIN报文我收到了，只有等到服务端所有的数据都发送完了，才能发送FIN报文，因此ACK报文和FIN报文不能一起发送。所以断开连接的时候才需要四次挥手来完成。