我有一个在 AIX 6.1 上运行的应用程序，它有一个服务器进程，用于侦听和轮询 TCP 连接，并使用 IPC 消息队列简单地将消息转发到另一个进程。它已经运行多年，通常可以毫无问题地处理 1000 个或更多的连接。但昨天我们遇到了一种情况，即与此服务器的连接大部分时间都超时。同时，与此服务器的另一个实例（在同一台机器上侦听不同的端口号）的连接工作正常。此外，通过现有连接的数据流动也很顺畅，处理器负载也很小。
这种情况持续了几个小时，即使重新启动了有问题的监听器后，这种情况仍然继续发生。然后今天早上突然间，情况就好了，一切都正常了。
真正奇怪的是，在同一台服务器机器上运行的客户端进程的内部连接也会出现延迟，有时还会超时。
是否存在某种方式，使得连接请求被卡在网络某处失败的连接后面，从而使服务在很长一段时间内似乎对所有人都不可用 - 然后又迅速恢复正常？并且这只影响新连接 - 而不是由同一进程处理的现有套接字？
谢谢，罗布
注意 - 我们可能已经解决了这个问题。看起来好像有一个网络位置正在实现部分连接（也许入站数据包是可路由的，但出站数据包不是）。无论如何，有大量连接处于 SYN_RCVD 状态，并且服务器侦听套接字上的“backlog”参数只有 5，因此，一群试图从错误位置连接的用户足以耗尽整个可用积压，并且不让任何其他人进入 - 我想直到某些事情导致部分连接超时。
因此，我想我会修改我的问题，只问将“Backlog”参数设置为 listen() 的良好经验法则是什么。我目前已将其从 5 增加到 20 - 但我们多年来一直使用 5，没有出现问题。