说如果要共享,虚拟或专用托管,我读到某处服务器/机器一次只能处理64,000个TCP连接的情况,这是真的吗?不管带宽如何,任何类型的主机可以处理多少个?我假设HTTP通过TCP起作用。
这是否意味着只有64,000个用户可以连接到该网站,并且如果我想提供更多服务,就不得不转到网络农场?
说如果要共享,虚拟或专用托管,我读到某处服务器/机器一次只能处理64,000个TCP连接的情况,这是真的吗?不管带宽如何,任何类型的主机可以处理多少个?我假设HTTP通过TCP起作用。
这是否意味着只有64,000个用户可以连接到该网站,并且如果我想提供更多服务,就不得不转到网络农场?
Answers:
简而言之:您应该能够实现数百万个同时活动的TCP连接并通过扩展HTTP请求来实现。这告诉您在具有正确配置的正确平台上可以期望的最大性能。
今天,我担心带有ASP.NET的IIS是否会支持100个并发连接(请看我的更新,在较旧的ASP.Net Mono版本上,期望每秒约有1万个响应)。当我看到这个问题/答案时,我忍不住要回答自己,这里很多问题的答案都是完全错误的。
最好的情况
这个问题的答案必须只涉及最简单的服务器配置,以与可能的下游无数变量和配置脱钩。
因此,请考虑以下情况作为我的答案:
详细答案
相对于异步IO实现,同步线程绑定设计的性能往往最差。
WhatsApp的得到一个亿,在一个单一的Unix交通味OS机- 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。无论使用哪种操作系统和平台,都应该期望异步性能很好。无论选择哪种语言,只要寻找关键字“ asynchronous”,大多数现代语言都将获得某种支持,即使它是某种形式的附加组件。
到WebFarm?
无论您的特定情况有多大的限制,是的,网络农场都是扩展规模的好方法。有许多架构可以实现这一目标。一种是使用负载均衡器(主机提供商可以提供这些负载均衡器,但即使这些负载均衡器也有限制,以及带宽上限),但我不赞成使用此选项。对于具有长时间运行的连接的单页应用程序,我更喜欢有一个服务器的开放列表,客户端应用程序将在启动时从服务器中随机选择,并在应用程序的生命周期内重复使用。这样可以消除单点故障(负载均衡器),并能够扩展多个数据中心,从而增加带宽。
打破神话-64K端口
为了解决有关“ 64,000”的问题部分,这是一个误解。服务器可以连接到超过65535个客户端。参见/networkengineering/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
这个问题是一个相当困难的问题。尽管某些操作系统比其他操作系统受到的限制更大,但计算机对活动连接的数量没有真正的软件限制。问题成为资源之一。例如,假设一台计算机要支持64,000个并发连接。如果服务器每个连接使用1MB的RAM,则它将需要64GB的RAM。如果每个客户端都需要读取文件,则磁盘或存储阵列的访问负载将变得远远超过这些设备所能承受的负载。如果服务器需要为每个连接派生一个进程,则操作系统将花费其大部分时间上下文切换或使进程饿死于CPU时间。
该C10K问题页面有这个问题的一个很好的讨论。
要在对话中增加我的两分钱,一个进程可以同时打开等于此数字的套接字(在Linux类型系统中)/ proc / sys / net / core / somaxconn
猫/ proc / sys / net / core / somaxconn
可以即时修改此数字(当然,只能由root用户修改)
回声1024> / proc / sys / net / core / somaxconn
但是,这完全取决于服务器进程,机器的硬件和网络,系统崩溃前可以连接的套接字的实际数量。
listen(int socket, int backlog)
。它与进程可以打开的套接字的数量无关。)
如果您拥有强大的服务器,并且服务器软件已针对该服务器进行了优化,并且拥有足够的客户端,则答案似乎至少为1200万。如果从一个客户端到一台服务器进行测试,则客户端上的端口号数量将是明显的资源限制之一(每个TCP连接都由源和目标处IP和端口号的唯一组合定义)。
(您需要运行多个客户端,否则首先要达到端口号的64K限制)
归根结底,这是一个见证人的经典例子:“理论与实践之间的差异在实践中要比理论上大得多”-在实践中获得更高的数字似乎是一个循环。提出特定的配置/架构/代码更改; b。测试直到达到极限,c。我吃完了吗 如果没有,则d。找出什么是限制因素,e。返回到步骤a(冲洗并重复)。
这是一个示例,其中有200万个TCP连接到运行Phoenix的强壮的盒子(128GB RAM和40个内核)上http://www.phoenixframework.org/blog/the-road-to-2-million-websocket-connections-它们结束了仅需要50台左右的相当重要的服务器来提供客户端负载(它们的初始较小的客户端已尽早使用,例如“在450k客户端上最大化了我们的4core / 15gb机顶盒”)。
这是本次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连接的人数。
这里有两种不同的讨论:一种是可以连接到您的服务器的人数。别人已经充分回答了这个问题,因此我不再赘述。
其他是您的服务器可以监听多少个端口?我相信这就是64K号码的来源。实际上,TCP协议对端口使用16位标识符,该标识符转换为65536(比64K多一点)。这意味着每个IP地址在服务器上可以有许多不同的“侦听器”。
我认为一个Web服务器可以处理的并发套接字连接的数量在很大程度上取决于每个连接消耗的资源数量以及该服务器上可用的总资源数量,除非有任何其他Web服务器资源限制配置。
为了说明这一点,如果每个套接字连接消耗1MB的服务器资源,并且服务器具有16GB的可用RAM(理论上),这意味着它将只能处理(16GB / 1MB)并发连接。我认为就这么简单...真的!
因此,无论Web服务器如何处理连接,每个连接最终都会消耗一些资源。