Introduction to WebSockets

In this article, we’ll delve into the concept of WebSockets, from its basic definition to its practical applications. To truly understand WebSockets, it’s essential to first familiarize ourselves with the foundational mechanics of the web. For example, when you access ‘http://www.example.com' through browsers like Chrome or Firefox, you’re actually sending a request to a server that holds the desired content.

Let’s break down the URL to further understand this process.

• URL Protocol: Specifies the method used to access resources.
• The Host: Represents the computer where the desired resources, like a webpage, are stored.

After retrieving the requested webpage, the web browser disconnects from the server, in line with the design of the HTTP protocol. HTTP is inherently stateless, meaning once data is sent or received, the connection between the client and server is terminated.

HTTP is stateless: after sending a request, the connection to the server (client-server connection) is lost.

The Need to Evolve

As the web evolves, it becomes clear that the traditional HTTP model falls short of the needs of modern web apps that require reliable, real-time communication with minimal latency. Online gaming, collaborative platforms, and live data visualization, among others, set new standards for web communication. Some limitations of HTTP include:

• It being half-duplex, traffic flows only in one direction at a time.
• Its request-response nature, which means if clients want to push data, they resort to techniques like frequent polling.
• The inherent latency it introduces.

In 2005, AJAX emerged, allowing web browsers to send data to servers asynchronously without the need for page refreshes. While this improved the web experience, it wasn’t perfect. The browser had to constantly check or “poll” the server for updates, leading to increased overhead and latency.

Then, more intricate solutions like Comet appeared, introducing the long-polling approach. Here, the browser would request updates from the server and wait there for a response. While this method used two connections, it often led to unnecessary complexity. Solutions like Comet frequently opened superfluous connections, proving inefficient, especially when servers had no updates to deliver to the client.

An Ideal Solution

For a clear picture of optimal client-server communication, consider the following comparison:

A sub-optimal approach:

The optimal solution:

WebSockets address the inefficiencies of the prior method.

What are WebSockets?

Traditionally, during web browsing, a browser (or client) communicates with a server using HTTP methods like ‘GET’ or ‘POST’. In this setup, the client sends a request, and the server sends back a response.

Enter WebSockets. They maintain a persistent connection between the client and server, enabling the server to send data anytime without waiting for a specific request. A prime example is how new emails instantly appear in Gmail without requiring a manual refresh. This continuous, two-way interaction is known as “full-duplex” communication.

WebSocket essentially addresses the limitations of HTTP by enabling this full-duplex, bi-directional communication. It operates like an upgraded version of HTTP, utilizing its own protocols — ws:// or wss://.

In essence, WebSocket sets up a connection via an HTTP handshake, facilitates the exchange of messages, and then concludes the connection. The advantage? It eliminates the need for long-polling, resulting in enhanced efficiency and reduced bandwidth consumption.

In the upcoming segment, “Introduction to Websockets, pt-2”, we’ll examine a hands-on implementation of the WebSocket standards.