Web服务器可以处理多少个套接字连接？ [英] How many socket connections can a web server handle?

问题描述

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

Say if I was to get shared, virtual or dedicated hosting, I read somewhere a server/machine can only handle 64,000 TCP connections at one time, is this true? How many could any type of hosting handle regardless of bandwidth? I'm assuming HTTP works over TCP.

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

Would this mean only 64,000 users could connect to the website, and if I wanted to serve more I'd have to move to a web farm?

推荐答案

简而言之：
你应该能够以数百万的顺序实现同时有效的TCP连接和扩展HTTP请求。

In short: You should be able to achieve in the order of millions of simultaneous active TCP connections and by extension HTTP request(s).

今天，我担心带ASP.NET的IIS是否会支持100个并发连接。当我看到这个问题/答案时，我无法抗拒回答自己，这里的问题很多答案都是完全错误的。

Today, I was worried whether IIS with ASP.NET would support in the order of 100 concurrent connections. When I saw this question/answers, I couldn't resist answering myself, many answers to the question here are completely incorrect.

最佳案例

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

The answer to this question must only concern itself with the simplest server configuration to decouple from the countless variables and configurations possible downstream.

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

So consider the following scenario for my answer:

1. TCP会话没有流量，保持活动数据包除外（


2. 软件旨在使用异步套接字和编程，而不是来自池的每个请求的硬件线程。否则，您显然需要相应数量的网络带宽和其他计算机资源。） （即IIS，Node.js，Nginx ...... webserver [但不是Apache]，使用异步设计的应用软件）


3. 性能良好/美元CPU / Ram。今天，任意地，让我们说i7（4核）带8GB内存。


4. 一个好的防火墙/路由器来匹配。


5. 没有虚拟限制/州长 - 即。 Linux somaxconn，IIS web.config ...


6. 不依赖于其他较慢的硬件 - 无法读取硬盘，因为它将是最低的公分母和瓶颈，而不是网络IO。

1. No traffic on the TCP sessions, except for keep-alive packets (otherwise you would obviously need a corresponding amount of network bandwidth and other computer resources)
2. Software designed to use asynchronous sockets and programming, rather than a hardware thread per request from a pool. (ie. IIS, Node.js, Nginx... webserver [but not Apache] with async designed application software)
3. Good performance/dollar CPU / Ram. Today, arbitrarily, let's say i7 (4 core) with 8GB of RAM.
4. A good firewall/router to match.
5. No virtual limit/governor - ie. Linux somaxconn, IIS web.config...
6. No dependency on other slower hardware - no reading from harddisk, because it would be the lowest common denominator and bottleneck, not network IO.

详细答案

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

Synchronous thread-bound designs tend to be the worst performing relative to Asynchronous IO implementations.

WhatsApp在一台Unix风格的操作系统机器上获得了100万的流量 - https://blog.whatsapp.com/index.php/2012/01/1-million-is-so-2011/ 。

WhatsApp get a million WITH traffic on a single Unix flavoured OS machine - 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更有效。

And finally, this one, http://highscalability.com/blog/2013/5/13/the-secret-to-10-million-concurrent-connections-the-kernel-i.html, goes into a lot of detail, exploring how even 10 million could be achieved. Servers often have hardware TCP offload engines, ASICs designed for this specific role more efficiently than a general purpose CPU.

良好的软件设计选择

异步IO设计在操作系统和编程平台上会有所不同。 Node.js的设计考虑了异步。你应该至少使用Promises，当ECMAScript 7出现时， async / 等待。 C＃/ .Net已经拥有像node.js这样的完全异步支持。无论操作系统和平台如何，异步都应该表现得非常好。无论你选择什么语言，寻找关键词异步，大多数现代语言都会有一些支持，即使它是某种附加组件。

Asynchronous IO design will differ across Operating Systems and Programming platforms. Node.js was designed with asynchronous in mind. You should use Promises at least, and when ECMAScript 7 comes along, async/await. C#/.Net already has full asynchronous support like node.js. Whatever the OS and platform, asynchronous should be expected to perform very well. And whatever language you choose, look for the keyword "asynchronous", most modern languages will have some support, even if it's an add-on of some sort.

到WebFarm？

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

Whatever the limit is for your particular situation, yes a web-farm is one good solution to scaling. There are many architectures for achieving this. One is using a load balancer (hosting providers can offer these, but even these have a limit, along with bandwidth ceiling), but I don't favour this option. For Single Page Applications with long-running connections, I prefer to instead have an open list of servers which the client application will choose from randomly at startup and reuse over the lifetime of the application. This removes the single point of failure (load balancer) and enables scaling through multiple data centres and therefore much more bandwidth.

打破神话 - 64K端口

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

To address the question component regarding "64,000", this is a misconception. A server can connect to many more than 65535 clients. See https://networkengineering.stackexchange.com/questions/48283/is-a-tcp-server-limited-to-65535-clients/48284

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

By the way, Http.sys on Windows permits multiple applications to share the same server port under the HTTP URL schema. They each register a separate domain binding, but there is ultimately a single server application proxying the requests to the correct applications.

这篇关于Web服务器可以处理多少个套接字连接？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！