WebSocket

HTTP follows a request-response pattern: the client requests, then the server responds. If new data appears on the server side but the client has not requested it, the server has no way to deliver it. To notify that a chat message arrived, a stock price changed, or another user edited a document, the client has to keep asking the server 'any new data?' This polling approach wastes server load and bandwidth on repeated requests even when there is nothing new, and real-time responsiveness suffers depending on the polling interval. Workarounds like HTTP Long Polling and Server-Sent Events exist, but Long Polling has the overhead of repeatedly opening and closing connections, and Server-Sent Events only support server-to-client one-way communication. Ultimately, a communication method where both client and server can freely send data over a single connection becomes necessary. WebSocket is the direct answer to that need.

As the web transformed from a document delivery medium into an application platform requiring real-time interaction, HTTP's request-response model hit its limits more frequently. Initially, Ajax and polling were used to simulate a real-time feel, but the approach of periodically poking the server caused unnecessary connections and server load to spike as the user count grew. Long Polling improved immediacy by delaying the response, but the cost of re-establishing connections remained. Techniques like Comet had cross-browser compatibility issues. As these limitations accumulated, a standard protocol was needed that could start with HTTP but then let both sides freely send messages afterward. WebSocket, standardized in 2011 (RFC 6455), was pivotal because it made full-duplex communication possible while maintaining HTTP infrastructure compatibility. Because existing web servers, proxies, and firewalls already understood HTTP, the design of starting with an HTTP upgrade greatly aided real-world adoption.

A WebSocket connection starts as a normal HTTP request. The client sends an HTTP request containing the `Upgrade: websocket` header, and when the server responds with `101 Switching Protocols`, the same TCP connection switches to the WebSocket protocol from that point. After that, HTTP's request-response structure disappears, and it becomes a full-duplex channel where either side can send message frames to the other at any time. WebSocket frames are much smaller than HTTP headers (2--14 bytes), so the overhead of exchanging messages over an already-open connection is very low. Text frames and binary frames can be distinguished, and Ping/Pong frames periodically verify that the connection is still alive. When closing the connection, both sides exchange Close frames to give each other time to clean up. Thanks to this structure, once connected, the server can push to the client the instant an event occurs, and the client can send messages to the server without a separate request.

WebSocket and HTTP are both application-layer protocols running on top of TCP, and a WebSocket connection itself starts with an HTTP handshake. But their communication patterns are fundamentally different. HTTP is a half-duplex structure where the client requests and the server responds, so for the server to send data first it must either wait for a client request or use a workaround. WebSocket is a full-duplex structure where once connected, both sides send messages independently. Server-Sent Events (SSE) also support server push, but only in the server-to-client direction, and since it runs on top of HTTP, it has the advantage of not requiring a separate protocol switch. If bidirectionality is not strictly needed and server push alone is sufficient, SSE is the simpler choice. If bidirectional real-time message exchange is the core requirement, WebSocket is the right fit, and if the interaction is a traditional request-response, HTTP is enough.

WebSocket is the most natural choice for chat, real-time notifications, live dashboards, collaborative editing, and multiplayer games -- scenarios where the server and client need to maintain a connection and exchange messages bidirectionally and frequently. It especially excels when server events occur irregularly and latency needs to be within tens of milliseconds, demands that polling cannot meet. On the other hand, if the server only sends data occasionally and the client does not need to respond, SSE is simpler. For typical API calls or page loads where a single request-response suffices, using WebSocket only adds connection maintenance overhead. Additionally, WebSocket connections are stateful and consume server memory, so with hundreds of thousands of concurrent connections, server resources and load balancer connection management become important design considerations. Whether the load balancer correctly handles WebSocket upgrades and whether the proxy avoids cutting long-lived connections are also deployment checks that should be confirmed beforehand.