Linux TCP关闭\u等待状态&；新连接

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

当我终止服务器进程时，客户端套接字进入关闭等待状态。现在，如果我重新启动服务器进程，客户机再次尝试连接，则connect（）调用似乎会阻塞，即使它应该是非阻塞的

实际的修复方法可能是在服务器死机时关闭套接字。但我正在努力了解目前的行为

• 当现有连接处于关闭状态时，\u等待是什么阻止建立新连接
• 为什么即使设置了is non blocking选项，连接也会阻塞

---

这可以在Linux 2.6.3x内核中看到

我相信你的问题得到了非常准确的回答，并且与

有关，因此_REUSEADDR

。另一个问题也与此相关。

这听起来像是客户机中的一个bug。如果将套接字设置为非阻塞，然后调用

connect

，则

connect

调用没有理由阻塞。能否粘贴创建套接字、将其设置为非阻塞并调用

connect

的客户端代码？另外，您确定它在

connect

调用本身中被阻塞了吗？

2.6.3x内核并不意味着什么。2.6.30和2.6.38之间有相当大的差异。将内核升级到3.0.0或3.1.0可能会有所不同。您使用的是

SO\u REUSEADDR

？请参阅@BasileStrynkevitch 2.6.3x，这是关于此问题的足够信息。这似乎是一种基本的TCP/IP行为，不太可能经常改变。实际版本为2.6.32。不，我不打算尝试3.0.0，因为我假设3.0.0中的行为可能不同，那么

SO\u REUSEADDR

选项呢？SO\u REUSEADDR选项在服务器端不是很有用吗？在服务器端，服务器希望在重启后立即侦听同一个套接字？在我的例子中，服务器能够绑定到相同的已知端口。但是问题是客户端无法连接。恐怕你错了，所以REUSEADDR允许服务器绑定到一个处于等待状态的地址。正如我所说，我的问题是在客户端。我对

SO\u REUSEADDR

的不完全理解是它正在改变连接本身，而不仅仅是服务器端。

SO\u REUSEADDR

只影响服务器是否被允许绑定。可能是我在客户端有一个bug。。客户机有一个inotiffd，它使用libevent监视该fd以跟踪服务器的死亡。看起来inotify fd上的读取被阻塞。我的错。。谢谢。