In this article, we will delve into the evolution of HTTP and the web, exploring the advent and application of WebSocket in today's digital landscape.

As users, we often take for granted how our apps seamlessly send and receive large amounts of data without our notice. Consider this: when was the last time you had to manually refresh your favorite app or website?

Instant-response applications provide a seamless user experience by delivering fresh content immediately, whether it's live instant messaging, or online games. While we now expect this immediacy, there was a time when users had to refresh their browsers for updates, a process that feels outdated and inefficient today.

so which Technology enabled this miraculous, instantaneous, bidirectional communication behaviour on the web.

HTTP 1.0

Hypertext Transfer Protocol (HTTP) is the set of rules and information systems that first enabled data transfer across the web. In short, HTTP 1.0 involved a request response cycle between client and server.

First, the request is always initiated by the client.

Second, one (successful) request from the client always gets one and one only response from the server. After that, the connection between client and server is closed.

Using HTTP 1.0, sending 100 messages in a chat app would require 100 separate request-response cycles. The recipient would need to refresh the page repeatedly to see each new message.

Herein the problem lies. Because the connection between server and client is lost at the end of every request-response cycle, the server does not typically maintain information about previous requests or the state of what the client sees, HTTP is therefore known as a stateless protocol.

Stateless behavior is suitable for viewing static content, like reading a Wikipedia article or checking the news. It minimizes data transfer by rendering content once and waiting for a new client request before doing anything further.

This is where WebSocket come into play.

HTTP 1.1 and WebSocket

WebSocket serve dual roles: a set of rules for client and server on how to establish communication and transmit data to each other and a transport layer for data exchange. They facilitate the transmission of various data formats such as JSON and XML.

In a regular HTTP 1.0 request, the client asks the server for something specific by providing a URL and stating which version of HTTP it's using. Then, the server responds with a status code that tells whether the request was successful and includes the requested content.

But In order to establish WebSocket connection the client sends a HTTP request (Which also contain upgrade header) to establish a connection between client and server.

The server responds with a 101 header and says WebSocket is open for real time data exchange between multiple clients and server.

This is also known as Web socket Hand shake.

WebSocket's are built on top of the TCP layer (a data-transport protocol that depends on two hosts having a connection before any data can be sent), and modify the TCP/IP socket so that client and server can agree for the socket to stay open.

A highly persisted connection is established between client and server keeping TCP/IP socket open.

At any point of time connection can be closed by client.

Providing the request is successful, a WebSocket connection has been made. The server can now emit, via a WebSocket, real-time updates on football scores, chat messages from the client’s friends and more. Not only that, it can do so unprompted by an initiating request from the client, and it can do it over, and over, and over again.

WebSocket in modern web development usingSocket.IO

One of the most popular libraries enabling users to use WebSocket in their projects is Socket.IO. But what exactly is Socket.IO?

Socket.IO is a library that enables low-latency, bidirectional and event-based communication between a client and a server.

The Socket.IO connection can be established with different low-level transports:-

• HTTP long-polling

• Web socket

Socket.IO simply adds a syntactic ‘wrapper’ around the standard WebSocket API found in node, making it slightly easier to read and work with.

Socket.IO isn't a WebSocket implementation, despite common misconceptions.

Socket.IO's purpose is to enable “real-time, bidirectional and event-based communication between the browser and the server”. Most of the time, this means giving us a slightly more usable interface than the WebSocket API that comes with Node.

In certain situations, setting up WebSocket can be challenging, especially when dealing with proxies or load balancers. In such cases, Socket.IO utilizes Engine.IO to create a long-polling connection between the server and client.

In brief, long-polling is a method of maintaining a close-to-persistent connection between client and server. In long-polling, the client sends a request to the server, and the connection is not closed until the server responds. Immediately following the response and the closing of the connection, the browser resends the request, thereby reopening the connection. While this does create the impression of a persistent connection between client and server, it does not truly enable bidirectional communication, and is a far less versatile than WebSocket.

It is clear, then that WebSocket are not only extremely useful in supporting the modern web experience, but they’re also not too difficult to use. Libraries like Socket.IO make the experience even easier.