What are WebSockets? Everything you need to know about WebSockets! (2023)
Updated: Dec 9, 2022
If you are someone who wants to explore WebSockets and know about how they work, or if you are planning to use WebSockets in your project and want to learn about its implementation and code WebSockets, this blog is for you. If you want your website to update data instantaneously in realtime or you want to display server-triggered notifications/messages on your website, you need to use WebSockets.
Before diving straight into Websockets, I will give a bit of an explanation of how HTTP/HTTPS protocol works. This will help to understand why WebSockets are required and what problem it solves.
Let's dive right into WebSockets -
1. How does a HTTP/HTTPS protocol work?
The HTTP protocol is based on a request/response system, i.e. the client (user) computer always makes a request and the server sends the response. The point to be noted here is the client/user will always be the first to initiate the request. The server won't randomly send a response to the user. Most of the public transactions on the internet happen using this HTTP protocol.
For example, whenever I open a website, let's say I open - https://thegeekyminds.com. My computer will send a request to a backend server via the internet. This request is sent using the HTTPS protocol. Whenever this request is sent to the web server, a response will be sent back from the server to my computer. To send this request a TCP connection is first established between my computer and the server. When the response is received, this TCP connection is closed.
Every time I open a URL or my web app calls a REST API, a TCP connection is opened. Once the response is received, the TCP connection gets closed. A certain amount of time is consumed in creating this TCP Connection.
In short, if my web app calls 20 different API calls to a web server, 20 different TCP connections will be created. Each of them will be closed once the responses for them are received. This is how an HTTP/HTTPS connection works.
Imagine the amount of extra time consumed by creating each of these TCP connections! Opening 20 TCP connections is very time consuming and increases latency of the web application.
HTTP protocol can be defined as a uni-directional protocol that creates a connection using the HTTP request method. The connection is closed once the response is received.
In HTTP Protocol, the client/user tells the server - "Hey give me data", but there can be use cases when the server wants to send a message to the client/user without the client requesting it. This is not possible using the HTTP protocol.
For example in a chat application when someone wants to send you a message, the server should push the message to your computer. HTTP/HTTPS protocol won't work here! This is where WebSockets come into the picture.
2. What are Websockets?
Websockets can be defined as a communications protocol, providing bi-directional communication over a single opened TCP connection. The use WebSockets became wide spread since 2010. Before 2010, there was not really an elegant solution for realtime communications with the server. Let's look at it in detail.👇🏻
3. How do WebSockets work?
To understand WebSockets, let's take a simple setup, where we have a computer and a server. Now let's say the computer and server want to communicate so they open a TCP connection and start exchanging data. But they don't close this TCP connection. The TCP communication remains open. Now both of them send data to each other until one of them decides to close the connection. This is the basis of WebSockets.
Unlike HTTP/HTTPS which is unidirectional, WebSockets are actually bi-directional. This means that the server can send messages to the client (the client does not need to poll for messages) and the client can also send messages to the server.
Poll or Polling is a mechanism where client/user constantly sends request to the server after a fixed interval of time to see if the server has anything to respond. There are 2 types of Polling - Short polling and Long Polling. The main difference between these two is that in Long Polling, the TCP request in HTTP is opened for a relatively longer duration ~300 sec.
Basically in WebSockets, anyone can send a message to anyone! There's no need to initiate a request by anyone. Thus making it a good option for chat applications.
Suppose you have a chat opened on your browser and you are chatting with your friend. Your friend sends you a new message which is received on the server. The server can actually tell your computer - "Hey, you received a new message !". All this without the need for your chat window to actually poll for new messages. This is possible via WebSockets The TCP connection is closed when either the server or the client computer wants to close the connection.
Unlike https://, the webockets URL would start with ws:// or wss://
A WebSocket connection is established using WebSocket Handshake, let's look into it in more depth.
4. WebSockets Handshake
The first request that the client makes is a normal HTTP get request. There's an 'upgrade' header that indicates that the client needs to upgrade this request.
The server will reply with a status code 101 - Switching Protocols, which means the server is okay to switch the protocols.
The above completes the process of the handshake and then both can communicate with one another without any limitations until one of the parties decide to close the connection.
These are what my request and response headers look like. You can see the "Connection" Header which mentions "Upgrade". And the "Upgrade" header, which mentions "webscoket".
5. Where are Websockets used?
Real-time applications: When you want to update content on a website without having to refresh the UI. Alternatively, you can use HTTPS to poll for the updated content but web sockets are faster and efficient choice.
Online multiplayer gaming applications
Social media feed or notifications
Chat applications use WebSockets - The client should not ask the server every few seconds if there is a message. The server should automatically push the messages when new messages are received.
Showing client progress/logging
Web Sockets is a very nice technology but does not mean we have to absolutely use it.
6. When not to use WebSockets?
If you want to retrieve an older or historical data, you should go for HTTP.
Caches are better served by HTTP requests. Hence, if you want to use caches, WebSockets won't be a very good option. The WebSocket design does not allow to create caches.
If your system and fail safe mechanisms are heavily dependent on error codes, HTTP is the way to go. WebSockets do not throw error codes/ error messages after the connection has been established.
The websocket protocol does not guarantee that the message will be acknowledged. This is an important factor to keep in mind while planning to use WebSockets
For synchronised events HTTP has an edge over Websockets due to it's request/response system.
7. WebSockets - Pros and Cons
Pros
Bi-directional: Since WebSockets are bi-directional, it provides realtime updates and reduces the need for polling by the clients. The server can directly send information
Websockets are accepted by most firewalls since they start with a HTTP protocol and then upgrade to a WebSocket connection. Hence it is Firewall friendly.
Most of the browsers have support for WebSockets
The developer community has a lot of support and online resources for websockets.
Cons :
Before adding WebSockets, you would need to check if your reverse proxy/ load balancer supports WebSockets connection
Server-side configurations are also needed before implementing WebSockets. So it is not so straightforward to add WebSockets to an existing project.
Hard to horizontally scale, i.e. it is difficult to add scale by adding more clients to the WebSocket connection.
There's no mechanism in WebSockets to store history. If the connection is lost, the context is forever lost.
WebSockets do not support caching.
While the support for WebSOckets is wide-spread, there may be scenarios where HTTP is not supported by the client/user. Hence with WebSockets, it is advisable to have a fail-safe mechanism or backup of HTTP requests or polling.
8. Coding Websockets
Let's Code!
Here's a simple tutorial for WebSocket for you to try out.
In this example, we will spin up a server on our machine. And the client will be our browser where we can run javascript code.
Server-side coding
I will code the server using nodejs. But you can use other programming languages as well like - Python, Java, PHP, C#, C, C++, etc.
First things first, let's install the WebSocket dependency for nodejs. Simply, run the command below:
$ npm install websocketI will then import the requirements
const http = require('http');
const WebSocketServer = require("websocket").serverconst httpserver = http.createServer((req, res) => {
console.log("We have received a request")
});The above code will accept the HTTP request and send the response. Whenever the client/user calls our server, it will first come here. This is the call with the `upgrade` header I talked about a while back.
httpserver.listen(8080, () => console.log("My server is listening")).listen() will listen on port 8080 for incoming requests
const websocket = new WebSocketServer({
"httpServer":httpserver
});The WebSocket class needs the httpserver we created above to initialize the socket
let connection = null
//Receive the upgrade cocnnection request from the client
// I can accept websockets by specific name
websocket.on("request", request=> {
connection = request.accept(null, request.origin)
connection.on("open", ()=>console.log("Opened!!"))
connection.on("close", ()=>console.log("Closed!!"))
connection.on("message", (mesage)=>console.log(`Message received ${message.utf8Data}`))
})In the on("request")... function, you can decide whether to accept the upgrade to WebSocket or reject it based on maybe the connection name or the origin. (Whatever is your criteria)
`request.accept(...` - will send back the switching protocol as a response to the handshake.
`connection.on("open" ...` - the stuff you want to do when the WebSocket is open
`connection.on("close" ...` - the stuff you want to do when the WebSocket is closed
`connection.on("message" ...` - the stuff you want to do when a message is received. Currently, I have just printed the message
function sendMessageCronJob(){
connection.send(`Message ${Math.random()}`)
setTimeout(sendMessageCronJob, 10)
}`connection.send( <message>...` - this is used when the server wants to send any message to the client. Here I have created a function "sendMessageCronJob" which will send a random number to the client every 10 seconds.
Cron Job refers to a periodic task which is carried out again and again after a fixed time interval. Here my function will send a random number every 10 secinds.
The final nodejs code on the server side would look like this
You can check out the code in my GitHub Repository: https://github.com/gouravdhar/websockets
Client-Side Coding
I will code my client side in javascript on the browser itself. Most browsers have WebSockets pre-installed.
let ws = new WebSocket("ws://localhost:8080")Here ws:// stands for web socket protocol. wss:// is also used if you want it to be TLS encrypted. localhost:8080 is the server address on which my server is listening.
If we want to read a message from the server it's really simple,
ws.onmessage = message => console.log(`Message from server ${message.data}`)To send a message to the server use the following command
ws.send("Hi there")It's time to see these in action
I will start my server.
$ node server.js
So my server started listening
I will go to the browser and establish a connection. The way to do that would be to open Developer Tools on the browser and navigate to the console option. And then type the command for establishing a connection
Now I should listen to messages from the server. Since my server was configured to send messages every 5 seconds, I can see the received message on the console.
Now it's time to send a message to the server.
This was a very simple implementation of WebSockets. You can find both the server-side and client-side code here - https://github.com/gouravdhar/websockets
9. Websockets implementation examples on the internet
If I go to this website: https://multiuser-blocks.glitch.me/ PS: I found it randomly on the internet.
It uses WebSocket. You can check the request by opening the developer tools of your website and then navigating to the Networks tab. The request URL is: wss://multiuser-blocks.glitch.me/
It starts with wss:// indicating that it is creating the WebSocket and keeping it open for further communications.
There's a tab called "Messages" where you can actually see the messages being sent and received to update the UI
10. My thoughts and Conclusion
Both HTTP and WebSockets are built on top of the TCP Protocol. If you are facing the dilemma of which of these two should you use, you should list down your requirements and then have a look at the Pros and Cons section in this blog which I have listed above. If you want real-time updates on your website, and you are okay with the listed cons, you should use WebSockets. Alternatively, you can also have a look at the Section When not to use WebSockets.
And that's a wrap! Hi, I am Gourav Dhar, a software developer and I write blogs on Backend Development and System Design. Subscribe to my Newsletter and learn something new every week - https://thegeekyminds.com/subscribe
11. Frequently Asked Questions (FAQs)
Are WebSockets secure?
As per stack overflow: Version hixie-76 of the WebSocket protocol is more secure than earlier versions, and version hybi-07 is even more secure. At hixie-76 version is added protection against fake requests. At hybi-07 version is added message masking.
Are WebSockets TCP or UDP?
Can postman do WebSockets?
Does Facebook Messenger use WebSockets?
