How do WebSockets work?

WebSockets work by establishing a persistent, full-duplex connection between a client and server over a single TCP connection. The process begins with the client sending an HTTP request containing a "Connection: Upgrade" header to initiate a WebSocket handshake. The server responds with an HTTP 101 status code, confirming the protocol switch to WebSocket. Once established, the connection allows bidirectional communication without the need for additional HTTP requests, enabling real-time data exchange. Messages are framed into text or binary data, and the connection remains open until explicitly closed by either party or disrupted by network issues.

For example, in a live chat application, messages can be delivered instantly to all users without refreshing the page or frequent HTTP requests.

Google Chrome was the first browser to include standard support for WebSockets in 2009. RFC 6455—The WebSocket Protocol—was officially published online in 2011. The Google WebSocket Protocol and WebSocket API are standardized by the W3C and the IETF, and support across browsers is very common.

Drawbacks of Web Sockets

• Browser Support: Although most modern browsers support WebSockets, some older ones do not. This can limit the reach of your application and require additional fallback mechanisms for older browsers.

• Proxy and Firewall Limitations: Some proxy servers and firewalls may block or interfere with WebSocket connections. This can cause connectivity issues, especially in secured corporate or restricted network environments.

• Scalability: Web Sockets maintain a persistent connection between the client and the server, which can strain server resources when dealing with many concurrent connections. Proper load balancing and resource management techniques must be implemented to ensure scalability. Open-source resources, like Socket.io, are not great for large-scale operations or quick growth.

• Stateful Nature: Unlike HTTP, which is stateless, WebSockets are stateful. This means that the server needs to maintain the connection state for each client, leading to increased memory usage and potential scalability challenges.

• Security Considerations: With the persistent connection established by WebSockets, there is a need for proper security measures to protect against potential vulnerabilities, such as cross-site scripting (XSS) and cross-site request forgery (CSRF). Secure WebSocket connections (wss://) using SSL/TLS encryption should be implemented to ensure data privacy and integrity.

• Connection Disadvantage: If a connection over Web Sockets is lost, there are no included load balancing or reconnecting mechanisms.

• It is still necessary to have fallback options, like HTTP streaming or long polling, in environments where Web Sockets may not be supported.

• Features like Presence do not work well over WebSocket connections because disconnections are hard to detect.

WebSockets place in tech stack

WebSockets fit into the communication layer of a technology stack. On the server-side, WebSockets are integrated into backend frameworks (e.g., Node.js, Spring, Django) to manage connections. WebSockets pass through load balancers, API gateways, and can be secured using WSS (TLS/SSL) for encrypted communication. Depending on the application architecture, they are typically positioned as part of the following layers:

1. Client Layer:

   • Web Browsers (Frontend) WebSockets are most commonly used in web applications, where the frontend (e.g., a JavaScript app in a browser) establishes a WebSocket connection to interact with the server in real-time.

   • Mobile Apps Native mobile applications (iOS/Android) also use WebSocket libraries to establish real-time communication with servers.

2. Server Layer:

   • Backend Frameworks WebSockets are integrated within server-side frameworks (e.g., Node.js, Django, Spring, ASP.NET) to facilitate real-time communication with clients. This includes frameworks like PubNub, Spring WebSocket, or SignalR.

   • WebSocket Servers Specialized servers or services that handle WebSocket connections, such as

     WebSocket servers built with Node.js (using ws or Socket.IO), Java-based solutions with javax.websocket, or other language-specific implementations.

3. Application Layer:

   • Real-Time Applications WebSockets are commonly used in applications requiring live updates, such as chat systems, online games, stock ticker apps, live data feeds, and collaborative tools.

   • Push Notification Systems WebSockets are part of push-based notification systems, where the server sends data to clients immediately when events occur.

4. Communication (Cloud/Networking) Layer:

   • API Gateways & Load Balancers WebSocket traffic often passes through API gateways or load balancers, which need to be configured to support long-lived connections. Some cloud providers (like AWS and Google Cloud) offer WebSocket support in their API Gateway services.

   • WebSocket Proxies Proxies and reverse proxies (e.g., Nginx, HAProxy) can be configured to handle WebSocket connections.

5. Security Layer: TLS/SSL can be used to secure connections with WSS ( wss:// WebSocket Secure), which operates over TLS, similar to HTTPS for web pages, ensuring encryption and secure communication.

WebSockets vs. HTTP vs. web servers vs. polling

HTTP connections vs. WebSockets

To understand the WebSocket API, it is also important to understand the foundation it was built on – HTTP (Hypertext Transfer Protocol) and its request/response model. HTTP is an application layer protocol and the basis for all web-based communication and data transfers.

When using HTTP, clients—such as web browsers—send requests to servers, and then the servers send messages back, known as responses. The web as we know it today was built on this basic client-server cycle, although there have been many additions and updates to HTTP to make it more interactive. There are currently a few viable and supported versions of HTTP—HTTP/1.1 and HTTP/2—and a secure version known as HTTPS.

Basic HTTP requests work well for many use cases, such as when someone needs to search on a web page and receive relevant, non-time-sensitive information. However, it is not always best suited for web applications requiring real-time communication or data that needs to update quickly with minimal latency. 

Whenever the client makes a new HTTP server request, the default behavior is to open a new HTTP connection. This is inefficient because it uses bandwidth on recurring non-payload data and increases latency between the data transfers.

 Additionally, HTTP requests can only flow in one direction—from the client side. There is traditionally no mechanism for the server to initiate communication with the client. The server cannot send data to the client unless it requests it first. This can create issues for use cases where messaging needs to go out in real time from the server side. 

Short polling vs. WebSockets

One of the first solutions for receiving regular data updates was HTTP polling. Polling is a technique where the client repeatedly sends requests to the server until it updates. For example, all modern web browsers offer support for XMLHttpRequest, one of the original methods of polling servers.

These earlier solutions were still not ideal for efficient real-time communication—short polling is intensive because, for every request, the non-payload data is re-sent and must be parsed, including the header HTML, the web URL, and other repetitive information that wastes resources.

Long polling vs. Web Sockets

The next logical step to improve latency was HTTP long polling. When long polling, the client polls the server, and that connection remains open until the server has new data. The server sends the response with the relevant information, and then the client immediately opens another request, holding again until the next update. Long polling can hold a connection open for a maximum of 280 seconds before automatically sending another request. This method effectively emulates an HTTP server push.

Long polling provides fast communication in many environments and is widely used, often as opposed to true push-based methods like Server Side Events (SSE). Long polling can seem intensive on the server side, as it requires continuous resources to hold a connection open, but it uses much less than repeatedly sending polling requests.