![Windows 2008 Server SP2 64 位-TIME_WAIT 之后 TCP 连接永不释放](https://linux22.com/image/529910/Windows%202008%20Server%20SP2%2064%20%E4%BD%8D-TIME_WAIT%20%E4%B9%8B%E5%90%8E%20TCP%20%E8%BF%9E%E6%8E%A5%E6%B0%B8%E4%B8%8D%E9%87%8A%E6%94%BE.png)
我们在使用 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 超时。