有谁知道在现代标准根服务器上可以有多少个tcp-socket连接？(每个连接的流量通常较少,但所有连接都必须一直在运行.)
编辑:我们将使用Linux服务器.
因此，我正在开发一个 C++ 应用程序，该应用程序当前使用 C 套接字在对等点之间传输数据。有 n 个对等点，并且都运行相同的代码。在应用程序逻辑中，任何对等点都可能需要将（可能很大）数据传输到任何其他对等点，因此首先在所有可能的对等点组合之间打开连接。要求是应用程序逻辑和数据（可能很大）的网络传输应尽可能快。
目前，在任意 2 个对等点（例如 A 和 B）之间，应用程序会打开 2 种类型的连接 - 其中 A 是服务器，B 是客户端，反之亦然。这样做可能是为了如果 A 需要同时向 B 传输数据，反之亦然，则整个过程可以比仅从 A 到 B 具有一种连接类型更快地完成。对于每种连接类型（例如，其中 A 是服务器，B 是服务器）客户端），然后应用程序打开 3 个 TCP 连接（使用 C 套接字）。然而，目前的编码方式最终仅使用这 3 个连接之一。
看到这一点，我开始想知道，为了充分利用 N 个打开的连接，也许可以使用循环或某种策略来将数据分成块并同时传输。然而，我不清楚应该打开多少个并行 TCP 连接以及这些连接之间使用什么策略。这个答案还取决于哪些因素？例如，如果我打开 1000 个 TCP 连接，有什么危害？（忽略系统限制，例如端口耗尽等）
如果有人能够阐明当今的应用程序如何利用多个并行 TCP 连接来获得最佳性能，那就太好了。快速的谷歌搜索让我找到了几篇研究论文，但我也有兴趣了解例如网络浏览器如何解决这个问题。
谢谢！
更新：在与一些对 TCP 有更多了解的人交谈之后，我有了更好的了解。首先，我的前提是在 A 和 B 之间打开两种类型的连接（其中 A 是客户端，B 是服务器，反之亦然）将有助于增加网络吞吐量，这似乎是错误的。在 A 和 B 之间打开一种类型的 TCP 连接就足够了。这取决于数据报是否能够同时从 A 传输到 B，反之亦然。我发现这个链接很有用：Is TCP bi Direction or full-duplex?。
另外，为了充分利用可用的带宽，最好打开多个 TCP …
有没有办法克服Linux系统上的端口限制？我们有一个运行的服务器接受传入的连接,它使用非常少的内存和CPU.我们必须构建一个小型Linux机箱集群才能克服软件限制(大约60k的点数),这是相当愚蠢的.有任何想法吗？