无法连接到本地端口，因为该端口仍然被一个进程监听。

Question

我有一个服务器应用程序（unimrcpserver.exe），它正在响应客户端进程的请求。这个服务器进程监听着几个端口。 使用netstat -a命令，我可以得到我的进程的以下行。

  TCP    192.168.10.65:2544     MERTB-PC:0             LISTENING  
  TCP    192.168.10.65:2554     MERTB-PC:0             LISTENING  
  TCP    192.168.10.65:9060     MERTB-PC:0             LISTENING  

通常情况下，当系统正常工作时，我从这些端口向服务器发出请求，每个端口都能正常工作。

在进行压力测试时，我遇到了一个情况，系统不再响应我通过端口2554发出的请求。 netstat -a 仍然显示以上行内容，因此服务器仍然在监听此端口。当我在同一台机器上运行telnet时，它会给出一个错误：

telnet 192.168.10.65 2554  
  Connecting To 192.168.10.65...Could not open connection to the host, on port 2554: Connect failed

我还用c++编写了一个简单的程序，以获取系统生成的连接（connect()）请求的确切错误消息。这次我得到了以下错误：

No connection could be made because the target machine actively refused it

附加信息: 所有内容都在同一台Windows机器上。防火墙已禁用。这种情况仅在我进行压力测试时发送多个请求同时发生。在出现这种情况之前，系统处理了约13000个请求，大约花费了半个小时。

所以问题是: 这种情况如何发生？ netstat报告该端口正在“LISTENING”，但我无法连接到它。如果这可能是由编程错误引起的，什么样的错误会导致这种行为？

- Mert

---

然后检查可以使用这些端口的程序。您可以运行 ps ax | grep 2544。 - ForceBru

检查 listen 调用的 backlog 参数，它应该是一个很大的值。或者可能是您无法足够快地接受传入连接... - Malkocoglu

@ForceBru 这是一台Windows机器。我使用netstat -a命令检查过了，没有其他程序占用这个端口。 - Mert

@Malkocoglu 这是可能的，因为这是一个使用大量CPU资源的程序。监听调用是在我不拥有的模块中进行的（即unimrcp），我已经将系统附加到调试器上，但挂起后没有调试信息，因此我可能无法看到该参数的值。 - Mert

好的，我了解了SOMAXCONN，它似乎不是问题所在。它的值已经足够高了。 - Mert

Answer 1

在几种情况下，新连接可能会被“主动拒绝”：

1. 正在连接的IP:Port上没有处于“LISTENING”状态的套接字。

2. 存在一个“LISTENING”套接字，但它的待处理连接队列已满，因此它无法在此时接受新的连接。

3. 防火墙将其阻止。尽管防火墙更有可能使用不同的错误，如果它发送了一个错误的话。

由于存在“LISTENING”套接字，#2是最常见的情况。如果是这样，那么意味着服务器应用程序无法快速接受其待处理客户端连接，如果完全无法接受的话。

客户端无法区分这些条件。 它所能做的就是检测连接失败 - 根据平台不同为“WSAECONNREFUSED”或“ECONNREFUSED” - 并稍后重试。

- Remy Lebeau

---

嗯，所以套接字处于LISTENING状态。但负责接收传入连接的线程已经陷入死锁。这导致由SOMACONN确定大小的传入连接队列变满。我想这就解释了情况。 - Mert

Answer 2

问题是：为什么会出现这种情况？使用netstat命令时，端口显示“LISTENING”，但我无法连接它。如果这是由编程错误引起的，什么样的错误会导致这种行为？

是的，这可能是由服务器上的编程错误引起的。当服务器的监听线程死锁时，我见过这种情况。套接字的状态是“listening”，但是如果监听线程具有某些全局状态，并且被阻塞在等待其他线程释放互斥锁的状态，那么你就会遇到这个问题。 此外，正如其他人在这里所述，如果CPU由于压力测试而负载过高，这可能会导致服务器拒绝连接，因为线程可能正在忙于处理工作，而监听线程从未有机会接受连接。

- shaks

---

看起来是正确的答案，但 Remy 更快。 :) 谢谢。 - Mert

另一个可能性是监听线程可能已经崩溃而不是死锁。 - Remy Lebeau