What is WebSocket?

Why plain HTTP is not enough

In the classic request-response model the client always speaks first. When the server has a new chat message or a price changes, it has no way to tell the browser on its own. For years the workaround was polling: asking “anything new?” every few seconds, which wastes requests and still delivers updates late. Long polling improved this by holding each request open until data arrived, at the cost of constantly re-establishing requests. WebSocket removes the limitation altogether by keeping one connection open and letting both sides talk whenever they want.

The opening handshake

A WebSocket connection begins life as an ordinary-looking HTTP/1.1 request asking to switch protocols. This is the example from RFC 6455:

GET /chat HTTP/1.1
Host: server.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Origin: http://example.com
Sec-WebSocket-Version: 13

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=

The Sec-WebSocket-Accept value is derived from the client's key, proving the server really speaks the protocol. From then on the TCP connection carries WebSocket frames instead of HTTP. URLs use ws:// or, encrypted with TLS, wss://; production traffic should always use the latter.

Frames and the browser API

Data travels in text or binary frames, alongside control frames: ping and pong to check the connection is alive, and close for an orderly shutdown. Every frame sent from client to server must be masked, a rule designed to stop intermediaries from being confused into caching attacker-controlled bytes. In the browser the API is small:

const ws = new WebSocket("wss://example.com/live");
ws.addEventListener("open", () => ws.send(JSON.stringify({ subscribe: "orders" })));
ws.addEventListener("message", (e) => render(JSON.parse(e.data)));
ws.addEventListener("close", () => scheduleReconnect());

Choosing between polling, SSE and WebSocket

• Polling is fine for data that changes rarely and when simplicity matters most.
• Server-Sent Events suit one-way streams from server to browser: notifications, job progress, live feeds. They run over plain HTTP and reconnect automatically.
• WebSocket earns its extra complexity when both sides send frequent messages: chat, collaborative editors, trading screens, games.

Running WebSockets in production

• Proxies: a reverse proxy must forward the Upgrade and Connection headers. In nginx that means proxy_set_header Upgrade $http_upgrade; and proxy_set_header Connection "upgrade";. By default nginx also closes the connection if the backend sends nothing for 60 seconds, so send periodic pings or raise proxy_read_timeout.
• Scaling out: each connection is pinned to one server instance. With several instances, a broadcast layer such as Redis pub/sub routes messages to whichever instance holds the recipient's socket, and the load balancer must tolerate long-lived connections.
• Authentication and origin checks: browsers send cookies with the handshake. A server that does not validate the Origin header may accept connections opened by another site on the user's behalf.
• Reconnection: mobile connections drop constantly. Clients should reconnect with exponential backoff, and the server needs a way to replay or resync what was missed.