HTML WebSockets是否为每个客户保持开放连接？这是否规模？ [英] Do HTML WebSockets maintain an open connection for each client? Does this scale?

问题描述

我很好奇，如果有人有任何有关HTML WebSockets的可伸缩性的信息。对于我读过的所有内容，似乎每个客户端都将与服务器保持开放的通信线路。我只是想知道服务器可以处理的扩展WebSocket连接的规模和扩展程度。也许让这些连接保持开放并不是现实中的问题，但感觉就好了。

解决方案

在大多数情况下，WebSockets都会可能比AJAX / HTML请求的规模更好。但是，这并不意味着WebSockets可以替代AJAX / HTML的所有用途。

每个TCP连接本身在服务器资源方面消耗很少。通常建立连接可能很昂贵，但保持空闲连接几乎是免费的。通常遇到的第一个限制是可以同时打开的文件描述符（套接字使用文件描述符）的最大数量。这通常默认为1024，但可以很容易地配置更高。

曾尝试配置Web服务器以支持数以万计的同时AJAX客户端？将这些客户端更改为WebSockets客户端，这可能是可行的。

HTTP连接，虽然它们不会长时间创建打开的文件或消耗端口号，但更多几乎所有其他方式都很昂贵：

• 每个HTTP连接都带有很多大部分时间没有使用的行李：cookie，内容类型，内容长度，用户代理，服务器ID，日期，最后修改等。一旦建立了WebSockets连接，只需要来回发送应用程序所需的数据。

  通常，HTTP服务器被配置为记录占用磁盘和CPU时间的每个HTTP请求的开始和完成时间。
记录WebSockets数据的开始和完成将成为标准，但是当WebSockets连接进行双工传输时，不会有任何额外的日志记录开销（除非应用程序/服务设计为这样做）。
大多数生产流行的Web服务器都有一个用于处理HTTP请求的进程（或线程）池。随着压力的增加，池的大小会增加，因为每个进程/线程一次处理一个HTTP请求。每个额外的进程/线程使用更多的内存，并且创建新的进程/线程比创建新的套接字连接（这些进程/线程仍然必须这样做）要昂贵得多。大多数流行的WebSockets服务器框架都采用事件路由，这种路由可以扩展并且性能更好。

WebSockets的主要优点是交互式Web应用程序的低延迟连接。与HTTP AJAX / long-poll相比，它可以更好地扩展并消耗更少的服务器资源（假设应用程序/服务器设计正确），但IMO较低的延迟是WebSockets的主要优点，因为它将启用不可能的新类Web应用程序使用AJAX / long-poll的当前开销和延迟。

一旦WebSockets标准变得更加完善并得到更广泛的支持，将它用于大多数新的需要经常与服务器通信的交互式Web应用程序。对于现有的交互式Web应用程序，它将取决于当前的AJAX /长轮询模型的运行情况。转换的努力将是非平凡的，因此在许多情况下，成本不值得获益。

更新：

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

I am curious if anyone has any information about the scalability of HTML WebSockets. For everything I've read it appears that every client will maintain an open line of communication with the server. I'm just wondering how that scales and how many open WebSocket connections a server can handle. Maybe leaving those connections open isn't a problem in reality, but it feels like it is.

解决方案

In most ways WebSockets will probably scale better than AJAX/HTML requests. However, that doesn't mean WebSockets is a replacement for all uses of AJAX/HTML.

Each TCP connection in itself consumes very little in terms server resources. Often setting up the connection can be expensive but maintaining an idle connection it is almost free. The first limitation that is usually encountered is the maximum number of file descriptors (sockets consume file descriptors) that can be open simultaneously. This often defaults to 1024 but can easily be configured higher.

Ever tried configuring a web server to support tens of thousands of simultaneous AJAX clients? Change those clients into WebSockets clients and it just might be feasible.

HTTP connections, while they don't create open files or consume port numbers for a long period, are more expensive in just about every other way:

• Each HTTP connection carries a lot of baggage that isn't used most of the time: cookies, content type, conetent length, user-agent, server id, date, last-modified, etc. Once a WebSockets connection is established, only the data required by the application needs to be sent back and forth.

• Typically, HTTP servers are configured to log the start and completion of every HTTP request taking up disk and CPU time. It will become standard to log the start and completion of WebSockets data, but while the WebSockets connection doing duplex transfer there won't be any additional logging overhead (except by the application/service if it is designed to do so).

• Typically, interactive applications that use AJAX either continuously poll or use some sort of long-poll mechanism. WebSockets is a much cleaner (and lower resource) way of doing a more event'd model where the server and client notify each other when they have something to report over the existing connection.

• Most of the popular web servers in production have a pool of processes (or threads) for handling HTTP requests. As pressure increases the size of the pool will be increased because each process/thread handles one HTTP request at a time. Each additional process/thread uses more memory and creating new processes/threads is quite a bit more expensive than creating new socket connections (which those process/threads still have to do). Most of the popular WebSockets server frameworks are going the event'd route which tends to scale and perform better.

The primary benefit of WebSockets will be lower latency connections for interactive web applications. It will scale better and consume less server resources than HTTP AJAX/long-poll (assuming the application/server is designed properly), but IMO lower latency is the primary benefit of WebSockets because it will enable new classes of web applications that are not possible with the current overhead and latency of AJAX/long-poll.

Once the WebSockets standard becomes more finalized and has broader support, it will make sense to use it for most new interactive web applications that need to communicate frequently with the server. For existing interactive web applications it will really depend on how well the current AJAX/long-poll model is working. The effort to convert will be non-trivial so in many cases the cost just won't be worth the benefit.

Update:

Useful link: 600k concurrent websocket connections on AWS using Node.js

这篇关于HTML WebSockets是否为每个客户保持开放连接？这是否规模？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！