我很好奇是否有人有关于HTML WebSockets可伸缩性的任何信息。对于我所阅读的一切，似乎每个客户都将与服务器保持开放的通信线路。我只是想知道如何扩展以及服务器可以处理多少个打开的WebSocket连接。也许将这些连接打开并不是现实中的问题，但感觉就像是。
答案 0 :(得分：197)
在大多数情况下，WebSockets可能比AJAX / HTML请求更好地扩展。但是，这并不意味着WebSockets可以替代AJAX / HTML的所有用途。
每个TCP连接本身在服务器资源方面消耗很少。通常建立连接可能很昂贵，但保持空闲连接几乎是免费的。通常遇到的第一个限制是可以同时打开的文件描述符（套接字使用文件描述符）的最大数量。这通常默认为1024，但可以很容易地配置得更高。
是否曾尝试过配置Web服务器以支持数万个同步的AJAX客户端？将这些客户端更改为WebSockets客户端，这可能是可行的。
HTTP连接，虽然它们不会长时间创建打开的文件或使用端口号，但是几乎所有其他方式都更昂贵：
每个HTTP连接都带有很多大部分时间都没有使用的行李：cookies，内容类型，内容长度，用户代理，服务器ID，日期，最后修改等等。一旦成为WebSockets建立连接，只需要来回发送应用程序所需的数据。
通常，HTTP服务器配置为记录占用磁盘和CPU时间的每个HTTP请求的开始和完成。记录WebSockets数据的开始和完成将成为标准，但是当WebSockets连接进行双工传输时，不会有任何额外的日志记录开销（除非应用程序/服务设计为这样做）。
通常，使用AJAX的交互式应用程序要么不断轮询或使用某种长轮询机制。 WebSockets是一种更清洁（和更低资源）的方式来执行更多事件模型，其中服务器和客户端在有关于现有连接的报告时相互通知。
生产中的大多数流行Web服务器都有一个用于处理HTTP请求的进程（或线程）池。随着压力增加，池的大小将增加，因为每个进程/线程一次处理一个HTTP请求。每个额外的进程/线程使用更多的内存并创建新的进程/线程比创建新的套接字连接（这些进程/线程仍然必须这样做）要贵得多。大多数流行的WebSockets服务器框架都采用了事件路径，这种路径可以扩展并且性能更好。
WebSockets的主要优点是交互式Web应用程序的低延迟连接。与HTTP AJAX / long-poll相比，它可以更好地扩展并消耗更少的服务器资源（假设应用程序/服务器设计正确），但IMO较低的延迟是WebSockets的主要优点，因为它将启用不可能的新类Web应用程序使用AJAX / long-poll的当前开销和延迟。
一旦WebSockets标准变得更加完善并获得更广泛的支持，将其用于需要经常与服务器通信的大多数新交互式Web应用程序是有意义的。对于现有的交互式Web应用程序，它实际上取决于当前AJAX / long-poll模型的工作情况。转换的努力将是非平凡的，因此在许多情况下，成本不值得获益。
<强>更新：
有用的链接：600k concurrent websocket connections on AWS using Node.js
答案 1 :(得分：35)
只是澄清一下：服务器可以支持的客户端连接数与此方案中的端口无关，因为服务器[通常]仅在一个端口上侦听WS / WSS连接。我认为其他评论者的意思是文件描述符。您可以将文件描述符的最大数量设置得相当高，但是您必须注意每个打开的TCP / IP套接字的套接字缓冲区大小。以下是一些其他信息：https://serverfault.com/questions/48717/practical-maximum-open-file-descriptors-ulimit-n-for-a-high-volume-system
至于通过WS与HTTP减少延迟，这是正确的，因为除了初始WS握手之外不再解析HTTP头。此外，随着越来越多的数据包被成功发送，TCP拥塞窗口变宽，有效地降低了RTT。
答案 2 :(得分：13)
任何现代单一服务器都可以服务thousands of clients at once。它的HTTP服务器软件就是面向事件驱动（IOCP）（我们不再是旧的Apache一个连接=一个线程/进程方程式）。甚至内置在Windows（http.sys）中的HTTP服务器也是面向IOCP的并且非常高效（在内核模式下运行）。从这个角度来看，在WebSockets和常规HTTP连接之间进行扩展会有很大的不同。一个TCP / IP连接使用一点资源（远远少于一个线程），现代操作系统针对处理大量并发连接进行了优化：WebSockets和HTTP只是OSI 7应用层协议，继承了这个TCP / IP规范。 / p>
但是，通过实验，我发现了WebSockets的两个主要问题：
所以我建议以下任何项目：
- 仅使用WebSockets进行客户端通知（使用回溯机制进行长轮询 - 周围有很多库）;
- 对所有其他数据使用RESTful / JSON，使用CDN或代理进行缓存。
实际上，完整的WebSockets应用程序无法很好地扩展。只需使用WebSockets来实现它们的目的：将通知从服务器推送到客户端。
关于使用WebSockets的潜在问题：
1。考虑使用CDN
今天（差不多4年后），网络扩展涉及使用Content Delivery Network（CDN）前端，不仅适用于静态内容（html，css，js），还适用于your (JSON) application data。
当然，您不会将所有数据都放在CDN缓存中，但实际上，很多常见内容都不会经常发生变化。我怀疑80％的REST资源可能被缓存...即使一分钟（或30秒）CDN到期超时可能足以为您的中央服务器提供新的实时，并增强应用程序响应性很多，因为CDN可以在地理上进行调整......
据我所知，CDN中还没有WebSockets支持，我怀疑它永远不会。 WebSockets是有状态的，而HTTP是无状态的，因此很容易被缓存。实际上，为了使WebSockets对CDN友好，您可能需要切换到无状态RESTful方法......这不再是WebSockets。
2。安全问题
WebSockets存在潜在的安全问题，特别是有关DOS攻击的问题。有关新安全漏洞的说明，请参阅this set of slides和this webkit ticket。
WebSockets避免在OSI 7应用程序层级别进行数据包检查的机会，这在任何业务安全性中都是非常标准的。事实上，WebSockets使传输变得模糊，因此可能是安全漏洞的主要漏洞。
答案 3 :(得分：8)
以这种方式思考：什么是更便宜，保持开放连接，或为每个请求打开一个新连接（这样做的协商开销，记住它是TCP。）
当然这取决于应用程序，但对于长期实时连接（例如AJAX聊天），保持连接打开要好得多。
最大连接数将受套接字的最大空闲端口数限制。
答案 4 :(得分：-3)
不，它没有扩展，为中间路由交换机提供了巨大的工作。然后在服务器端，页面错误（您必须保留所有这些描述符）达到高值，并且将资源带入工作区的时间增加。这些主要是JAVA编写的服务器，并且可以更快地抓住那些插座的gazilions然后销毁/创建一个。 当您在计算机上运行此类服务器时，任何其他进程都无法再移动。