What is WebSocket?
Websocket is that protocol which offers interactive bi-directional communication session between the server and the client over a single TCP connection.
This means server can actively send messages to the client at any time, and also the client can send messages to the server without doing full HTTP requests each time.
This is made possible by providing a normalized way for the server to send content to the browser without being requested by the client, and allowing information to be pushed back and forth while keeping the connection open.
Why to use WebSocket?
A Websocket is a continuous connection between server and client. It is often called server-push and is very valuable for applications where the client needs to know fairly and quickly when something happens on the server (like a prompt message on UI has been received to a client who is using your app when your application deployed/updated to a new version).
Without a websocket, the client would have to regularly poll by making an http request every few seconds in order to get timely new data. Where as with a websocket, no more polling.
Also information can be sent either way very efficiently, because the connection is already established and a websocket data is very efficiently organized.
When to use WebSocket?
As Websocket provides full-duplex communication, this can be used:
- When your application involve multiple user communicating with each other.
- When your application is a window to server-side data that’s constantly changing.
Few scenarios where Websocket can be used:
Ongoing Updates: When a client wants ongoing updates, using websocket is good. As these is a good fit when the client cannot predict when a change will occur and changes are like to happen. Example: Using a websocket on social applications, can update your feed in real-time or also getting a notification on your post as soon as your friend reacts to that.
Also if you are including sports information in your web application, websockets can keep your users up to speed.
Quick Reaction: When a client needs to react quickly to a change or an update, using Websocket is the best. A good example for this is a chat application that allows multiple users to chat in real time.
Impromptu messaging: Websocket design provides bi-directional messaging. Messages may be sent from either end of the connection at any time, and there is no native support for one message to indicate that it is related to another message. Websocket design is well suited for `fire and forget` messaging scenarios.
How it works?
To establish a Websocket connection, the client sends a Websocket handshake request, for which the server returns a Websocket handshake response.The handshake resembles HTTP in allowing servers to handle HTTP connections as well as WebSocket connections on the same port.
Once the connection is established, communication switches to a bi-directional binary protocol which doesn’t conform to the HTTP protocol. Now, the client and server can send WebSocket data or text frames back and forth in full-duplex mode. The data is minimally framed, with a small header followed by payload.
When not to use WebSocket?
When we know when to use websocket, it is also important that to know when not to use it.
Following are scenarios where Websockets are not preferred:
Edge Caching: When your application benefits from caching, that is when the representation of your app changes rarely. Websocket design does not allow explicit proxies to cache messages as it prevents caching proxy from re-sending a previous websocket conversation. A usage of websocket can degrade client performance in this scenario.
Safety: Websocket does not provide any authentication, privacy or integrity, the protocol leaves these issues to the messaging layer design.
Transactional messaging: Websockets are poorly suited for transactional requirements or download and upload techniques as it does not support `Request-Response` messaging pattern. The messaging layer must address your transactional needs if that’s needed in your application.