What is WebSocket, anyway?
WebSocket is a communications protocol that is part of the HTML5 specification. The API is currently being standardized by the W3C. The protocol is supported by most recent browsers. It offers the possibility of a persistent full-duplex channel between the server and the client. This innovation paves the way for a revolution in the design of dynamic, real-time sites.
In the days before WebSocket
To refresh its data, a highly dynamic website had no choice but to regularly check the server that contains the data. The refresh frequency determines how responsive the site is.
The front page of the website of the French newspaper, Le Monde, for example, checks one of its servers every 15 seconds in order to display any alerts under way.
This works for certain kinds of information but, say, for a football game, there would be a time lapse. For example, an average lapse of 15 seconds between when the goal was scored and when the information appears on the website. That’s enough for the viewer to lose the impression of watching in real time. If a sports website wants to be able to report changes in scores down to the second, each of its clients must check its servers once every second.
The traffic generated is not a problem for a desktop. It’s more problematic for a smartphone. As for the server, it has to handle all of the traffic generated by an HTTP request from the client every second, and for the entire duration of the game. Note that each request is a complete HTTP request, with its connection to the network, its HTTP headers, and so forth.
WebSocket changes the situation significantly. Establishing a connection is similar to getting an HTTP/s handshake, but the ensuing traffic is very much like in a plain TCP connection.
This eliminates the surplus that HTTP/s imposes on every single message.
The two-way nature of WebSocket lets the server send information to its clients when it wants. Not only does this improve the efficiency of each transmission, but the clients also don’t need to query the server periodically.
The responsiveness of the whole no longer depends on the refresh frequency, but instead on network time and server response time. So what used to take seconds now takes milliseconds. Taking full advantage of this gain could mean a change in the processing of real-time data. The architectures articulated around events will be the way to go (data bus in a publish/subscribe communication model, Node.js microservices).
There are other benefits to using WebSocket. For example, knowing the connection status of each client at any given moment, where a conventional HTTP server has only the date of the latest request. This information can be exploited for finer analytics because the exact connection time can be established rather than estimated.
The WebSocket API thus allows for true real-time exploitation of data, as long as you plan a stream processing part in its server architecture. Still, it is not a miracle solution for all performance problems, since it can’t take advantage of caches like other HTTP/s traffic.