Windows 2008 Server SP2 64bit - TCP 连接在 TIME_WAIT 后永远不会释放

Question

Windows 2008 数据中心版 SP2 64 位存在问题。我们有一个进程非常频繁地轮询并建立新的 TCP 连接。系统进入一种状态，我们最终在 TIME_WAIT 状态下有超过 16k 个连接。默认操作系统超时为 120 秒，之后这些连接应该会消失，但这种情况永远不会发生。即使在原始进程长期终止之后，这些连接仍然存在并且永远不会被清除（在进程被终止两天后，我们仍然有 16k 连接）。操作系统应该让它们超时，但事实并非如此。

有没有其他人看到过这种行为，如果有，采取了什么措施来解决它。我们知道如何调整 tcp 堆栈以缩短超时时间或允许更多连接，但这不是这里的问题。

谢谢！

Answer 1

Amazon EC2 在这方面有一个主要问题。他们最近修复了这个错误。也许同样的问题适用于您的情况？

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

Answer 2

有一篇Microsoft 文章描述了解决此问题的几种方法。它通常来自编码错误且未正确关闭端口的应用程序。您需要查看已安装的应用程序或正在执行的任务，然后禁用这些应用程序以查看导致问题的原因。

要解决这个问题，您需要考虑其中一个；

1. 增加动态分配给客户端 TCP/IP 套接字连接的临时端口的上限范围。
2. 将客户端 TCP/IP 套接字连接超时值从默认值 240 秒减少（更永久的修复）