TIME_WAIT 你好！

[root@vm-10-124-66-212 ~]# netstat  -an|awk -F ' ' '{print $NF}'|sort |uniq -c |sort -rn|more
   5552 TIME_WAIT
    631 ESTABLISHED
     22 SYN_RECV
     10 LISTEN

dmesg Log：

TCP: time wait bucket table overflow 

 TCP: time wait bucket table overflow产生原因及影响：原因是超过了linux系统tw数量的阀值。危害是超过阀值后﹐系统会把多余的time-wait socket 删除掉，并且显示警告信息，

先从机器的现状来说起，我机器的time_wait数量较多，以上的数据是非高峰期的机器现状，下面需要进一步了解一下time_wait，看看是否需要优化，可以先从下面三个方面入手去了解。

1. TIME_WAIT 是什么？如何产生的呢？

2. TIME_WAIT存在起到什么作用？

3. TIME_WAIT过多我们应该怎么办？

1.TIME_WAIT是什么？如何产生？

TIME_WAIT 是在TCP协议中的一种状态，他是产生在四次断连时主动发起申请的一方，为什么会出现这种状态呢？（如图）主动方在最后发送ack包时被动方直接进入close状态，因为B服务器认为A已经收到了我的ACK包，通话结束了，但是A此时并不知道B是否收到了我的ACK包，如果B没收到的话B还会给我重复发送FIN开启TCP重传，所以进入了等待状态TIME_WAIT，在等待2MSL后将进入CLOSED状态。

为什么是2MSL呢？

linux里一个MSL为30s，去向ACK消息最大存活时间（MSL) + 来向FIN消息的最大存活时间(MSL) = 2MSL，最大报文存活时间的2倍，确保延迟报文不会被新连接接收

 2.TIME_WAIT存在起到什么作用？

 TIME_WAIT进入等待状态，如果不等，释放的端口可能会重连刚断开的服务器端口，这样依然存活在网络里的老的TCP报文可能与新TCP连接报文冲突，造成数据冲突，为避免此种情况，需要耐心等待网络老的TCP连接的活跃报文全部死翘翘，2MSL时间可以满足这个需求，如果强制忽略TIME_WAIT，还是有很高的机率，造成数据错乱，或者短暂性的连接失败。 

 3.TIME_WAIT过多我们应该怎么办？

 TIME_WAIT连接如果没到达一定量级比如几千，其实可以不用处理的，其实对cpu和内存消耗很小，如果需要调优的话，可以深入了解一下背后的一些参数，防止出现影响业务情况。

 1.tcp_max_tw_buckets 表示系统同时保持TIME_WAIT套接字的最大数量，如果超过这个数字，TIME_WAIT套接字将立刻被清除并打印警告信息

　　从机器的TIME_WAIT和LOAD负载对比来看，我觉得并没有对机器对性能产生很直观对影响，我选择不变更tcp_max_tw_buckets参数，起码不会让它变得更小，如果系统出现TCP: time wait bucket table overflow报错的话，请适当调大一些

 2.net.ipv4.tcp_fin_timeout  对于本端断开的socket连接，TCP保持在FIN-WAIT-2状态的时间（秒）。对方可能会断开连接或一直不结束连接或不可预料的进程死亡默认是60s，可以调整为30s

3.net.ipv4.tcp_timestamps  RFC 1323 在 TCP Reliability一节里，引入了timestamp的TCP option，两个4字节的时间戳字段，其中第一个4字节字段用来保存发送该数据包的时间，第二个4字节字段用来保存最近一次接收对方发送到数据的时间。有了这两个时间字段，也就有了后续优化的余地，tcp_tw_reuse，tcp_tw_recycle优化依赖tcp_timestamps参数

4.net.ipv4.tcp_tw_reuse 是否允许将TIME-WAIT sockets重新用于新的TCP连接，默认为0，表示关闭

5.net.ipv4.tcp_tw_recycle 是否开启TCP连接中TIME-WAIT sockets的快速回收，默认为0，表示关闭

参数	默认配置	调整配置	说明
fs.file-max	1048576	9999999	所有进程打开的文件描述符数
fs.nr_open	1635590	1635590	单个进程可分配的最大文件数
net.core.rmem_default	124928	262144	默认的TCP读取缓冲区
net.core.wmem_default	124928	262144	默认的TCP发送缓冲区
net.core.rmem_max	124928	8388608	默认的TCP最大读取缓冲区
net.core.wmem_max	124928	8388608	默认的TCP最大发送缓冲区
net.ipv4.tcp_wmem	4096 16384 4194304	4096 16384 8388608	TCP发送缓冲区
net.ipv4.tcp_rmem	4096 87380 4194304	4096 87380 8388608	TCP读取缓冲区
net.ipv4.tcp_mem	384657 512877 769314	384657 512877 3057792	TCP内存大小
net.core.netdev_max_backlog	1000	5000	在每个网络接口接收数据包的速率比内核处理这些包的速率快时，允许送到队列的数据包的最大数目
net.core.optmem_max	20480	81920	每个套接字所允许的最大缓冲区的大小
net.core.somaxconn	128	2048	每一个端口最大的监听队列的长度，这是个全局的参数
net.ipv4.tcp_fin_timeout	60	30	对于本端断开的socket连接，TCP保持在FIN-WAIT-2状态的时间（秒）。对方可能会断开连接或一直不结束连接或不可预料的进程死亡
net.core.netdev_max_backlog	1000	10000	在每个网络接口接收数据包的速率比内核处理这些包的速率快时，允许送到队列的数据包的最大数目
net.ipv4.tcp_max_syn_backlog	1024	2048	对于还未获得对方确认的连接请求，可保存在队列中的最大数目。如果服务器经常出现过载，可以尝试增加这个数字
net.ipv4.tcp_max_tw_buckets	5000	5000	系统在同时所处理的最大timewait sockets数目
net.ipv4.tcp_tw_reuse	0	1	是否允许将TIME-WAIT sockets重新用于新的TCP连接
net.ipv4.tcp_keepalive_time	7200	900	表示TCP链接在多少秒之后没有数据报文传输时启动探测报文（发送空的报文）
net.ipv4.tcp_keepalive_intvl	75	30	表示前一个探测报文和后一个探测报文之间的时间间隔
net.ipv4.tcp_keepalive_probes	9	3	表示探测的次数

总结：

tcp_tw_reuse 和 tcp_tw_recycle 参数会大大的降低TIME_WAIT连接存在，但调整不当也会导致数据错乱的危险。

完整的了解完TIME_WAIT以后也就无需因为看见大量TIME_WAIT而恐慌 

参考：https://blog.oldboyedu.com/tcp-wait/

参考：https://blog.51cto.com/benpaozhe/1767612　

参考：https://kiswo.com/article/1017