Windows 2008上处于TIME_WAIT状态的大量TCP连接-在Amazon AWS上运行

操作系统：Windows Server 2008，SP2（在EC2 Amazon上运行）。

使用Apache httpd和tomcat服务器6.02和Web服务器运行Web应用程序具有保持活动设置。

在TIME_WAIT状态（使用netstat和tcpview）中，大约有69,250个（http端口80）+ 15000个（端口80除外）TCP连接。即使停止网络服务器（等待24小时），这些连接似乎也没有关闭

性能监视器计数器：

• TCPv4活动连接：145K
• TCPv4被动连接：475K
• TCPv4失败连接数：16K
• TCPv4连接重置：23K

HKEY_LOCAL_MACHINE\System \CurrentControlSet\Services\Tcpip\Parameters 没有TcpTimedWaitDelay键，因此该值应为默认值（2 * MSL，4分钟）

即使同时有成千上万的连接请求，为什么Windows OS最终无法清理它们？
这种情况背后的原因可能是什么？
有没有办法在不重新启动Windows OS的情况下强制关闭所有这些TIME_WAIT连接？

几天后，我们的应用程序停止建立任何新连接。

我们也一直在处理这个问题。看起来亚马逊找到了根本原因并纠正了它。这是他们给我的信息。

嗨，我在下面粘贴导致此问题的原因的解释。好消息是我们的工程团队最近已修复了此问题。要获得修复，您所要做的就是停止/启动您看到此问题的Windows Server 2008实例。同样，我不是在谈论REBOOT，这是不同的。STOP / START导致实例移至其他（正常）主机。当这些实例再次启动时，它们将在具有修复程序的主机上运行，​​因此不会再有此问题。现在，下面是此问题的工程解释。经过深入调查，我们发现在大多数可用实例类型上运行Windows 2008 x64时，我们发现了一个问题，该问题可能导致TCP连接在TIME_WAIT / CLOSE_WAIT中保留的时间过长（在某些情况下，无限期保持在此状态）。在这些状态下，特定的套接字对仍然无法使用，如果有足够的堆积，将导致所涉及端口的端口耗尽。如果发生这种特殊情况，清除相关套接字对的唯一解决方案是重新启动相关实例。我们确定原因是Windows 2008内核API中的计时器函数产生的值，在我们的许多64位平台上，该函数偶尔会检索到将来极远的值。这会导致TCP套接字对上的时间戳在未来很长一段时间内被标记，从而影响TCP堆栈。根据Microsoft，有一个存储的累积计数器，除非此API调用产生的值大于累积值，否则不会更新。最终结果是，在此之后创建的套接字将来都将被标记得太远，直到到达将来的时间为止。在某些情况下，我们已经在未来数百天看到了这个值，因此套接字对似乎永远被卡住了。

Ryan的回答是很好的一般建议，只是它不适用于Ravi在EC2中遇到的情况。我们也已经看到了这个问题，无论出于何种原因，Windows都完全忽略了TcpTimedWaitDelay，并且从未从其TIMED_WAIT状态释放套接字。

等待无济于事...重新启动应用程序无济于事...我们发现的唯一补救措施是重启操作系统。真丑。

在尝试调试单独的问题时，我完全随机地找到了该线程，但这是Windows 2 on EC2上的一个小问题，但众所周知的问题。我们曾经有溢价的支持，并在通过该通道非公开场合与他们讨论这一点，但是这是一个相关的问题是，我们没有在公共论坛上讨论。

正如其他人所提到的，您确实需要开箱即用调整Windows Server。但是，就像StopWatch在上述线程中无法正常工作一样，TCP / IP堆栈也使用该QueryPerformanceCounter调用来确定TCP_TIME_WAIT周期的持续时间。问题在于，在EC2上，他们遇到并知道一个棘手的问题QueryPerformanceCounter，并且可能会在很远的将来返回。不是因为您的TIME_WAIT状态被忽略，而是因为TIME_WAIT的到期时间可能是未来几年。在httpd设置中运行时，您可以看到遇到状态后如何快速累积这些僵尸套接字（我们通常看到这是一个离散事件，而不是慢慢累积僵尸）。

我们要做的是在后台运行一个服务，该服务查询处于TIME_WAIT状态的套接字的数量，一旦该指针停留在某个阈值之上，我们将采取措施（重启服务器）。在过去的45秒中，有人以某种方式指出您可以停止/启动服务器来解决此问题-我建议您结合使用这两种方法。

至少可以说，Windows中TCP堆栈的默认设置对于要托管HTTP服务器的系统不是最佳的。

为了在用作HTTP服务器时充分利用Windows机器，通常需要调整一些参数，例如MaxUserPort TcpTimedWaitDelay，TcpAckFrequency，EnableDynamicBacklog，KeepAliveInterval等

几年前，我就此事给自己写过一封便条，以防万一我需要一些快速默认值。随意了解参数，然后进行调整。

与AWS无关，我们只是遇到了这个问题，似乎是由于这篇知识库文章所致：

http://support.microsoft.com/kb/2553549/en-us

基本上，如果系统运行时间超过497天且未应用此修复程序，它将启动。当然，重新启动已将其清除-我们可能在接下来的16个月内都不知道该修补程序是否有效，但这可能会帮助那些拥有长时间运行服务器的人。

我在许多装有SP1的Windows Server 2008 R2 x64的盒子上都经历了几乎完全相同的事情，大多数情况下是使用CLOSE_WAIT（与TIME_WAIT有所不同）。我碰到了这个答案，该答案引用了Microsoft的知识库文章和一个修补程序，如果服务器在负载平衡器（属于我的）之后运行。安装此修复程序并重新启动后，所有的CLOSE_WAIT问题都已解决。