HTML WebSockets 是否为每个客户端维护一个开放的连接？这个规模吗？

如何解决HTML WebSockets 是否为每个客户端维护一个开放的连接？这个规模吗？

在大多数情况下，WebSocket 可能会比 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/长轮询的当前开销和延迟。

一旦 WebSockets 标准变得更加最终并获得更广泛的支持，将它用于大多数需要与服务器频繁通信的新交互式 Web 应用程序将是有意义的。对于现有的交互式 Web 应用程序，它实际上取决于当前 AJAX/长轮询模型的工作情况。转换的努力将是非常重要的，因此在许多情况下，成本将不值得收益。

：

有用的链接：AWS 上使用 Node.js 的 600k 并发 websocket 连接

解决方法

我很好奇是否有人有任何关于 HTML WebSockets
可扩展性的信息。对于我读过的所有内容，似乎每个客户端都将与服务器保持开放的通信线路。我只是想知道它是如何扩展的以及服务器可以处理多少个打开的
WebSocket 连接。也许让这些连接打开在现实中不是问题，但感觉就像是这样。