If you want to understand the difference between the WebSocket protocol vs HTTP, let’s take an example:
When we hit google.com on our browser, the request goes to a backend server in the form of HTTP or HTTPS. These are communication protocols that the browser uses to communicate with a web server. Whenever there is a request sent to the web server, there will be a response sent (by the webserver) as well. In other words, when a request is sent, there will be a TCP connection created between the client and the server. Once the response is received, the connection gets closed.
HTTP Protocol: What Is It and How Does It Work?
Let’s say a website sends 5 different requests to the server in order to retrieve 5 different information, it’s going to create 5 different connections separately. If we take any REST connection, it’s also the same thing when we’re hitting a REST endpoint from UI, from Postman, or from different servers, these connections will be closed when the responses are received.
If a Trading website sends hundreds of requests to the backend web server while it’s doing some trade processing, it’s going to retrieve those 100 pieces of information with 100 sets of new connections. Every time a request is made, a new connection is created. In other words, a new connection is established every single time.
Websocket: What Is It and How Does It Work?
Whenever a WebSocket is involved, there will be a client and server, similar to how we have in a day-to-day scenario. This client may be the browser of maybe a different server in itself. Whenever you see ws://, you know that the website is using WebSocket.
What Is the Difference Between Websocket Protocol vs HTTP?
One of the major differences between the HTTP connection and the Websocket is that: HTTP is unidirectional (the sender has to create a request in order to get a response) and Websockets are bi-directional (the receiver could also send data). In other words, bidirectional communication means data could flow in both ways – from the client to the server and also from the server to the client. But how are they achieving it?
They don’t close the connection which they opened for the first time. Whenever a client has established a connection with the server, this connection stays there until the client or the server decides to terminate the connection. And because these WebSockets are always open, it allows real-time data flow in the application.
For example
Let’s consider a client and a server. Whenever we initiate a connection between them, a handshake is made. The client and the server decide to create a connection that is going to be there forever. Once it’s open, the communication happens in terms of bidirectional message processing. The connection will exist until the client or the server dies. If one of the sides decides to close the connection, the connection gets terminated permanently from both ends. This is how WebSocket works, unlike HTTP where a connection is closed once the response is received.
Where and When Can Websockets Be Used?
Imagine we have a chat application that is hosted on this black server here. All the clients are different people around the world. They all go to our black server through their web browsers (might be Chrome, Edge, Safari..) to request our chat application. If one person sends a message to our chat app, this message will be simultaneously updated in all other client’s browsers around the world viewing that chat as well. This is how chat works and also Websockets in action.
Recommended reading: The Role of Sociological Imagination in Web Development
1. But what is really going on?
When we first request our chat app in the browser, we’re opening a WebSocket between the client and server. That also means other clients have their own WebSocket opened while connecting to our server as well. Because these are always open, data can flow back and forth between them in real-time. So when a person writes and clicks Send, our server receives it and distributes it to all other people in the Chat room (all each individual web socket). All of them will be notified that a new message has arrived. This data transfer occurs in real-time and will not use any kind of Ajax request from each of these different clients to get any new data from the server. In other words, the client doesn’t have to make any additional requests at all.
2. The different uses for Websockets
There are tons of different uses for Websockets, not just chat rooms. They include:
- Multiplayer browser games. The game UI is automatically refreshed without us having to reestablish a new connection
- Collaborative code editing (you might see it in Google Docs)
- Chat application
- Live text for sports/news websites
- Online drawing canvas
- Real-time running apps with multiple users
When Using HTTP and Not Using Websockets?
1. When not using WebSockets
WebSockets should not be used whenever we don’t want to only have the new data. Let’s say we want to retrieve old information as well, we should go for HTTP because we could use some Restful services by hitting the REST endpoint and easily getting the data. WebSockets can be perfectly used when we want real-time updates. If we don’t want real-time updates, then it’s better not to go for WebSockets because it just creates a socket and keeps it alive.
2. When using HTTP
Use HTTP if we are not worried about getting the data every now and then or if we just want to load the data only once. HTTP established the connection once we sent the request and it closes the connection once the response is retrieved. WebSockets keep the connection alive until we kill it.
Designveloper hopes you can understand the key of Websocket Protocol vs HTTP in this article!
Also published on
Share post on
Read more topics
