#WebSocket: The Real Bidirectional Channel

WebSocket is the only channel where both client and server can actively send messages at the same time. It is true full-duplex, not long-polling in disguise, and that makes it the backbone of chat, games, and collaboration tools.

#What it is

WebSocket, standardized in RFC 6455 in 2011, provides full-duplex communication over a single long-lived TCP connection. Unlike HTTP, which is request-response and requires the client to ask before the server can answer, WebSocket lets both sides send frames whenever they want. The connection stays open, so there is no repeated handshake overhead.

Think of WebSocket like a phone call. Once connected, both parties talk and listen freely, without having to hang up and redial every time they want to say something. HTTP is more like sending letters: each message requires opening and sealing a new envelope. WebSocket keeps the line open.

#Why it matters

• It is true full-duplex, so the server can push to the client without waiting for a request.
• A single TCP connection carries thousands of messages, which saves the overhead of repeated handshakes.
• Latency is low because the connection is never reopened.
• It is an RFC standard with native browser support, so no library is required on the client.
• It is the foundation of chat, multiplayer games, collaboration tools, and live trading platforms.

#How it works

WebSocket starts with an ordinary HTTP GET request carrying an Upgrade header. The server responds with status 101 Switching Protocols, and from that moment the connection is no longer HTTP. It has been upgraded to a full-duplex WebSocket channel. Both sides can now send text or binary frames at any time, independently and simultaneously.

In a chat application, when a user types a message, the client sends a JSON frame over WebSocket. The server receives it and broadcasts to every other open connection, so other users see the message almost instantly. This broadcast pattern is something REST cannot do. Because the connection is long-lived, you need to keep it alive with periodic ping and pong frames to detect breaks, and the client needs reconnect logic with exponential backoff. Without that, dead connections linger on the server and waste memory.

#Caveats

Long-lived connections consume RAM and file descriptors on the server, so WebSocket is more expensive per connection than stateless HTTP. Because it is stateful, horizontal scaling is harder: connections must be sticky to a specific node, which complicates load balancing. You must implement heartbeat and reconnect logic on the client. WebSocket is also overkill for infrequent events, where SSE or webhooks are lighter and simpler.

#Who it's for

WebSocket is for developers building chat and messaging, multiplayer games, real-time collaboration tools like Figma, live trading dashboards, and any application where both sides need to send and receive continuously with low latency. If your use case is only one-way server push, SSE is lighter. If events are infrequent, a webhook is simpler.

WebSocket is the right choice for continuous bidirectional realtime. Use it where it fits, and do not reach for it when a lighter pattern would do the job.

Source: https://datatracker.ietf.org/doc/html/rfc6455