假如我要获得共享，虚拟或专用托管，我在某处读取服务器/机器一次只能处理64,000个TCP连接，这是真的吗？无论带宽如何，任何类型的托管处理有多少？我假设HTTP通过TCP工作。
这意味着只有64,000个用户可以连接到该网站，如果我想提供更多服务，我必须转移到网络农场吗？
简而言之：您应该能够以数百万个同时活动的TCP连接和扩展HTTP请求的顺序实现。这可以告诉您使用正确配置的正确平台可以获得的最高性能。
今天，我担心带ASP.NET的IIS是否支持100个并发连接的顺序（看看我的更新，期望在旧的ASP.Net Mono版本上每秒约10k响应）。当我看到这个问题/答案时，我无法抗拒回答自己，这里的问题很多答案都是完全错误的。
最佳案例
这个问题的答案必须只关注最简单的服务器配置，以便与下游可能的无数变量和配置分离。
因此，请考虑以下场景作为我的答案：
详细解答
相对于异步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的最新比较
这个问题相当困难。虽然某些操作系统比其他操作系统更受限制，但是对于机器可以具有的活动连接数没有真正的软件限制。问题变成了资源之一。例如，假设一台机器想要支持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服务器如何处理连接，每个连接最终都会消耗一些资源。