What Are WebSockets?

Analogy categoryAnalogies

WebSockets (RFC 6455) are a communication protocol that provides a persistent, full-duplex channel between a browser (or any client) and a server over a single TCP connection. Unlike plain HTTP, where every exchange is a fresh request-response pair, a WebSocket connection stays open after an initial HTTP handshake, letting either side send messages at any time without re-establishing the connection or repeating headers.

🏏

Cricket analogy: Comparing it to a stump mic left on throughout a Test match at Lord's, capturing every sound continuously, rather than a reporter re-dialing the dressing room after every over for an update.

Full-Duplex, Persistent Communication

Full-duplex means both the client and the server can transmit data independently and simultaneously over the same connection, rather than taking strict turns. Because the underlying TCP connection is kept open, WebSockets avoid the overhead of re-negotiating TCP handshakes, TLS sessions, and HTTP headers on every exchange, which matters enormously once you're sending dozens or hundreds of small messages per second.

🏏

Cricket analogy: Like a two-way stump mic and coach's earpiece letting the captain and coach talk simultaneously during a strategic timeout, unlike a walkie-talkie relay where only one side speaks at once.

javascript

const socket = new WebSocket('wss://example.com/chat');

socket.addEventListener('open', () => {
  console.log('Connected');
  socket.send(JSON.stringify({ type: 'join', room: 'general' }));
});

socket.addEventListener('message', (event) => {
  const data = JSON.parse(event.data);
  console.log('Received:', data);
});

socket.addEventListener('close', (event) => {
  console.log('Closed', event.code, event.reason);
});

socket.addEventListener('error', (err) => {
  console.error('WebSocket error', err);
});

Where WebSockets Fit in the Stack

WebSockets operate as an application-layer protocol layered on top of TCP, identified by the ws:// and wss:// URL schemes, typically using ports 80 and 443 respectively so they pass through the same infrastructure as regular web traffic. They shine in scenarios needing low-latency, server-initiated updates: chat applications, live dashboards, multiplayer games, and collaborative editing tools where multiple users see each other's changes instantly.

🏏

Cricket analogy: Like the live win-probability graph broadcasters overlay during an IPL run chase, updated continuously the way a WebSocket feed pushes fresh scores to every viewer's app instantly.

Intermediary infrastructure matters: reverse proxies (nginx, HAProxy) and load balancers must be explicitly configured to forward the HTTP Upgrade and Connection headers, and sticky sessions are often required so a client's messages keep reaching the same backend instance for the life of the connection.

The WebSocket API in the Browser

Browsers expose a native WebSocket constructor that opens a connection and exposes a small set of lifecycle events: open fires once the handshake succeeds, message fires for each incoming payload, error fires on protocol or network failures, and close fires when the connection ends, carrying a status code and reason. The readyState property (CONNECTING, OPEN, CLOSING, CLOSED) lets application code guard against sending data before the connection is ready.

🏏

Cricket analogy: Like a scorer's checklist for a match: toss happened (open), runs scored are logged as they come (message), a rain delay is flagged (error), and stumps drawn is recorded (close).

WebSockets are not a drop-in replacement for every HTTP call. For occasional request/response interactions — fetching a user profile, submitting a form — plain HTTP/REST is simpler, cacheable by CDNs, stateless, and easier to horizontally scale. Reach for WebSockets only when you need low-latency, server-initiated, bidirectional updates.

WebSockets provide a persistent, full-duplex connection over a single TCP socket, defined in RFC 6455.
The connection starts as an HTTP request with an Upgrade: websocket header before switching protocols.
Both client and server can send messages at any time without waiting for a request.
ws:// is unencrypted (like http://) and wss:// is encrypted over TLS (like https://).
Typical use cases include chat apps, live dashboards, multiplayer games, and collaborative editors.
Proxies and load balancers need explicit configuration to support the Upgrade handshake and long-lived connections.
WebSockets add complexity versus REST, so they should be reserved for genuinely real-time needs.