我们在使用 Windows 2008 Datacenter edition SP2 64bit 时遇到了一个问题。我们有一个进程正在非常频繁地轮询并建立新的 TCP 连接。系统处于一种状态，最终有超过 16k 个连接处于 TIME_WAIT 状态。默认操作系统超时时间为 120 秒，在此之后这些连接应该会消失，但这种情况从未发生过。这些连接仍然存在，即使在发起进程早已终止后也从未被清除（进程被终止两天后，我们仍然有 16k 个连接）。操作系统应该将它们超时，但它没有。
有其他人见过这种行为吗？如果见过，如何解决它？我们知道如何调整 TCP 堆栈以缩短超时时间或允许更多连接，但这不是这里的问题。
谢谢！
答案1
Amazon EC2 在这方面遇到了一个大问题。他们最近修复了这个错误。也许您的情况也存在同样的问题？
嗨，我在下面粘贴了导致此问题的原因的解释。好消息是，我们的工程团队最近已经修复了这个问题。要修复它，您只需停止/启动出现此问题的 Windows Server 2008 实例。再次强调，我说的不是重新启动，这是不同的。停止/启动会导致实例移动到不同的（健康）主机。当这些实例再次启动时，它们将在已修复的主机上运行，因此它们不会再次出现此问题。下面是此问题的工程解释。经过深入调查，我们发现，在大多数可用实例类型上运行 Windows 2008 x64 时，我们发现了一个问题，该问题可能导致 TCP 连接在 TIME_WAIT/CLOSE_WAIT 中停留过长时间（在某些情况下，无限期地保持此状态）。在这些状态下，特定的套接字对仍然不可用，如果积累得足够多，将导致相关端口的端口耗尽。如果发生这种特殊情况，清除相关套接字对的唯一解决方案是重新启动相关实例。我们已确定原因在于 Windows 2008 内核 API 中的计时器函数生成的值，在我们的许多 64 位平台上，该函数偶尔会检索到未来非常遥远的值。这会导致 TCP 套接字对上的时间戳被标记在相当遥远的未来，从而影响 TCP 堆栈。据 Microsoft 称，有一个存储的累积计数器，除非此 API 调用生成的值大于累积值，否则不会更新。最终结果是，在此时间点之后创建的套接字都将被标记在太遥远的未来，直到达到该未来时间。在某些情况下，我们看到这个值位于未来几百天之后，因此套接字对似乎永远停滞了。
答案2
有一个Microsoft 文章描述了解决此问题的几种方法。它通常来自编码错误且未正确关闭端口的应用程序。您需要查看您安装了哪些应用程序，或者您正在执行哪些任务并禁用这些任务，以查看是哪些应用程序导致了此问题。
要解决这个问题，您需要查看以下任一内容；
- 增加动态分配给客户端 TCP/IP 套接字连接的临时端口的上限范围。
- 将客户端 TCP/IP 套接字连接超时值从默认值 240 秒减少（更持久的修复）
答案3
我在 Windows 2003 Server 上遇到了同样的问题。更改注册表 TCPIP 参数后重新启动计算机时问题解决了。也许你可以在 Server 2008 上尝试一下
答案4
我注意到，当同一台虚拟机 (Windows 2008r2) 部署在 Intel 或 AMD Magny-Cours VMware 服务器上时，此问题会有所不同。在 AMD 上，连接无限期地停留在 TIME_WAIT 状态，而在 Intel 机器上，它们遵循标准的 4 分钟 TIME_WAIT 超时。