WebSockets - friend or foe? How to achieve real-time experience in your web application

What are WebSockets and why we use them?

WebSockets enable the server and the client to send messages to each other at any time. The connection is established only once at the beginning, and after that, there is an open channel for sending and receiving data. This is an entirely different pattern than a standard HTTP connection where to get data, the client has to request it, and then a connection is broken soon.

WebSockets use HTTP protocol only to initiate communication channel, then every frame is sent by their own protocol via TCP connection in the transport layer of the OSI model.

Many of us heard a lot about WebSockets and almost always, when we consider any real-time behavior in our application, we tend to choose them. Why? Are they the only one, or are they the best choice when real-time is required? Maybe it is just that the developers out there are not aware of possible alternatives or blindly follow the examples of others from the plethora of available ones on the web. Let’s have a closer look at WebSockets to see some of their drawbacks and think about possible substitutes.

1. For me, the most significant disadvantage of using web sockets is that it keeps the connection open on the server for the whole duration of the time the user is interacting with the page. It can consume large amount of server resources.
2. Such a significant number of possible connections sometimes is considered as an advantage, but when we dive into it, we can see there exist other limitations like a database which can be killed by a high number of concurrent connections.
3. Web sockets also have no reconnect mechanisms. We have to implement our own comprehensive mechanism or use one provided by WebSocket third-party libraries.
4. From the end of 2011, we have an official standard for WebSockets RFC 6455, and there would be nothing weird about it, but for many years WebSockets were not standardized. They had unstable spec during their journey, and for that reason, many separate libraries with multiple implementations have been created.
5. Working with load balancers or proxies and WebSockets is a bit complicated. Additional effort is required during configuration. In the past, there were several issues related to transport over the unsecured connection. Frames were often lost. On the other hand, scaling the application with wrongly configured load balancer can cause connection flood. This can be a case even while restarting the server.
6. It is worth to mention that WebSockets give us only an illusion of reliability. Unfortunately, the Internet connection itself is not reliable. There are many places when the connection is slow, devices often go offline, and in fact, there is still a need to be backed by a reliable messaging system.

The above being said, I do not mean that WebSockets are bad. It is one of the best ways of real-time communication, and it can be used with success to resolve some specific problems (chat, video streaming, etc.), but I have always said that we should seek out the most straightforward solutions.

Alternatives for specific cases

WebSockets provide us communication in full-duplex mode, that means the client can send and receive messages on the same channel. This is an advantage of course, and it improves performance and user experience a lot, but in case of standard real-time applications, we do not need full-duplex communication. Majority of web applications out there are predominantly read applications. Lots of users benefit from live updates, but very few change information. It is incredibly rare to be in a situation where the HTTP header parsing optimization is warranted, and this work is done after sub-millisecond.

When it comes to data delivery from the server to the client, we are limited to two general approaches: client pull or server push. As a simple example with any web application, the client is the web browser. When the website in your browser is asking the server for data, this is called client pull. The reverse, when the server is proactively pushing updates to your website, it is called server push.

Let’s dive into some of the alternatives:

• Long polling (client pull)
• Short polling (client pull)
• Server-Sent Events (server push)
• Real-time database from Firebase (with WebSockets under the hood)

Short and Long Polling

Both are HTTP requests. When short polling is used, requests are processed as they come on the server. It creates much traffic (uses resources, but frees them as soon as a response is sent back). In comparison to short polling, long polling sends requests to server and client is waiting for the response to come until timeout. So the traffic is smaller, but resources are blocked for some time.

When should we use them? Short polling is rather dead. We should not use it at all, but long polling is used for some scenarios. Long polling’s most significant advantage is the fact that it works in every environment and every browser. It’s harder to starve the server of TCP connections since they are periodically released, but we have to face with re-authentication and re-authorization mechanisms.

Server-Sent Events (HTTP streaming)

HTTP provides a mechanism to push data from the server to clients via Server-Sent Events. In comparison to WebSockets, it is also a great way to achieve real-time experience. SSE is a mechanism that allows the server to asynchronously push the data to the client once the client-server connection is established. The server can then decide to send data whenever a new portion of data is available. It can be considered as a one-way publish-subscribe model.

SSE is an excellent alternative to WebSockets. They are limited to the browser’s connection pool limit of ~6 concurrent HTTP connections per server, but they provide a standard way of pushing data from the server to the clients over HTTP, which load balancers and proxies understand out-of-the-box. It is supported by most web browsers, except IE and Edge, but it is still available there through a polyfill.

Firebase

Firebase started as a Backend-as-a-Service (BaaS) and grew into a next-generation development platform. Firebase contains multiple features, but one of them is a real-time database. When you’re connecting your app with Firebase, you’re not connecting through standard HTTP. You’re indeed connecting through WebSockets under the hood. You do not have to configure all that real-time stuff on your own.

If you start a new project, it is worth to consider using it, but it is also worth to check all of the pros and cons. It is more than perfect for small apps, but it also has some limitations, for example - lack of OR operation on a query.

Let’s dive into the HTTP/2 world

The new HTTP/2 protocol comes with great features in the context of a better experience with communication. It can be used with SSE and with WebSockets as well. The possible way of communication was defined in RFC 8441. HTTP/2 provides us some features and worth to emphasize two of them:

• Multiplexing - a single TCP connection can be used to make multiple HTTP/2 requests and receive multiple responses (to a single origin). It is a great feature and removes the limitation of SSE, which was 6 connections to the origin. Multiplexing also works between different tabs. Thanks to that, we can have 50 tabs and only one multiplexed connection to the origin, but we have to be careful since the browsers, and also web servers can limit the number of concurrent streams by setting SETTINGS_MAX_CONCURRENT_STREAMS.

• HTTP/2 Server Push - sending server responses to the client without receiving requests, i.e., initiated by the server. The server can push additional resources to the client, without the client having to request each one explicitly. It can increase the performance of our app, but when the connection is slow, excess of unnecessary data can degrade our app. It is worth to remember that the browser can turn off push notifications by setting SETTINGS_ENABLE_PUSH.

HTTP/2 is not an alternative, but it has given us a lot of great improvements since it was introduced. Let’s try it using any type of real-time mechanisms.

Conclusion

Once again, all the drawbacks of WebSockets do not have to be drawbacks when you use them with caution and careful implementation. When we create a real-time application, we need to find the simplest and best approach. WebSockets can cause some severe problems when they are misused. Think twice if full-duplex communication is really required. Remember that you can approach most of the use cases by using real-time updates of SSE or even Long Polling. If the only thing you need is to update your website, use SSE (preferably together with HTTP/2). If you honestly need full-duplex communication for chat app or video streaming, use WebSockets, as they can be the best choice for you.