TCP协议四次挥手过程-TIME_WAIT-CLOSE_WAIT状态的作用-大量出现如何处理？

TCP协议四次挥手过程

TCP在建立连接时要进行三次握手，在断开连接时要进行四次挥手，这是由于TCP的半关闭造成的。因为TCP 连接是全双工的（即数据可在两个方向上同时传递），所以在进行关闭时对每个方向都要单独进行关闭，这种单方向的关闭叫作半关闭。在一方完成它的数据发送任务时，就发送一个FIN来向另一方通告将要终止这个方向的连接。

TCP 断开连接既可以是由客户端发起的，也可以是由服务器端发起的；如果由客户端发起断开连接操作，则称客户端主动断开连接；如果由服务器端发起断开连接操作，则称服务端主动断开连接。下面以客户端发起关闭连接请求为例

口述

• 客户端发送一个FIN=1,seq = X的报文给服务器端，表示在客户端关闭链路前要发送的数据已经安全发送完毕，可以开始关闭链路操作，并请求服务器端确认关闭客户端到服务端的链路操作。此时客户端处于FIN-WAIT-1状态。
• 服务端收到FIN消息后，回应一个ACK=1, seq=Y, ack = X + 1的消息给客户端，表示已经收到客户端断开链路的请求，TCP服务器端进程通知高层应用进程释放客户端到服务器端的连接，服务器处于CLOSE_WAIT状态(半关闭状态)。客户端在收到ACK消息后处于FIN-WAIT-2状态。
• 服务器将主动关闭连接请求的FIN=1,  ACK = 1, ack = X + 1, seq = Z的消息给客户端，表示在服务端关闭链路前要发送的数据已经安全发送完毕，可以开始关闭链路操作， 此时进入LAST_ACK状态，等待客户端最终断开链路。
• 客户端在收到FIN消息之后，发送ACK = 1, ack = Z + 1, seq = W的消息给服务端，然后进入TIME_WAIT状态，TCP还没有释放连接，还需要等到2 *MSL时间后，客户端进入CLOSE状态。
• seq序号不会重复，一直增大，而且客户端依次出现的状态为: FIN-WAIT-1, FIN-WAIT-2, TIME_WAIT、 CLOSE， 服务度端依次进入的状态有CLOSE_WAIT，LAST_ACK_CLOSE

TIME_WAIT状态

1. 被动关闭方发送FIN（第三次挥手），并等待主动关闭方返回ACK(第四次挥手)
2. 若最终ACK丢失(第四次挥手失败)，被动关闭方将重新发送FIN(第三次挥手)，主动关闭方必须维护状态信息TIME_WAIT,保证自己可以接收，然后再重发最终ACK.不能让主动方发送完报文以后立马进入CLOSE状态

TIME_WAIT状态所带来的问题

1. 主动断开方处于TIME_WAIT状态时，源端口无法使用
2.  端口最大数是65535，因此如果频繁主动断开TCP连接，将很快耗尽端口号。一旦达到了上限，则新的请求就无法被处理，接着就是大量Too Many Open Files异常，然后tomcat、nginx、apache崩溃

如何解决TIME_WAIT问题

1. 解决TIME_WAIT大量出现，最核心的思想，就是打开系统的TIME_WAIT重用和快速回收
2. net.ipv4.tcp_tw_recycle = 1表示开启TCP连接中TIME_WAIT sockets的快速回收，默认为0,表示关闭
3. net.ipv4.tcp_tw_reuse = 1 表示开启重用。允许将TIME_WAIT sockets重新用于新的TCP连接，默认为0，表示关闭

CLOSE_WAIT状态

如果出现了CLOSE_WAIT过多的状态

1.在对方关闭连接后，自身程序里没有检测 -（被动方的角度）

2.本身忘了需要关闭连接，于是整个资源就一直被程序占用着。-（主动方的角度）

如何解决CLOSE_WAIT问题

1. 关闭正在运行的程序
2. 尽快修改程序bug,然后测试提交到线上服务器