在服务器端等待许多时间的成本是多少?

每个插座 TIME_WAIT 在内核中消耗一些内存,通常比 ESTABLISHED 插座仍然重要。足够大的数量可能耗尽内核内存,或者至少会降低性能,因为该内存可以用于其他目的。 时间等待 套接字不包含打开的文件描述符(假定它们已正确关闭),因此不需要担心“打开的文件太多”错误。

插座还连接了那个特定的 src / dst IP地址和端口,因此在 等待时间 间隔。(这是 时间等待 状态。)除非需要用相同的端口对重新连接,否则捆绑端口通常不是问题。最常见的情况是,一边使用一个短暂的港口,只有一边锚定在一个众所周知的港口。然而,大量的 时间等待 如果在相同的两个IP地址之间反复频繁地连接,那么套接字可能会耗尽短暂的端口空间。注意:这只影响这个特定的IP地址对,不会影响与其他主机建立连接。

迄今为止的发现:

即使服务器使用系统调用关闭了套接字,如果它进入时间等待状态,它的文件描述符也不会被释放。当时间等待状态消失后(即2*msl秒后),将释放文件描述符。因此,太多的等待时间可能会导致服务器进程中出现“打开的文件太多”错误。

我相信O/S TCP/IP堆栈是用适当的数据结构(例如哈希表)实现的,因此总等待时间不应影响O/S TCP/IP堆栈的性能。只有在等待状态下拥有套接字的进程(服务器)才会受到影响。

每个连接都由一个元组(服务器IP、服务器端口、客户端IP、客户端端口)标识。至关重要的是, TIME_WAIT 连接(无论是在服务器端还是在客户机端)都占用这些元组中的一个。

与 时间等待 在客户机端,很容易理解为什么您不能再建立任何连接——您没有更多的本地端口。但是,同样的问题也适用于服务器端-一旦它在 等待时间 状态 对于单个客户 ,它不能再接受任何连接 来自那个客户 ,因为它无法区分旧连接和新连接之间的区别-两个连接都由同一个元组标识。服务器应该只发送回 RST 在这种情况下,从该客户机到新的连接尝试。

如果从许多不同的客户机IP到服务器IP有很多连接,那么可能会遇到连接跟踪表的限制。

检查:

sysctl net.ipv4.netfilter.ip_conntrack_count
sysctl net.ipv4.netfilter.ip_conntrack_max

在所有SRC IP/端口和DEST IP/端口元组中,跟踪表中只能有net.ipv4.netfilter.ip_conntrack_max。如果达到此限制,您将在日志中看到一条消息“nf_contrack:table full,dropping packet.”,并且在跟踪表中再次有空间之前,服务器将不会接受新的传入连接。

这种限制可能会在短暂的端口耗尽之前很久就影响到您。

在我的场景中,我运行了一个脚本,它重复调度文件,我的产品做了一些计算,并将响应发送到客户机IE客户机正在进行一个重复的HTTP调用,以获取每个文件的响应。当我的服务器中约有150个文件被调度时,套接字端口进入“等待”状态,并在客户机中引发一个异常,打开一个HTTP连接。离子IE

 Error : [Errno 10048] Only one usage of each socket address (protocol/network address/port) is normally permitted

结果是我的应用程序挂起了。我不知道线程是否已进入等待状态或发生了什么,但我需要终止所有进程或重新启动应用程序以使其再次工作。

我试着把等待时间缩短到30秒,因为默认情况下它是240秒,但它不起作用。

因此,总体影响至关重要,因为它使我的应用程序没有响应

看起来服务器可能只是用完了分配给传入连接的端口(在现有的超时等待期间),这是DOS攻击的一种情况。