WebSockets & SSE

WebSockets establish a persistent, full-duplex TCP connection over HTTP/1.1 upgrade, enabling true bidirectional real-time communication between client and server. Server-Sent Events (SSE) are a simpler, unidirectional alternative (server to client only) over a long-lived HTTP connection, automatically resuming with the Last-Event-ID header after disconnection. The choice between them depends on use case: WebSockets for chat, collaborative editing, and gaming; SSE for live dashboards, news feeds, and notification streams.

Key Points

• WebSocket handshake: client sends HTTP GET with Upgrade: websocket and Sec-WebSocket-Key header; server responds 101 Switching Protocols — connection becomes a raw TCP socket, no more HTTP overhead.
• WebSocket frame overhead: 2–10 bytes per frame vs 200–800 bytes per HTTP request; critical for high-frequency updates (trading tickers, live game state, cursor positions).
• Heartbeat / ping-pong: send a PING frame every 30 seconds; if no PONG within 10 seconds, close the connection — detects half-open connections where the TCP layer shows connected but the remote is gone.
• Reconnection strategy: exponential backoff starting at 1 second, cap at 60 seconds, jitter ±10% to avoid thundering herd when a WebSocket server restarts with thousands of connected clients.
• WebSocket horizontal scaling: each connection is stateful on a specific server; route clients to the same server using sticky sessions (IP hash or cookie), or use a pub/sub backplane (Redis Pub/Sub, Kafka) to fan messages to all servers.
• SSE advantages over WebSockets: works over HTTP/1.1 (no proxy issues), supports automatic reconnection with Last-Event-ID, streams over standard HTTP (works with CDN, load balancers without special config).
• SSE max connections per browser: browsers limit HTTP/1.1 connections to 6 per origin; SSE uses one of those — use HTTP/2 to remove this constraint (HTTP/2 multiplexes all SSE streams on one TCP connection).
• Long polling as fallback: client sends a request, server holds it open until data is available (up to 30 seconds), then responds and client immediately re-requests — high latency vs WebSocket but universally compatible.