Web applications are becoming more and more interactive. They do not resemble static web pages anymore. That is why they require functionality like instant messaging, user status updates, real time data view, peer to peer interaction, etc. Until recently, the most common way of such communication was polling via HTTP – the most simple but not very effective way, and here is why.

1.  Server cannot message a user directly, it can only process and respond to client’s request. In order to receive updates the clients are sending requests all the time. And in most cases the server responds “nothing new”. The server is loaded with those numerous iterations without any useful information being actually transferred.
2. HTTP allows client requests and server responses go only in successive manner, one after another.
3. HTTP requests and responses include headers that may very long, if cookie values are passed. They are transferred with each request and response and do not carry any useful data.

As the result the communication is not instant, and we have sufficient server load which grows dramatically for large amounts of users and my collapse the application. There were attempts to solve these problems, but these were rather patches and hacks then truly elegant solutions.

Long Polling was aimed at reducing the number of request-response iterations. Unlike traditional polling, user request has a timeout, staying open for certain time. The server responds to this request only if an event happens. If nothing happens during the given period, the server responds closing the request. Then a new request can be issued. From the client side, events happen almost in real time, but slight delay may happen between requests. For the server, this reduces the number of request-response iterations, but the problem with redundant headers remains. Also, long polling requires sufficient memory to keep a number of idle connections – one for each user.

Server-Sent Events protocol works in a similar way to long polling, but the connection stays open even after an event is sent to user. This reduces server load, but the connection is one way, which is fine for displaying changing values, but is not sufficient for messaging.

WebSocket technology was introduced in 2011 and became a breakthrough. Unlike the other solutions it provided bidirectional, full-duplex communication between server and client over a single TCP connection. WebSocket does not require the request-response routine, allowing both client and server message each other instantly after the initial handshake. Each message is framed with just 2 bytes instead of bulky HTTP headers. Client and server can talk independently, each able to send and receive information at the same time.

As you can see, with WebSocket you have no redundant requests and responses and no extra load, only necessary bytes are sent. This reduces delays and server load vastly, allowing web applications to perform modern tasks in the most effective way.

The WebSocket protocol is currently supported by most major browsers, including Google Chrome, Microsoft Edge, Internet Explorer, Firefox, Safari and Opera. So there are no compatibility issues. And this makes it the best universal solution to date.