TCP CLOSE_WAIT 状态.. & 新连接答案

【问题标题】：TCP CLOSE_WAIT state.. & new connectionTCP CLOSE_WAIT 状态.. & 新连接
【发布时间】：2012-02-08 09:15:17
【问题描述】：

我在一个众所周知的 TCP 端口上有一个服务器，连接了一堆客户端。客户端使用非阻塞选项连接到服务器。

当我终止服务器进程时，客户端套接字进入 CLOSE_WAIT 状态。现在，如果我重新启动服务器进程并且客户端尝试再次连接，connect() 调用似乎会阻塞，即使它应该是非阻塞的..

实际的解决方法可能是在服务器死机时关闭套接字。但我试图了解当前的行为..

这在 Linux 2.6.3x 内核中可见..

【问题讨论】：

2.6.3x 内核意义不大。 2.6.30 和 2.6.38 之间存在相当大的差异。将内核升级到 3.0.0 或 3.1.0 可能会有所不同。
你在使用SO_REUSEADDR吗？见stackoverflow.com/questions/775638/…
@BasileStarynkevitch 2.6.3x 对于这个问题来说已经足够了。这似乎是一种基本的 TCP/IP 行为，不太可能经常更改。实际版本是 2.6.32。不，我不打算尝试 3.0.0，假设 3.0.0 中的行为可能不同
那么SO_REUSEADDR 选项呢？
SO_REUSEADDR 选项在服务器端不是很有用吗，服务器想在重启后立即在同一个套接字上侦听？在我的情况下，服务器能够绑定到同一个众所周知的端口。但问题在于他们无法连接的客户端..

【解决方案1】：

这听起来像是客户端的错误。如果您将套接字设置为非阻塞，然后调用connect，则connect 调用没有理由阻塞。您可以粘贴创建套接字、将其设置为非阻塞并调用connect 的客户端代码吗？另外，您确定它在connect 调用本身中被阻止了吗？

【讨论】：

这可能是我在客户端中遇到了一个错误。客户端有一个 inotify fd，它使用 libevent 来监控它以跟踪服务器的死亡。看起来 inotify fd 上的读取被阻塞了。我的坏..谢谢。

【解决方案2】：

我相信您的问题得到了完全准确的回答 here 并与 SO_REUSEADDR 相关。另一个answer 与Using SO_REUSEADDR - What happens to previously open socket? 相关的问题也很相关。

【讨论】：