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.
Html – Do HTML WebSockets maintain an open connection for each client? Does this scale
htmlwebsocket
Related Solutions
I think most of your questions can be clarified by understanding the real purpose of WebSockets. WebSockets was not primarily designed to replace any of the the things that are already in place and working well. For example, it was not designed to be a low-overhead version of AJAX. The purpose is to provide a bidirectional, low latency, full duplex, communication channel between the browser and server. It's real purpose is to enable a new domain of web applications or to improve current ones that are abusing HTTP to achieve bidirectional communication.
With that in mind let me comment on your bullet points:
The purpose of periodic WebSockets ping/pong messages is two-fold: to keep the channel from being closed by TCP timeout and to more quickly detect when the channel is closed (this is historically a weakness of TCP). The purpose of HTTP/AJAX polling is to get around the fact that HTTP is not bidirectional (i.e. the client polls to give the server the opportunity to send data back). WebSocket ping/pong frames are generally 2 bytes long. HTTP/AJAX polling requires full headers, cookies, etc which can easily total over a kilobyte for each request/response. Even if you send a ping/pong 10 times a second over WebSockets you are still unlikely to even compare to the overhead of HTTP/AJAX polling every 2 seconds. However, note that applications do not have the ability to send ping/pong messages. This is between the browser and server.
If you lose the Internet connection, you will receive an onclose event. If your browser is not doing ping/pong messages for you then you may not receive an onclose until you try to send a message after the network connection goes down.
I wouldn't replace a working RESTful service with WebSockets. You would be doing a lot of mapping work for probably very little benefit (again, WebSockets is not designed to replace what's already working well). I can envision situations where you might have a combination of both: REST for state transfer, WebSockets for event notification. E.g. the server sends a WebSocket message indicating "something changed" which triggers the client to do a REST request to find out the change.
Update:
Clarification: you could do REST over WebSockets but it's a mismatch in philosophy. REST is an architecture style that is un-opinionated about the underlying transport system. It is a constrained architecture: "client-server", "stateless", "cacheable", "layered system", "code on demand", and "uniform interface". WebSockets is constrained by none of those; it is a generic message transport system. You could constrain WebSockets to be RESTful but don't do that until you understand both REST and WebSockets intimately and can identify when it's right to do so.
The WebSocket Application Messaging Protocol (WAMP) https://wamp-proto.org/ provides RPC (Remote Procedure Call) and PubSub (Publish & Subscribe) messaging patterns on top of raw WebSocket for that purpose.
WAMP is a proper WebSocket subprotocol, uses WebSocket as transport and JSON as a payload format. RPC is implemented using 3 messages, and those messages contain a "Call ID" to correlate asynchronous RPC server responses to client initiated procedure calls.
Disclaimer: I am author of WAMP and some (open-source) WAMP implementations. Its an open initiative, with others already started to get on the boat. Ultimately, there should be a WAMP RFC properly defining the protocol .. but its still in the early stages.
Best Answer
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