有谁知道在现代标准根服务器上可以使用多少个tcp-socket连接？ （每个连接的流量通常较少，但所有连接都必须一直在运行。）
编辑：我们将使用Linux服务器。
答案 0 :(得分：82)
我实现了1600k并发空闲套接字连接，同时在Linux桌面上实现了57k req / s（16G RAM，I7 2600 CPU）。它是用C语言编写的单线程http服务器。源代码位于github，blog here。
编辑：
我在同一台计算机上使用JAVA / Clojure进行了600k并发HTTP连接（客户端和服务器）。详细信息post，HN讨论：http://news.ycombinator.com/item?id=5127251
连接的费用（使用epoll）：
每个注册的文件描述符大约花费90 32位内核上的字节数，64位内核上的大约160字节。
答案 1 :(得分：22)
这不仅取决于所讨论的操作系统，还取决于配置，可能是实时配置。
对于Linux：
cat /proc/sys/fs/file-max
将显示允许同时打开的当前最大文件描述符数。查看http://www.cs.uwaterloo.ca/~brecht/servers/openfiles.html
答案 2 :(得分：8)
10,000？ 70000？就是这一切：）
FreeBSD可能就是你想要的服务器，这里有little blog post关于调整处理100,000个连接的问题，它现在有一些有趣的功能，比如零拷贝套接字，还有kqueue作为完成港口机制。
Solaris can handle 100,000 connections早在上个世纪！他们说linux会更好
我遇到的最佳描述是关于编写可扩展的网络服务器的演示文稿/论文。他并不害怕这样说：）
软件相同：上面的cretins 应用层强行很大 OS层的创新。因为 Lotus Notes保持一个TCP连接 每个客户开放，IBM贡献主要 优化“一个过程， 100.000开放连接“案例到Linux
最初是O（1）调度程序 创造得好一些 不相关的Java基准测试。底部 这条线是这个膨胀的好处 我们。
答案 3 :(得分：5)
在Linux上，您应该考虑使用epoll进行异步I / O.也许值得微调套接字缓冲区，以免每个连接浪费太多内核空间。
我猜你应该能够在合理的机器上达到100k连接。
答案 4 :(得分：5)
可以在/ proc文件系统
中配置打开套接字数量的限制cat /proc/sys/fs/file-max
由整数限制定义的操作系统中传入连接的最大值。
Linux本身允许数十亿的开放套接字。
要使用套接字，您需要应用程序监听，例如一个Web服务器，每个插槽将使用一定量的RAM。
RAM和CPU将引入真正的限制。 （现代2017年，想想数百万而非数十亿）
100万是可能的，不容易。预计使用X千兆字节的RAM来管理100万个插槽。
传出 TCP连接受端口号限制〜每个IP 65000。您可以拥有多个IP地址，但不能拥有无限制的IP地址。 这是TCP而非Linux的限制。
答案 5 :(得分：3)
取决于应用程序。如果每个客户端只有几个软件包，那么100K很容易用于linux。我的团队的一名工程师在几年前做过测试，结果显示：当连接建立后没有来自客户端的软件包时，linux epoll可以在CPU使用率低于50％的情况下观看400k fd的可读性。
答案 6 :(得分：1)
哪个操作系统？
对于Windows机器，如果您正在编写服务器以进行扩展，因此使用I / O完成端口和异步I / O，则主要限制是您正在使用的非页面缓冲池的数量每个活动连接。这会直接转换为基于计算机已安装的内存量的限制（非页面缓冲池是基于安装的总内存的有限固定大小量）。
对于没有看到太多流量的连接，您可以通过发布不使用非页面缓冲池的“零字节读取”来减少它们的效率，并且不会影响锁定的页面限制（另一个可能有限的资源，可能会阻止你打开很多套接字连接）。
除此之外，您需要进行配置，但我已经设法在一个适度指定的（760MB内存）服务器上获得超过70,000个并发连接;有关详细信息，请参阅此处http://www.lenholgate.com/blog/2005/11/windows-tcpip-server-performance.html。
显然，如果您使用效率较低的架构，例如“每个连接的线程”或“选择”，那么您应该期望获得不那么令人印象深刻的数字;但是，恕我直言，没有理由为Windows套接字服务器选择这样的架构。
修改：点击此处 http://blogs.technet.com/markrussinovich/archive/2009/03/26/3211216.aspx;计算非分页池数量的方式在Vista和Server 2008中发生了变化，现在有更多可用。
答案 7 :(得分：-8)
我怀疑这个数字被选中是因为它很难，但理论上可行。
答案 8 :(得分：-9)
实际上，对于一个应用程序，单个机器上超过4000-5000个开放套接字变得不切实际。只检查所有套接字上的活动并管理它们就开始成为性能问题 - 尤其是在实时环境中。