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

Posted 2021-04-16

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

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

答案

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

今天，我担心带ASP.NET的IIS是否支持100个并发连接的顺序（看看我的更新，期望在旧的ASP.Net Mono版本上每秒约10k响应）。当我看到这个问题/答案时，我无法抗拒回答自己，这里的问题很多答案都是完全错误的。

最佳案例

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

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

1. 除了保持活动数据包之外，TCP会话没有流量（否则您显然需要相应数量的网络带宽和其他计算机资源）
2. 软件旨在使用异步套接字和编程，而不是来自池的每个请求的硬件线程。 （即IIS，Node.js，nginx ... webserver [但不是Apache]与异步设计的应用程序软件）
3. 良好的性能/美元CPU / Ram。今天，任意地，让我们说i7（4核）与8GB的RAM。
4. 一个好的防火墙/路由器匹配。
5. 没有虚拟限制/调控器 - 即。 Linux somaxconn，IIS web.config ......
6. 不依赖于其他较慢的硬件 - 没有读取硬盘，因为它将是最低的公分母和瓶颈，而不是网络IO。

详细解答

相对于异步IO实现，同步线程绑定设计往往表现最差。

WhatsApp在一台Unix风格的操作系统机器上获得了100万的流量 - 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
• 使用的硬件：戴尔R440 Xeon Gold + 10 GbE
• 领导者每秒有~7M纯文本响应（响应不是连接）
• golang的第二个Fasthttp广告1.5M并发连接 - 请参阅https://github.com/valyala/fasthttp
• 领先的语言是Rust，Go，C ++，Java，C，甚至C＃排名为11（每秒6.9M）。 Scala和Clojure排名进一步下滑。 Python以每秒2.7M的速度排名第29位。
• 在列表的底部，我注意到laravel和cakephp，rails，aspnet-mono-ngx，symfony，zend。全都低于每秒10k。请注意，这些框架中的大多数都是针对动态页面构建的，并且相当陈旧，可能有更新的变体在列表中具有更高的特征。
• 请记住，这是HTTP明文，而不是Websocket专业：很多人来到这里可能会对websocket的并发连接感兴趣。

另一答案

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

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

另一答案

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

cat / proc / sys / net / core / somaxconn

这个数字可以动态修改（当然只有root用户）

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

但完全取决于服务器进程，机器和网络的硬件，崩溃系统之前可以连接的实际插座数量

另一答案

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

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

当谈到它时，这是一个典型的例子，说“理论与实践之间的差异在实践中比在理论上要大得多” - 在实践中，实现更高的数字似乎是一个循环。提出具体的配置/架构/代码更改，b。测试它直到你达到极限，c。我完成了吗？如果不是那么d。找出限制因素，e。回到步骤a（冲洗并重复）。

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

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

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

另一答案

请注意，HTTP通常不会使TCP连接保持打开状态，而不是将页面传输到客户端;用户通常需要花费更多的时间来阅读网页而不是下载页面...当用户正在查看页面时，他根本不会给服务器增加任何负担。

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

另一答案

在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个套接字

另一答案

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

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

另一答案

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

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

因此，无论Web服务器如何处理连接，每个连接最终都会消耗一些资源。