我很好奇是否有人有关于HTML WebSockets的可伸缩性的任何信息 . 对于我读过的所有内容，似乎每个客户端都将与服务器保持开放的通信线路 . 我只是想知道服务器可以处理的扩展WebSocket连接的规模和扩展程度 . 也许将这些连接打开并不是现实中的问题，但感觉就像是这样 .
在大多数情况下，WebSockets可能比AJAX / HTML请求更好地扩展 . 但是，这并不意味着WebSockets可以替代AJAX / HTML的所有用途 .
每个TCP连接本身在服务器资源方面消耗很少 . 通常 Build 连接可能很昂贵，但保持空闲连接几乎是免费的 . 通常遇到的第一个限制是可以同时打开的文件描述符（套接字使用文件描述符）的最大数量 . 这通常默认为1024，但可以轻松配置更高 .
曾经尝试过配置Web服务器来支持数万个同步的AJAX客户端吗？将这些客户端更改为WebSockets客户端，这可能是可行的 .
HTTP连接，虽然它们不会长时间创建打开的文件或消耗端口号，但几乎所有其他方式都更昂贵：
每个HTTP连接都带有很多大部分时间都没有使用的 Baggage ：cookie，内容类型，内容长度，用户代理，服务器ID，日期，最后修改等 . 一旦 Build 了WebSockets连接，应用程序所需的数据需要来回发送 .
通常，HTTP服务器配置为记录占用磁盘和CPU时间的每个HTTP请求的开始和完成 . 记录WebSockets数据的开始和完成将成为标准，但是当WebSockets连接进行双工传输时，不会有任何额外的日志记录开销（除非应用程序/服务设计为这样做） .
通常，使用AJAX的交互式应用程序要么不断轮询或使用某种长轮询机制 . WebSockets是一种更清洁（和更低资源）的方式来执行更多事件模型，其中服务器和客户端在他们有通过现有连接报告的内容时相互通知 .
生产环境 中的大多数流行Web服务器都有一个用于处理HTTP请求的进程（或线程）池 . 随着压力的增加，池的大小将增加，因为每个进程/线程一次处理一个HTTP请求 . 每个额外的进程/线程使用更多的内存并且创建新的进程/线程比创建新的套接字连接（这些进程/线程仍然必须这样做）要贵得多 . 大多数流行的WebSockets服务器框架都采用事件路由，这种路由趋于扩展并且性能更好 .
WebSockets的主要优点是交互式Web应用程序的低延迟连接 . 与HTTP AJAX / long-poll相比，它可以更好地扩展并消耗更少的服务器资源（假设应用程序/服务器设计正确），但IMO较低的延迟是WebSockets的主要优点，因为它将启用不可能的新类Web应用程序与AJAX /长轮询的当前开销和延迟 .
一旦WebSockets标准变得更加完善并获得更广泛的支持，将它用于需要经常与服务器通信的大多数新的交互式Web应用程序是有意义的 . 对于现有的交互式Web应用程序，它实际上取决于当前AJAX / long-poll模型的工作情况 . 转换的努力将是非平凡的，因此在许多情况下，成本不值得获益 .
Update ：
有用的链接：600k concurrent websocket connections on AWS using Node.js
只是澄清一下：服务器可以支持的客户端连接数与此方案中的端口无关，因为服务器[通常]只在一个端口上侦听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 .
任何现代的单个服务器都能够服务器thousands of clients at once . 它的HTTP服务器软件就是面向事件驱动（IOCP）（我们不再是旧的Apache一个连接=一个线程/进程方程式） . 甚至Windows内置的HTTP服务器（http.sys）也是面向IOCP的并且非常高效（在内核模式下运行） . 从这个角度来看，WebSockets和WebSockets之间的缩放不会有太大差异常规HTTP连接 . 一个TCP / IP连接使用少量资源（远远少于一个线程），现代操作系统针对处理大量并发连接进行了优化：WebSockets和HTTP只是OSI 7应用层协议，继承自此TCP / IP规范 .
但是，从实验中，我看到了WebSockets的两个主要问题：
他们不支持CDN;
他们有潜在的安全问题 .
因此，对于任何项目，我都建议使用以下内容：仅使用WebSockets进行客户端通知（使用回退机制进行长轮询 - 周围有大量库）;对所有其他数据使用RESTful / JSON，使用CDN或代理进行缓存 .
实际上，完整的WebSockets应用程序不能很好地扩展 . 只需将WebSockets用于它们的设计目的：将通知从服务器推送到客户端 .
关于使用WebSockets的潜在问题：
1.考虑使用CDN
今天（差不多4年后），Web扩展涉及使用Content Delivery Network（CDN）前端，不仅用于静态内容（html，css，js），还包括your (JSON) application data .
当然，你经常赢得改变 . 我怀疑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使传输变得模糊，因此可能是安全漏洞的主要漏洞 .
可以这样考虑：什么是更便宜，保持开放连接，或为每个请求打开一个新连接（这样做的协商开销，记住它是TCP . ）
当然这取决于应用程序，但对于长期实时连接（例如AJAX聊天），保持连接打开要好得多 .
最大连接数将受套接字的最大空闲端口数限制 .
不，它没有扩展，为中间路由交换机提供了巨大的工作 . 然后在服务器端，页面错误（您必须保留所有这些描述符）达到高值，并且将资源带入工作区的时间增加 . 这些主要是JAVA编写的服务器，并且可以更快地 grab 那些插座的gazilions然后销毁/创建一个 . 当您在计算机上运行此类服务器时，任何其他进程都无法再移动 .
5 回答
在大多数情况下，WebSockets可能比AJAX / HTML请求更好地扩展 . 但是，这并不意味着WebSockets可以替代AJAX / HTML的所有用途 .
每个TCP连接本身在服务器资源方面消耗很少 . 通常 Build 连接可能很昂贵，但保持空闲连接几乎是免费的 . 通常遇到的第一个限制是可以同时打开的文件描述符（套接字使用文件描述符）的最大数量 . 这通常默认为1024，但可以轻松配置更高 .
曾经尝试过配置Web服务器来支持数万个同步的AJAX客户端吗？将这些客户端更改为WebSockets客户端，这可能是可行的 .
HTTP连接，虽然它们不会长时间创建打开的文件或消耗端口号，但几乎所有其他方式都更昂贵：
每个HTTP连接都带有很多大部分时间都没有使用的 Baggage ：cookie，内容类型，内容长度，用户代理，服务器ID，日期，最后修改等 . 一旦 Build 了WebSockets连接，应用程序所需的数据需要来回发送 .
通常，HTTP服务器配置为记录占用磁盘和CPU时间的每个HTTP请求的开始和完成 . 记录WebSockets数据的开始和完成将成为标准，但是当WebSockets连接进行双工传输时，不会有任何额外的日志记录开销（除非应用程序/服务设计为这样做） .
通常，使用AJAX的交互式应用程序要么不断轮询或使用某种长轮询机制 . WebSockets是一种更清洁（和更低资源）的方式来执行更多事件模型，其中服务器和客户端在他们有通过现有连接报告的内容时相互通知 .
生产环境 中的大多数流行Web服务器都有一个用于处理HTTP请求的进程（或线程）池 . 随着压力的增加，池的大小将增加，因为每个进程/线程一次处理一个HTTP请求 . 每个额外的进程/线程使用更多的内存并且创建新的进程/线程比创建新的套接字连接（这些进程/线程仍然必须这样做）要贵得多 . 大多数流行的WebSockets服务器框架都采用事件路由，这种路由趋于扩展并且性能更好 .
WebSockets的主要优点是交互式Web应用程序的低延迟连接 . 与HTTP AJAX / long-poll相比，它可以更好地扩展并消耗更少的服务器资源（假设应用程序/服务器设计正确），但IMO较低的延迟是WebSockets的主要优点，因为它将启用不可能的新类Web应用程序与AJAX /长轮询的当前开销和延迟 .
一旦WebSockets标准变得更加完善并获得更广泛的支持，将它用于需要经常与服务器通信的大多数新的交互式Web应用程序是有意义的 . 对于现有的交互式Web应用程序，它实际上取决于当前AJAX / long-poll模型的工作情况 . 转换的努力将是非平凡的，因此在许多情况下，成本不值得获益 .
Update ：
有用的链接：600k concurrent websocket connections on AWS using Node.js
只是澄清一下：服务器可以支持的客户端连接数与此方案中的端口无关，因为服务器[通常]只在一个端口上侦听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 .
任何现代的单个服务器都能够服务器thousands of clients at once . 它的HTTP服务器软件就是面向事件驱动（IOCP）（我们不再是旧的Apache一个连接=一个线程/进程方程式） . 甚至Windows内置的HTTP服务器（http.sys）也是面向IOCP的并且非常高效（在内核模式下运行） . 从这个角度来看，WebSockets和WebSockets之间的缩放不会有太大差异常规HTTP连接 . 一个TCP / IP连接使用少量资源（远远少于一个线程），现代操作系统针对处理大量并发连接进行了优化：WebSockets和HTTP只是OSI 7应用层协议，继承自此TCP / IP规范 .
但是，从实验中，我看到了WebSockets的两个主要问题：
他们不支持CDN;
他们有潜在的安全问题 .
实际上，完整的WebSockets应用程序不能很好地扩展 . 只需将WebSockets用于它们的设计目的：将通知从服务器推送到客户端 .
关于使用WebSockets的潜在问题：
1.考虑使用CDN
今天（差不多4年后），Web扩展涉及使用Content Delivery Network（CDN）前端，不仅用于静态内容（html，css，js），还包括your (JSON) application data .
当然，你经常赢得改变 . 我怀疑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使传输变得模糊，因此可能是安全漏洞的主要漏洞 .
可以这样考虑：什么是更便宜，保持开放连接，或为每个请求打开一个新连接（这样做的协商开销，记住它是TCP . ）
当然这取决于应用程序，但对于长期实时连接（例如AJAX聊天），保持连接打开要好得多 .
最大连接数将受套接字的最大空闲端口数限制 .
不，它没有扩展，为中间路由交换机提供了巨大的工作 . 然后在服务器端，页面错误（您必须保留所有这些描述符）达到高值，并且将资源带入工作区的时间增加 . 这些主要是JAVA编写的服务器，并且可以更快地 grab 那些插座的gazilions然后销毁/创建一个 . 当您在计算机上运行此类服务器时，任何其他进程都无法再移动 .