Web 服务器可以处理多少个套接字连接？答案

【问题标题】：How many socket connections can a web server handle?Web 服务器可以处理多少个套接字连接？
【发布时间】：2010-12-07 05:20:18
【问题描述】：

假设我要获得共享、虚拟或专用主机，我在某处看到一台服务器/机器一次只能处理 64,000 个 TCP 连接，这是真的吗？无论带宽如何，任何类型的托管都可以处理多少？我假设 HTTP 通过 TCP 工作。

这是否意味着只有 64,000 名用户可以连接到该网站，如果我想提供更多服务，我就必须搬到网络农场？

【问题讨论】：

向响应者道歉，我已经像龙卷风一样撕开了这个线程。我喜欢的错误答案太多了，仍然没有直接的答案。我经常使用 stackoverflow 并找到许多高质量的答案。我希望其他人能够找到此线程并找到有用的知情答案。
嗨大卫，你找到这个问题的正确答案了吗？
64000 个 TCP 连接，通过服务器的单个 IP。您可以升级您的服务器网络以扩展并支持超过 64000 个。

标签： http tcp network-programming hosting tcplistener

【解决方案1】：

简而言之：您应该能够实现 数百万 的同时活动 TCP 连接和扩展 HTTP 请求。这会告诉您使用正确的平台和正确的配置可以获得的最大性能。

今天，我担心带有 ASP.NET 的 IIS 是否会支持大约 100 个并发连接（查看我的更新，预计旧 ASP.Net Mono 版本每秒大约 10k 响应）。当我看到这个问题/答案时，我忍不住回答了自己，这里问题的许多答案是完全错误的。

最佳案例

这个问题的答案必须只关注最简单的服务器配置，以便与下游可能的无数变量和配置解耦。

因此，请考虑以下场景作为我的答案：

TCP 会话上没有流量，除了保持活动的数据包（否则您显然需要相应数量的网络带宽和其他计算机资源）
设计为使用异步套接字和编程的软件，而不是每个来自池的请求的硬件线程。（即 IIS、Node.js、Nginx...网络服务器 [但不是 Apache]，带有异步设计的应用软件）
良好的性能/美元 CPU / 内存。今天，随便说一下具有 8GB RAM 的 i7（4 核）。
一个很好的防火墙/路由器来匹配。
没有虚拟限制/州长 - 即。 Linux somaxconn、IIS web.config...
不依赖于其他较慢的硬件 - 不从硬盘读取，因为它是最小的公分母和瓶颈，而不是网络 IO。

详细解答

与异步 IO 实现相比，同步线程绑定设计的性能往往最差。

WhatsApp 可以在一台 Unix 风格的操作系统机器上处理一百万个 WITH 流量 - https://blog.whatsapp.com/index.php/2012/01/1-million-is-so-2011/。

最后，http://highscalability.com/blog/2013/5/13/the-secret-to-10-million-concurrent-connections-the-kernel-i.html 详细介绍了很多细节，探讨了如何达到 1000 万。服务器通常具有硬件 TCP 卸载引擎，专为这一特定角色设计的 ASIC 比通用 CPU 更有效。

良好的软件设计选择

异步 IO 设计会因操作系统和编程平台而异。 Node.js 在设计时考虑到了异步。你至少应该使用 Promises，当 ECMAScript 7 出现时，async/await。 C#/.Net 已经像 node.js 一样拥有完整的异步支持。无论操作系统和平台如何，都应该期望异步执行得非常好。不管你选择什么语言，寻找关键字“异步”，大多数现代语言都会有一些支持，即使它是某种附加组件。

到 WebFarm？

无论您的特定情况有什么限制，是的，网络农场是一种很好的扩展解决方案。有许多架构可以实现这一点。一种是使用负载均衡器（托管服务提供商可以提供这些，但即使这些也有限制，还有带宽上限），但我不赞成这个选项。对于具有长时间运行连接的单页应用程序，我更喜欢有一个开放的服务器列表，客户端应用程序将在启动时随机选择这些服务器，并在应用程序的整个生命周期内重复使用。这消除了单点故障（负载均衡器），并支持通过多个数据中心进行扩展，从而获得更多带宽。

打破神话 - 64K 端口

要解决有关“64,000”的问题部分，这是一种误解。一台服务器可以连接到超过 65535 个客户端。见https://networkengineering.stackexchange.com/questions/48283/is-a-tcp-server-limited-to-65535-clients/48284

顺便说一下，Windows 上的 Http.sys 允许多个应用程序在 HTTP URL 架构下共享同一个服务器端口。它们各自注册一个单独的域绑定，但最终只有一个服务器应用程序将请求代理到正确的应用程序。

2019-05-30 更新

这是最快的 HTTP 库的最新比较 - https://www.techempower.com/benchmarks/#section=data-r16&hw=ph&test=plaintext

测试日期：2018-06-06
使用的硬件：Dell R440 Xeon Gold + 10 GbE
领导者每秒有大约 700 万个明文响应（响应不是连接）
golang 的第二个 Fasthttp 广告 1.5M 并发连接 - 见https://github.com/valyala/fasthttp
领先的语言是 Rust、Go、C++、Java、C，甚至 C# 排名第 11 位（每秒 690 万）。 Scala 和 Clojure 排名更靠后。 Python 以每秒 270 万的速度排在第 29 位。
在列表的底部，我注意到 laravel 和 cakephp、rails、aspnet-mono-ngx、symfony、zend。全部低于每秒 10k。请注意，这些框架中的大多数都是为动态页面构建的，而且相当陈旧，可能会有更新的变体在列表中排名靠前。
请记住，这是 HTTP 纯文本，不适用于 Websocket 专业：许多来到这里的人可能会对 websocket 的并发连接感兴趣。

【讨论】：

感谢您提供链接，让人们谈论他们的工作方式。
如果客户端连接的单台服务器宕机了怎么办？如果您的所有 SPA 随机连接到一台服务器并使其过载怎么办？使用负载均衡器的想法不仅仅是使用 1，您可以随意使用多个
客户端会随机选择一个服务器。所有随机连接到一个的机会实际上是不可能的。虽然可以跟进客户端计数，如果过于拥挤，服务器可能会要求客户端移动到另一台服务器。
Re: 64K 限制 - 你说的是真的，但是服务器应用程序通过某些后端服务代理请求是相当普遍的，在这种情况下，“服务器”现在变成一个“客户”，可能不得不担心临时端口耗尽（例如：nginx.com/blog/overcoming-ephemeral-port-exhaustion-nginx-plus）。我确定您知道，但请为其他人提及（：
@jwd 好点，适用于网络应用程序上的 nginx 上下文，但对于基本网站，不需要进行此类代理。 Web 应用程序通过 TCP 连接到数据库也可以这样说。理论上，这可以通过使用 127.*.*.* 范围内的所有地址来解决，但实际上我不知道这是否可用。

【解决方案2】：

这个问题是一个相当困难的问题。一台机器可以拥有的活动连接数量没有真正的软件限制，尽管某些操作系统比其他操作系统更受限制。问题成为资源之一。例如，假设一台机器想要支持 64,000 个同时连接。如果服务器每个连接使用 1MB 的 RAM，则需要 64GB 的 RAM。如果每个客户端都需要读取一个文件，那么磁盘或存储阵列的访问负载就会变得远远超出这些设备的处理能力。如果服务器需要为每个连接派生一个进程，那么操作系统将花费大部分时间进行上下文切换或使进程缺乏 CPU 时间。

C10K problem 页面对此问题进行了很好的讨论。

【讨论】：

有点混杂的答案。 OP 似乎指的是最好的情况，包括如何有益，而不是找到最坏的情况，然后参考可能有解决方案的文章。注意磁盘瓶颈很有用。使用异步 IO 可以达到非常多的并发客户端。
你怎么能说没有真正的软件限制，因为端口大小本身是 16 位，这使得在任何时候最大 65.5K 都没有可用的端口。我认为您的答案不正确。
您的机器可以有超过 1 个 IP，因此有超过 2^16 个端口可用。

【解决方案3】：

将我的两分钱添加到对话中，一个进程可以同时打开多个连接等于该数量的套接字（在 Linux 类型系统中）/proc/sys/net/core/somaxconn

cat /proc/sys/net/core/somaxconn

这个数字可以随时修改（当然只能由root用户）

echo 1024 > /proc/sys/net/core/somaxconn

但完全取决于服务器进程、机器硬件和网络、系统崩溃前可以连接的真实套接字数

【讨论】：

虽然 Linux 可能如此，但这指的是虚拟限制，而不是可能性的基准。这个答案对我来说有点具体，并且没有提供任何数量或并发连接数量的指示。尽管您很努力，但它并不是很有用。也许你可以自己回答一个问题：“为什么我不能在 Linux 上同时提供超过 X 个并发 TCP 连接”
据我所知这是错误。 somaxconn 是打开的套接字上的最大排队连接数（即它是listen(int socket, int backlog) 的积压参数的最大值。它与进程可以打开的套接字数无关。

【解决方案4】：

如果你有一个强大的服务器，你的服务器软件已经针对它进行了优化，你有足够的客户端，那么答案看起来至少是 1200 万。如果从一台客户端到一台服务器进行测试，客户端上的端口号数量将是明显的资源限制之一（每个 TCP 连接由源和目标的 IP 和端口号的唯一组合定义）。

（您需要运行多个客户端，否则您首先会达到端口号的 64K 限制）

归根结底，这是“理论与实践之间的差异在实践中比在理论中大得多”的俏皮话的经典例子——在实践中实现更高的数字似乎是一个循环。提出具体的配置/架构/代码更改，b。测试它直到你达到极限，c。我完成了吗？如果没有，那么 d.找出什么是限制因素，例如。返回步骤 a（冲洗并重复）。

这是一个示例，200 万个 TCP 连接连接到运行 Phoenix http://www.phoenixframework.org/blog/the-road-to-2-million-websocket-connections 的强大机器（128GB RAM 和 40 个内核）上 - 他们最终需要 50 台左右相当重要的服务器来提供客户端负载（他们最初的较小客户端早到早，例如“最大化我们的 4core/15gb 盒子 @ 450k 客户”）。

这里是 Go 这次 1000 万的另一个参考：http://goroutines.com/10m。

这似乎是基于 java 和 1200 万个连接：https://mrotaru.wordpress.com/2013/06/20/12-million-concurrent-connections-with-migratorydata-websocket-server/

【讨论】：

很棒的新链接，对问题有正确的理解。我喜欢关于 hit-barrier -> fix barrier 的一般建议。每个人都有不同的具体情况，但至少他们在这里表明了经济/实际可以实现的目标。短期内不应向客户承诺每台服务器 1 亿美元。

【解决方案5】：

请注意，HTTP 通常不会保持 TCP 连接打开的时间超过将页面传输到客户端所需的时间；并且用户阅读网页所花费的时间通常比下载页面所花费的时间要多得多......当用户查看页面时，他根本不会给服务器增加任何负载。

因此，可以同时查看您网站的人数远大于它可以同时服务的 TCP 连接数。

【讨论】：

这根本不能回答问题。不管您所说的准确性如何，在给定时间仍然会有许多并发 TCP 连接，最大是多少？这是问题的本质。
如果你有什么值得贡献的东西，托德，一定要去做。
我已经在 3 月 28 日收到了答复，您一定错过了。在具有长轮询和 Web 套接字连接的现代单页应用程序世界中，HTTP 并不总是短暂的。但即使它是短暂的，仍然存在最大并发连接数。试图解释这个问题不是一个anwer IMO。这个答案最好作为对该问题的评论，它当然很有用，但问题与“套接字连接”有关，而不是“人”。如果需要，关于比率（用户：活跃连接）的问题应该是一个单独的问题。
Keep Alive on HTTP TCP 连接自上个千年以来一直存在并被浏览器请求 - 它是否允许连接保持活动状态以及空闲超时时间将取决于服务器.允许 Keep Alive 可减少一组请求（例如 html 页面及其相关资产）的延迟，但会增加服务器上的资源使用率。

【解决方案6】：

在 IPv4 协议的情况下，具有一个 IP 地址的服务器只能侦听一个端口，它可以处理 2^32 个 IP 地址 x 2^16 个端口，因此 2^48 个唯一套接字。如果您将服务器称为物理机器，并且您能够使用所有 2^16 个端口，那么一个 IP 地址最多可以有 2^48 x 2^16 = 2^64 个唯一 TCP/IP 套接字。请注意，有些端口是为操作系统保留的，所以这个数字会更低。总结一下：

1 个 IP 和 1 个端口 --> 2^48 个套接字

1 个 IP 和所有端口 --> 2^64 个套接字

Universe 中所有唯一的 IPv4 套接字 --> 2^96 个套接字

【讨论】：

【解决方案7】：

这里有两个不同的讨论：一个是有多少人可以连接到您的服务器。其他人已经充分回答了这个问题，所以我不再赘述。

你的服务器可以监听多少个端口？我相信这就是 64K 数字的来源。实际上，TCP 协议使用一个 16 位的端口标识符，它转换为 65536（比 64K 多一点）。这意味着您可以在每个 IP 地址的服务器上拥有许多不同的“侦听器”。

【讨论】：

为了您的利益，我在答案中添加了一个额外的部分，以解决您的误解。这个问题也与“套接字连接”而不是“人”有关，这是在这个问题的上下文中的一个重要区别。
如果我们说的是一台服务器机器和一台路由器，我认为这个答案是正确的。但是@Todd 正在处理一个服务器机器群，用户可以通过负载平衡器随机连接到其中的任何一个。
@amr 不正确。我的回答是关于一台机器。 “网络农场？”部分有对比和建议以超越并得出结论，负载均衡器对于良好的架构不是必需的。你只是还没有仔细阅读我的答案。

【解决方案8】：

我认为一台 Web 服务器可以处理的并发套接字连接的数量很大程度上取决于每个连接消耗的资源量以及服务器上可用的总资源量，除非有任何其他 Web 服务器资源限制配置。

为了说明，如果每个套接字连接消耗 1MB 的服务器资源并且服务器有 16GB 的可用 RAM（理论上），这意味着它只能处理 (16GB / 1MB) 并发连接。我认为就这么简单……真的！

所以无论网络服务器如何处理连接，每个连接最终都会消耗一些资源。

【讨论】：