彻底弄懂TCP四次挥手

上篇文章讲述了TCP三次握手原理，这次来了解一下TCP四次挥手，废话不多说，上图，一目了然：

最开始客户端和服务端都是处于ESTABLISHED状态，数据传输完毕，双方都可以释放连接，这里以客户端主动释放连接为例：

• 第一次挥手：客户端发送断开连接报文，报文首部FIN置为1，其序号为u，报文发出后，客户端进入FIN-WAIT-1状态。TCP规定，FIN报文段即使不携带数据，也要消耗一个序号。
• 第二次挥手：服务端收到来自客户端发送过来的断开连接报文，随即向客户端回一个确认报文，报文首部ACK置为1，ack=u+1，其序号为v。随后服务端进入CLOSE-WAIT状态。该状态也称为半关闭状态，即客户端无数据传输，而服务端还可以继续发送数据。 客户端收到服务端发送的确认报文后，客户端进入FIN-WAIT-2状态，等待服务端发送FIN报文。
• 第三次挥手：服务端数据传输完毕后，向客户端发送连接释放报文，报文头部FIN置为1，ACK=1，ack=u+1，序号Seq=w（在半关闭状态，可能存在数据传输），随后服务端进入LAST-ACK状态，等待客户端最后确认。
• 第四次挥手：客户端收到服务端发送过来连接释放报文后，向服务端发送一个确认报文，ACK置为1，ack=w+1，序号Seq=u+1，客户端随即进入TIME-WAIT状态。注意：此时客户端并没有释放连接，需要等待2MSL（最大段报文寿命）时间，并撤销相应的TCB（传输控制块），才能最终释放TCP连接。 服务端收到客户端发送的释放连接确认报文后，撤销TCB，然后立即进入CLOSED状态。

第四次挥手为什么要等待2MSL？

MSL(Maximum Segment LifeTime)，即报文最大生成时间，它是指任何报文在网络上存在的最长时间，超过这个时间的报文将被丢弃。

要弄懂第四次挥手为何要等待2MSL时间，需要明白TIME-WAIT状态的目的：

> 优雅的关闭 TCP 连接，保证被动关闭的一端收到它自己发出去的 FIN 报文的 ACK 确认报文；

> 处理延迟的重复报文，避免前后两个使用相同四元组(源IP地址、目的IP地址、源端口、目的端口)的连接中的前一个连接报文干扰后一个连接。

TIME_WAIT状态过多有什么危害？

1）过多TIME_WAIT的会话占用内存资源，一个TIME_WAIT连接占用4k大小

2）TIME_WAIT状态结束以前，socket端口一直被占用，无法释放；若TIME_WAIT过多，端口资源耗尽，将不能创建新的连接请求。

如何解决过多TIME_WAIT？

在系统中启用TIME_WAIT的重用和快速回收，在Linux系统下可以修改以下参数：

（1）打开TCP对时间戳的支持，保持服务器与客户端时间同步 ：

net.ipv4.tcp_timestamps=1（默认为 1）

（2）允许对处于TIME_WAIT的socket用于建立新的连接：

net.ipv4.tcp_tw_reuse = 1 (默认为0)

（3）修改TIME_WAIT连接状态的上限值，超过上限值，处于TIME_WAIT状态的socket将立刻被清除：

net.ipv4.tcp_max_tw_buckets = 3000 （默认为18000）