我整天都在到处阅读有关此内容的文章，从我所收集的信息来看，TIME_WAIT 是一种相对无害的状态。即使数量太多，它也应该是无害的。
但如果它们的数字与我过去 24 小时看到的数字一致，那么一定有什么地方出了问题！
[root@1 ~]# netstat -nat | awk '{print $6}' | sort | uniq -c | sort -n
1 established)
1 Foreign
12 CLOSE_WAIT
15 LISTEN
64 LAST_ACK
201 FIN_WAIT2
334 CLOSING
605 ESTABLISHED
816 SYN_RECV
981 FIN_WAIT1
26830 TIME_WAIT
这个数字在 20,000 到 30,000 之间波动（到目前为止，我见过的最大数字是 32,000）。令我担心的是，它们都是来自各种随机位置的不同 IP 地址。
现在这应该是（或曾经应该是）一次 DDoS 攻击。我知道这是事实，但我不会深入讨论这些无聊的细节。它一开始是一次 DDoS，确实影响了我服务器几分钟的性能。之后，一切都恢复正常。我的服务器负载正常。我的互联网流量正常。没有服务器资源被滥用。我的网站加载正常。
我也禁用了 IPTABLES。这也有一个奇怪的问题。每次我启用防火墙/iptables 时，我的服务器就会开始出现数据包丢失。大量数据包丢失。大约 50%-60% 的数据包丢失。这种情况发生在启用防火墙后一小时或几小时内。一旦我禁用它，我测试的所有位置的 ping 响应都会开始清除并再次稳定。非常奇怪。
从昨天开始，TIME_WAIT 状态连接数一直在这些数字上下波动。24 小时以来，我一直处于这种状态，虽然它没有对性能造成任何影响，但已经够令人不安了。
我当前的 tcp_fin_timeout 值为 30 秒，而默认为 60 秒。然而，这似乎毫无帮助。
有什么想法或建议吗？真的，只要你提供任何建议，我都会非常感激！
答案1
关于时间等待的一个很好的讨论是如何在时间等待中强制关闭套接字。
根据该参考，等待时间的连接数应与过去 4 分钟内的流量相对应。这些数字大致匹配吗？
答案2
当另一端未正确挂断时，我曾遇到过连接处于关闭等待状态的问题。这可能是由于恶意原因，或者是因为您的网络堆栈存在问题。
事实上，您似乎遇到了 iptables 问题，这也表明您的网络堆栈存在问题。
如果您有其他网络端口，则有必要将您的连接切换到另一个网络端口，以查看该端口是否出现同样的问题。问题也可能出在上游防火墙、路由器或坏人身上。
还有一些报告称 RedHat (+Centos?) 的 tcp_tw_recycle 设置存在问题。您可能需要调查一下。