因此，我在一台服务器上安装了应用程序A，该服务器每秒向另一台服务器上的应用程序B发送710条HTTP POST消息，该服务器正在侦听单个端口。连接不是保持活跃;他们被关闭了。
几分钟后，应用程序A报告无法打开与应用程序B的新连接。
我在两台机器上连续运行netstat，并且看到每个机器上都打开了大量的TIME_WAIT连接。实际上显示的所有连接都在TIME_WAIT中。从在线阅读开始，在每一方关闭连接之后，这似乎是30秒内的状态（根据/ proc / sys / net / ipv4 / tcp_fin_timeout值在我们的机器上30秒）。
我在每台机器上都有一个正在运行的脚本：
netstat -na | grep 5774 | wc -l
和
netstat -na | grep 5774 | grep "TIME_WAIT" | wc -l
在应用程序A报告无法打开与应用程序B的新连接之前，每台计算机上每个计算机的值似乎达到28,000左右。
我已经读过这个文件：/ proc / sys / net / ipv4 / ip_local_port_range提供了一次可以打开的连接总数：
$ cat / proc / sys / net / ipv4 / ip_local_port_range 32768 61000
61000 - 32768 = 28232，这与我看到的大约28,000个TIME_WAIT一致。
我的问题是如何在TIME_WAIT中建立如此多的连接。
似乎每秒关闭710个连接，我应该在给定时间看到大约710 * 30秒= 21300。我想这只是因为每秒打开710并不意味着每秒关闭710 ...
我唯一能想到的是一个缓慢的操作系统，可以解决关闭问题。
答案 0 :(得分：4)
TCP的TIME_WAIT表示本地端点（此方）已关闭连接。保持连接，以便任何延迟的数据包可以与连接匹配并进行适当处理。当连接在四分钟内超时时，连接将被删除。
假设所有这些连接都是有效的，那么一切都正常。您可以通过让远程端关闭连接来消除TIME_WAIT状态，或者您可以修改系统参数以增加回收（尽管这样做可能很危险）。
Vincent Bernat有excellent article on TIME_WAIT and how to deal with it：
Linux内核文档对net.ipv4.tcp_tw_recycle的作用不是很有帮助：
启用快速回收TIME-WAIT套接字。它应该是默认值 没有技术专家的建议/要求，不得更改。
它的兄弟net.ipv4.tcp_tw_reuse有点记载，但语言大致相同：
允许在安全时重新使用TIME-WAIT套接字进行新连接 从协议的角度来看默认值为0.不应更改 没有技术专家的建议/要求。
缺乏文档的唯一结果是我们找到了许多调优指南，建议将这两个设置都设置为1，以减少TIME-WAIT状态下的条目数。但是，正如tcp(7)手册页所述，net.ipv4.tcp_tw_recycle选项对于面向公众的服务器来说是很成问题的，因为它不会处理来自同一NAT设备后面的两台不同计算机的连接，这是一个很难的问题检测并等待咬你：
实现TIME-WAIT套接字的快速回收。启用此选项是 不建议使用，因为这会在使用NAT时导致问题 （网络地址转换）。