WebSockets

NetworkingMidapinetworking

The Question

What are WebSockets and when would you use them instead of HTTP?

What a Strong Answer Covers

• HTTP upgrade (101)
• "full-duplex
• "persistent
• use case

Senior-Level Answer

WebSockets are a protocol (RFC 6455) that provides full-duplex, persistent communication over a single TCP connection. Unlike HTTP's request-response model, where the client initiates every exchange, a WebSocket connection allows both the client and server to send messages independently at any time after the connection is established.

Establishment uses an HTTP upgrade handshake: the client sends an HTTP GET with `Upgrade: websocket` and `Connection: Upgrade` headers plus a `Sec-WebSocket-Key`. The server responds with 101 Switching Protocols and a `Sec-WebSocket-Accept` header derived from the key. After this, the connection switches from HTTP framing to the WebSocket binary framing protocol on the same underlying TCP socket. This design means WebSockets work through existing HTTP infrastructure (proxies, load balancers, firewalls) on ports 80 and 443.

The wire format is frame-based: frames have an opcode (text, binary, ping, pong, close), payload length, and optional masking (client-to-server frames are always masked to prevent cache poisoning attacks on intermediaries). Messages can span multiple frames (fragmentation).

When to use WebSockets over HTTP: real-time bidirectional use cases where the server needs to push data without the client polling. Classic examples: live chat, collaborative editing (Google Docs-style), multiplayer games, live trading/financial data feeds, live sports scores, and collaborative code editors. Also appropriate when you need low latency and high frequency updates — WebSocket message overhead is much lower than HTTP headers on every message.

When not to use WebSockets: simple request-response APIs, infrequent updates where Server-Sent Events (SSE) or long polling suffice, scenarios requiring stateless horizontal scaling (WebSocket connections are stateful and sticky), or when HTTP/2 server push covers the use case.

Scaling WebSocket servers requires sticky sessions (connections must reach the same server instance) or a pub-sub broker (Redis, Kafka) that routes messages to whichever server instance holds a given connection. This adds operational complexity versus stateless HTTP services.

In Python, `websockets` or `fastapi`/`starlette` WebSocket support is common. In Node.js, `ws` or `socket.io` (which adds fallbacks and rooms). `socket.io` is not WebSockets — it has its own protocol with polling fallback and higher-level abstractions.

What Separates a 2/3 from a 3/3

Common Mistakes

• Saying WebSockets bypass HTTP entirely — the connection starts with an HTTP upgrade handshake and runs on the same ports.
• Not knowing Server-Sent Events (SSE) as an alternative — SSE is simpler for server-push-only use cases and doesn't require persistent bidirectional connections.
• Ignoring scaling implications — WebSocket connections are stateful, which breaks standard stateless horizontal scaling assumptions.
• Confusing socket.io with WebSockets — socket.io is a higher-level library with its own protocol; it uses WebSockets as a transport but is not WebSockets.

Follow-Up Questions

• How would you scale a WebSocket service to multiple server instances? — Sticky sessions at the load balancer, plus a pub-sub broker (Redis pub/sub, Kafka) so any server can publish and the holding server delivers to the connected client.
• When would you choose Server-Sent Events over WebSockets? — SSE is simpler for server-push-only (no client-to-server messages needed): unidirectional, HTTP-native, automatic reconnection. No upgrade handshake, works with HTTP/2 multiplexing.
• How do WebSockets handle connection drops and reconnection? — The protocol has ping/pong frames for keepalive. Reconnection is application logic — the client must detect the close event and re-initiate the upgrade handshake.
• Why are client-to-server WebSocket frames masked? — Masking prevents cache poisoning: an attacker could craft JavaScript that sends frames that look like HTTP responses, poisoning transparent proxy caches. Masking makes the payload unrecognizable to proxies.

Related Questions

• TCP — 3-Way Handshake
• TLS — Certificate, DH, AES
• TCP vs UDP
• HTTP vs HTTPS
• REST vs gRPC