draft: falsein this .mdx file once ready to be published.
In networking world, the Internet Protocol Suite holds three layers: Application Layer, Internet Layer, and Transport Layer. The Transport Layer transfers the data packets using TCP or Transmission Control Protocol. The Internet Layer uses IPv4 and IPv6, which define the addresses of the sender as well as the receiver. The topmost layer is the Application Layer which uses HTTP, Websockets, IMAP, POP. This layer is being used by the end-user and where the application is built.
The HTTP method is completely dependent on the request and response model. Where the client makes the request and the server process the request and responds to the request. It could be an anything HTML page, REST API, or anything. In a more general way, the browser is the one who makes the request and it’s the server like Django which processes the request.
We have another method that is Websockets, which is a bidirectional communication method where the connection is always open. Let’s dive more into WebSockets.
WebSocket is a bidirectional, duplex protocol for communication between the client and the server. It was standardized in 2011 and is fully compatible with HTTP. This enables real-time applications such as chatting, notification, live feed, multi-player gaming, and other use cases as well.
Ideally, we wanted a model where the client sends the initial request, the server with the initial package and then the server happens to have new data it can send you that data. In the case of a chat application, if I am sending the message to a group of my friends, the server will get that application and then send it to all of the recipients. If they respond to the message then the server forwards the response to you. Hence, WebSocket solves the problem of HTTP where you have to connect to the server again in order to get the new message, this is why it is called bidirectional. Therefore the client and server can continue to communicate in real-time without making the request again and again.
WebSocket is an HTTP upgrade. It means that if you want to use WebSocket, you send a header to the webserver saying
upgrade and using the same TCP connection you used to make the first connection.
Let’s go back to 1995 when HTTP 1.0 was introduced. It used TCP methods to communicate and was dependent on request-response models. So the client always makes a request and the server responds only to that request. There was no other way around. The server doesn’t just send the new information on its own to the client, always the client has to send a request. It worked great and is still working perfectly. But TCP was expensive, it was affordable when you have to get only one or two files. But when you want to fetch more files like thirty files, you’ll have to make thirty different requests and the server has to process that same request thirty times. So this opening and closing the connection was very costly and took too much time.
The above problem was resolved in HTTP 1.1 very smartly, here we make one TCP connection and make it always open. Make all the requests under this TCP connection, do not close it unless you’re absolutely done with it. All of this was possible by using the header
keep-alive. This was a good solution, but there are occasions when you need real-time interaction from the server. There is some information that the server needs to send despite you requesting the server as a client.
To resolve the above problem, many solutions like long-polling, short polling, WebSockets were introduced. But WebSockets is the dominant one. So what WebSockets does is that it uses HTTP 1.1 and it’s persistent TCP connection as a vehicle to send the data from the client to the server and the server to the client. Now they both are aware of each other, which means it’s no longer stateless, it’s stateful right? Because the server is aware of the client and the client is aware of the server and the moment it happens, it becomes stateful.
We do the same thing here, the client starts with an HTTP request. We do the WebSocket handshake request which involves the exchange of a little bit of information. This handshake will first happen with the server. The server responds whether it supports WebSocket or not. After the connection is detached from HTTP and shifted to WebSocket or WS and now anyone from the client or server can make the request or respond because both know of each other, they have the access to the API of an underlying TCP connection.
Now let's talk about the WebSocket handshake. When we talk about handshakes, we first have to understand the protocol (ws:// and wss://). The first request we make is a normal HTTP GET request which is the persistent TCP connection. There’s one special header which is called
upgrade in the request. The server accepts the requests and if the server understands the
upgrade header and the client is trying to upgrade the HTTP 1.1 connection to something else (WebSocket in this case). The server will reply with
101 which means Switching Protocol. This is what handshake does and it has to be done on HTTP 1.1 as it makes the TCP persistent.
You might be wondering why do we need a full-duplex setup? Well, chatting is the best example. Chatting is not a great example of request and response models right? You’re not loading a page. The client can receive a message, someone can send you a message without you requesting them to send a message again and again. You want the message to automatically push into your inbox when there’s a new message. Having the client request for a new message only to find that there’s no new message is an overkill, costly, and not an efficient method.
In other words, you can say that when you want to keep a persistent connection, get the response from the server without requesting, get real-time data then you should switch to WebSockets.
We have already covered one use on the above section that is Chatting, let us cover the rest of the applications of WebSockets in this section:
Suppose you want to connect to a blog feed and you want to get notified whenever a new blog post is published, or want to get the Twitter live feed. This can be easily achieved through WebSockets because you don’t want to ping the APIs infinite times to get the new data in the feed. I remember when Google Wave was launched they were using WebSockets and whenever they started typing anything in the immediate window it started showing “Typing”. This was a very cool example of WebSocket back then in 2011.
Another prominent example is multiplayer gaming. For Example, multiple players can send their inputs and the user at the other gets the input from the multiple players immediately. But it gets a little bit tricky here, when multiple clients get connected to a single WebSocket connection then this WebSocket has to maintain multiple TCP connections with each of the clients. This is what makes it more stateful and more statefulness means we can not easily horizontally scale it. But that doesn’t mean you can not do it, you’ll have to write the code and cover all the corner cases because if one connection gets destroyed then all the client connections also get destroyed.
When you upload a file to a server, it displays the upload progress like 10% uploaded, 15% uploaded or you’re converting a .mp4 file to .mov, now you want the server to show the progress of completion. This is all possible by the WebSockets.
If you’re a trader or an investor, you have to check the price every second. Even a delay of 5 seconds can make you run into losses. So most of the exchange applications like CoinBase use WebSockets to display the real-time value of crypto coins or other data.
Websockets are being used in navigation apps like Google Maps, Uber Eats, Zomato, etc to track the GPS location of users. WebSockets are heavily used here as it needs to track real-time data for accuracy as well as efficiency.
WebSocket is a very popular and hot topic in web/app development. Without WebSocket real-time communication was difficult but not impossible. There are other methods as well to provide real-time experience such as polling but only WebSocket got the dominance in the market. This article just has the basic information about the WebSockets, in the next article we’ll be covering the advanced as well as the basic WebSocket setup, so stay tuned.