我们遇到了一个问题，当相对少量的节点（16 到 24 个，但我们将来需要处理更多）同时尝试连接时，我们的传入客户端套接字连接被拒绝到我们的套接字服务器。
一些细节：
- 服务器在 Windows 2008 或 7 上运行
- 我们的主服务器是使用 ServerSocket 用 Java 编写的
- 客户端也是在我们数据中心的网格节点上运行的 Windows
当我们尝试在网格上进行测试运行时，客户端节点尝试连接到服务器并发送一个 40-100K 的数据包，然后断开连接。使用 16 到 24 个节点，我们开始看到客户端连接无法连接到服务器的问题。鉴于这种设置，我们正试图处理最多 16-24 个并发客户端连接和失败，这对我们来说似乎根本不正确。
主服务器循环正在侦听常规的 SocketServer，当它获得连接时，它会生成一个新线程来处理连接，并立即返回以侦听套接字。我们还有一个虚拟的 python 服务器，它简单地读取和丢弃传入的数据，还有一个 C++ 服务器，它在转储数据之前记录数据，两者都遇到同样的问题，客户端无法连接，之前成功的客户端连接的数量有微小的变化失败开始。这使我们相信任何特定的服务器在这个问题上都没有错，它可能是环境问题。
我们的第一个想法是增加套接字上的 TCP 积压。即使被推到非常高的水平，这也没有缓解这个问题。Java SocketServer 的默认值是 50，远低于我们的处理能力。
我们已经在同一子网的机器之间运行了测试，并禁用了机器上的所有本地防火墙，以防 FW 对我们与服务器的连接进行速率限制；没有成功。
我们已经尝试在运行服务器的 Windows 机器上调整网络：
- 减少 TimedWaitDelay，但没有效果（在我的 Python 测试中它不应该因为该测试只运行几毫秒）。
- 将 MaxUserPort 增加到一个较大的值，大约 65000，但没有效果（这很奇怪，因为我的 Python 测试只发送 240 条消息，所以我什至不应该接近这种类型的限制）。
- 将 TcpNumConnection 增加到一个较大的值（不记得确切的数字）。同样，我们一次不应该有超过 24 个连接，所以这不能是一个限制。
- 启动“动态积压”功能，允许消息积压动态增加。我认为我们将最大连接数设置为 2000，最小连接数为 1000，但没有效果。同样，Python 不应建立超过 240 个连接，因此我们甚至不应该激活动态积压。
- 除了上述禁用 TCP 端口的 Windows“自动调整”之外。再次，没有效果。
我的感觉是 Windows 以某种方式限制了入站连接的数量，但我们不确定要修改什么以允许更多的连接。网络上的代理限制连接速率的想法似乎也不正确。我们高度怀疑同时连接的数量是否会使物理 GB 网络超载。
我们很难过。有没有其他人遇到过这样的问题并找到了解决方案？