操作系统：Windows Server 2008 SP2（在Amazon EC2上运行）。
使用Apache httpd＆tomcat服务器6.02和Web服务器运行Web应用程序具有保持活动设置。
在TIME_WAIT状态下有大约69,250（http端口80）+ 15000（除了端口80）TCP连接（使用netstat＆tcpview）。 即使停止Web服务器（等待24小时），这些连接似乎也没有closures。
性能监控计数器：
HKEY_LOCAL_MACHINE\System \CurrentControlSet\Services\Tcpip\Parameters没有TcpTimedWaitDelay键，所以值应该是默认值（2 * MSL，4分钟）
即使有数以千计的连接请求同时到来，为什么Windows操作系统不能最终清理它们？
这种情况背后的原因是什么？
有没有办法强制closures所有这些TIME_WAIT连接，而无需重新启动Windows操作系统？
几天后，我们的应用程序停止采取任何新的连接。
我们也一直在处理这个问题。 亚马逊似乎find了根本原因，并纠正了它。 这是他们给我的信息。
嗨，我粘贴下面是什么导致这个问题的解释。 好消息是，我们的工程团队最近已经解决了这个问题。 为了解决问题，您只需停止/启动出现此问题的Windows Server 2008实例。 再次，我不是在谈论REBOOT，这是不同的。 停止/开始导致实例移动到不同的（健康的）主机。 当这些实例再次启动时，它们将在具有修复程序的主机上运行，这样他们就不会再遇到这个问题。 下面是这个问题的工程解释。 经过深入调查，我们发现在大多数可用的实例types上运行Windows 2008 x64时，我们发现了一个问题，可能导致TCP连接在TIME_WAIT / CLOSE_WAIT中保留时间过长（在某些情况下，无限期地保持这种状态）。 在这些状态下，特定的套接字对将保持不可用状态，如果足够累积，将导致端口耗尽。 如果出现这种情况，解决问题的唯一方法就是重新引导相关实例。 我们已经确定原因是Windows 2008内核API中的定时器函数产生的值，在我们的许多64位平台上，它们偶尔会检索一个非常远的值。 这会影响TCP堆栈，因为TCP套接字对上的时间戳未来将被标记得相当远。 据微软称，除非这个API调用产生的值大于累积值，否则存储的累计计数器将不会被更新。 最终的结果是，在这一点之后创build的套接字将在未来的时间被打上太远，直到达到未来的时间。 在某些情况下，我们已经看到这个价值数百天的未来，因此套接字似乎永远卡住。
Ryan的回答是很好的一般build议，只是它不适用于Ravi在EC2中遇到的情况。 我们也看到了这个问题，无论出于何种原因，Windows完全忽略了TcpTimedWaitDelay，也从来没有从TIMED_WAIT状态释放套接字。
等待没有帮助…重新启动应用程序没有帮助…我们发现的唯一的补救办法是重新启动操作系统。 真的很丑。
我完全随机地发现这个线程，同时寻找debugging一个单独的问题，但这是一个小调，但在EC2上的Windows知名的问题。 我们曾经有过高水平的支持，并通过这个渠道在非公开场合与他们进行了讨论，但这是我们在公共论坛上讨论过的一个相关问题 。
正如其他人所提到的，您确实需要调整Windows Server的开箱即用function。 但是，与StopWatch不在上述线程中工作的方式相同，TCP / IP堆栈也使用QueryPerformanceCounter调用来确定TCP_TIME_WAIT期限应该持续的时间。 问题是，在EC2上，他们遇到并了解到QueryPerformanceCounter出现故障的问题，并且可能会在未来的时间内返回到很远的地方; 这并不是说您的TIME_WAIT状态被忽略，而是TIME_WAIT的到期时间有可能是未来的几年。 当在一个httpd设置中运行时，你可以看到一旦遇到这个状态，你如何快速地积累这些僵尸套接字（我们通常会看到这是一个离散的事件，而不是你慢慢积累的僵尸）。
我们所做的是在后台运行一个服务来查询处于TIME_WAIT状态的套接字数量，一旦这个数值超过一定的阈值，我们就采取行动（重启服务器）。 不知何故， 在过去的45秒 ，有人指出，你可以停止/启动服务器来解决这个问题 – 我build议你结合这两种方法。
Windows中的TCP堆栈的默认设置至less对于要承载HTTP服务器的系统来说不是最佳的。
为了充分利用你的Windows机器作为HTTP服务器，有一些参数你通常会调整像MaxUserPort TcpTimedWaitDelay，TcpAckFrequency，EnableDynamicBacklog，KeepAliveInterval等
几年前，我曾经写过一篇关于自我的说明 ，以防万一我需要一些快速的默认设置。 随意了解参数，然后调整它们。
与AWS无关，我们只是遇到了这个问题，这似乎是这个知识库文章的结果：
http://support.microsoft.com/kb/2553549/en-us
基本上，如果系统启动超过497天，并且尚未应用修补程序，则会启动该function。 当然，重新启动已经被清除 – 我们可能在接下来的16个月中不知道修补程序是否工作，但是这可能有助于任何长时间运行服务器的人。
我在使用SP1的Windows Server 2008 R2 x64的许多盒子上遇到了几乎完全相同的事情，主要是使用CLOSE_WAIT（与TIME_WAIT有些不同）。 我碰到这个答案 ，它引用了微软的KB和一个热修复，如果服务器运行在负载平衡器（我的）后面。 安装修补程序并重新启动后，所有的CLOSE_WAIT内容都已解决。