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，看看是否需要优化，可以先从下面三个方面入手去了解。
-
TIME_WAIT 是什么？如何产生的呢？
-
TIME_WAIT存在起到什么作用？
-
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存在起到什么作用？
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
