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). This tells you the maximum performance you can expect with the right platform with the right configuration.
今天，我担心带有 ASP.NET 的 IIS 是否会支持 100 个并发连接(看看我的更新，在较旧的 ASP.Net Mono 版本上预计每秒大约有 10k 响应).看到这个问题/答案，我忍不住回答自己，这里问题的很多答案都是完全错误的.
Today, I was worried whether IIS with ASP.NET would support in the order of 100 concurrent connections (look at my update, expect ~10k responses per second on older ASP.Net Mono versions). 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:
- TCP 会话上没有流量，除了保持活动的数据包(否则您显然需要相应数量的网络带宽和其他计算机资源)
- 软件旨在使用异步套接字和编程，而不是针对池中的每个请求使用硬件线程.(即 IIS、Node.js、Nginx... 带有异步设计的应用软件的网络服务器 [但不是 Apache])
- 良好的性能/美元的 CPU/内存.今天，随便说一下 i7(4 核)和 8GB 内存.
- 一个很好的防火墙/路由器匹配.
- 没有虚拟限制/州长 - 即.Linux somaxconn、IIS web.config...
- 不依赖其他较慢的硬件 - 不从硬盘读取数据，因为这将是最低公分母和瓶颈，而不是网络 IO.
详细解答
与异步 IO 实现相比，同步线程绑定设计的性能往往最差.
Synchronous thread-bound designs tend to be the worst performing relative to Asynchronous IO implementations.
WhatsApp 可以在一台 Unix 风格的操作系统机器上处理一百万的 WITH 流量 - https://blog.whatsapp.com/index.php/2012/01/1-million-is-so-2011/.
WhatsApp can handle 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/await.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.
到网络农场?
无论您的特定情况有什么限制，是的，网络农场是一种很好的扩展解决方案.有许多架构可以实现这一点.一种是使用负载平衡器(托管提供商可以提供这些，但即使这些也有限制，以及带宽上限)，但我不赞成这个选项.对于具有长时间运行连接的单页应用程序，我更喜欢有一个开放的服务器列表，客户端应用程序将在启动时随机选择并在应用程序的整个生命周期内重复使用.这消除了单点故障(负载平衡器)并支持通过多个数据中心进行扩展，从而获得更多带宽.
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.
更新 2019-05-30
这是最快的 HTTP 库的最新比较 - https://www.techempower.com/benchmarks/#section=data-r16&hw=ph&test=plaintext
Here is an up to date comparison of the fastest HTTP libraries - 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 的并发连接感兴趣.
这篇关于Web 服务器可以处理多少个套接字连接?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
