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?
As Websocket provides full-duplex communication, this can be used:
- When your application involve multiple users 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 there 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 of 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 a payload.
When not to use WebSocket?
When we know when to use WebSocket, it is also important 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.
Top comments (0)