tcp - 是什么导致打开这么多 TIME_WAIT 连接？

Question

因此，我在一台服务器上有应用程序 A，它每秒向另一台服务器上的应用程序 B 发送 710 条 HTTP POST 消息，该服务器正在监听单个端口。连接不是保持事件的；他们关门了。

几分钟后，应用程序 A 报告它无法打开到应用程序 B 的新连接。

我在两台机器上连续运行 netstat，发现每台机器上都打开了大量 TIME_WAIT 连接。几乎所有显示的连接都在 TIME_WAIT 中。从在线阅读来看，这似乎是在每一方关闭连接后 30 秒(在我们的机器上为 30 秒，根据/proc/sys/net/ipv4/tcp_fin_timeout 值)的状态。

我在每台机器上运行一个脚本，该脚本一直在运行:

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_range32768 61000

61000 - 32768 = 28232，这正好符合我看到的大约 28,000 个 TIME_WAIT。

我的问题是在 TIME_WAIT 中怎么可能有这么多连接。

似乎每秒关闭 710 个连接，我应该在给定时间看到大约 710 * 30 秒 = 21300 个连接。我想仅仅因为每秒有 710 个被打开并不意味着每秒有 710 个被关闭......

我唯一能想到的另一件事是缓慢的操作系统绕过关闭连接。

Answer 1

TCP的 TIME_WAIT 表示本地端点(这一端)已关闭连接。保持连接，以便任何延迟的数据包都可以与连接匹配并适当处理。当连接在四分钟内超时时，连接将被删除。

假设所有这些连接都是有效的，那么一切都在正常工作。您可以通过让远程端关闭连接来消除 TIME_WAIT 状态，或者您可以修改系统参数以增加回收(尽管这样做可能很危险)。

Vincent Bernat 有一个 excellent article on TIME_WAIT and how to deal with it :

Linux 内核文档对于 net.ipv4.tcp_tw_recycle 的作用不是很有帮助:

Enable fast recycling TIME-WAIT sockets. Default value is 0. It should not be changed without advice/request of technical experts.

它的兄弟，net.ipv4.tcp_tw_reuse 有更多的文档，但语言大致相同:

Allow to reuse TIME-WAIT sockets for new connections when it is safe from protocol viewpoint. Default value is 0. It should not be changed without advice/request of technical experts.

缺乏文档的唯一结果是我们发现许多调整指南建议将这两个设置都设置为 1 以减少进入 TIME-WAIT 状态的条目数。然而，如 tcp(7) 所述在手册页中，net.ipv4.tcp_tw_recycle 选项对于面向公众的服务器来说是个问题，因为它不会处理来自同一 NAT 设备后面的两台不同计算机的连接，这是一个难以检测和解决的问题等着咬你:

Enable fast recycling of TIME-WAIT sockets. Enabling this option is not recommended since this causes problems when working with NAT (Network Address Translation).