WebSocket and Real-time

Binance WebSocket API processes 100 million WebSocket messages per day - real-time cryptocurrency quotes for traders worldwide. Latency: under 10ms from exchange to client. With polling every 30 seconds, 99.99% of traders would lose money on stale prices.

• **Slack**: switching from polling to WebSocket in 2013 reduced message latency from 30 seconds to 200ms - the difference between email and a messenger
• **ChatGPT/Claude API**: SSE for streaming tokens - each word in the response arrives as a separate event
• **Figma**: WebSocket for real-time collaborative editing - every cursor movement is synchronized between participants

WebSocket: A Persistent Bidirectional Channel

Slack in 2013: the first version used polling every 30 seconds. Message latency: up to 30 seconds. After switching to WebSocket - latency under 200ms. That's the difference between a messaging app and a messenger.

WebSocket is RFC 6455 protocol over TCP. It starts with an HTTP Upgrade handshake: the client sends GET with `Upgrade: websocket` and `Sec-WebSocket-Key` headers, the server responds with 101 Switching Protocols. After that, the HTTP connection becomes a WebSocket - a raw TCP channel with framing. Both sides can send data at any moment without a request-response cycle.

WebSocket vs HTTP/2 Server Push: HTTP/2 adds multiplexing and server push to HTTP, but this is a one-directional server initiative. WebSocket is a full-duplex channel: both sides are equal. gRPC bidirectional streaming over HTTP/2 is technically similar to WebSocket for server-client communication. The choice depends on ecosystem: browser + arbitrary data = WebSocket, gRPC-web for TypeScript clients.

Socket.IO: WebSocket with Batteries Included

Raw WebSocket is a raw protocol. No rooms, no namespaces, no automatic reconnect, no fallback when WebSocket is blocked by a corporate proxy. Socket.IO solves all these problems by adding an abstraction layer over the transport: WebSocket first, fallback to HTTP long-polling.

Socket.IO features: automatic reconnect with exponential backoff, namespace (event stream isolation), rooms (broadcast to a group), acknowledgments (delivery confirmation), multiplexing over one WebSocket. But Socket.IO is not compatible with a pure WebSocket client - it's a proprietary protocol on top of WebSocket.

Socket.IO horizontal scaling: if multiple Node.js processes serve WebSocket connections, a room event may affect clients on different instances. Solution: Socket.IO Redis Adapter. Pub/Sub through Redis: when a server wants to broadcast to a room, it publishes to a Redis channel; all instances receive it and relay to their own clients. Sticky sessions are an alternative: always route one client to the same instance.

Server-Sent Events: One-Way Streaming

Not every real-time application needs bidirectionality. A metrics dashboard, news feed, upload progress, live sports scores - data flows from server to client. WebSocket is overkill for this. SSE (Server-Sent Events) is a W3C standard specifically for this scenario: HTTP/1.1 + chunked transfer encoding.

SSE is simpler than WebSocket in several ways: works over standard HTTP (transparent to proxies and CDNs), automatic reconnect is built into the browser (EventSource), text-based (JSON natively), supports event types and Last-Event-ID for resumption. Limitation: server -> client only, maximum 6 concurrent SSE connections in HTTP/1.1 (no limit in HTTP/2).

OpenAI ChatGPT API uses SSE for token streaming - that's why the answer appears word by word rather than all at once. Each token = one SSE event. GitHub Copilot, Anthropic Claude API - same pattern. SSE is ideal for streaming AI responses: HTTP/2 compatible, no connection overhead like WebSocket, text is sent as soon as it's generated.

Long Polling: When WebSocket Is Unavailable

Some corporate proxies block WebSocket (non-standard upgrade). Some mobile networks have issues with long-lived connections. Long polling is an HTTP-based fallback: the client makes an HTTP request, the server holds it open until data arrives (or timeout), the client immediately makes the next request. Simulating push through pull.

Comparing techniques: Regular polling (1 req/sec): high overhead, guaranteed latency up to T. Long polling: minimal latency when data arrives, reconnect overhead. SSE: one long-lived HTTP connection, ideal for streaming. WebSocket: bidirectional, minimal overhead per message. The choice depends on latency requirements, data directionality, and infrastructure constraints.

WhatsApp Web in 2013 used long polling before switching to WebSocket. Facebook Messenger used long polling until 2011. Today long polling is mainly a fallback strategy in Socket.IO (when WebSocket is blocked by a corporate proxy). If WebSocket is unavailable, Socket.IO automatically falls back to long polling - transparently for the application.

Related Topics

Real-time communication intersects with protocols, security, and mobile development:

• HTTP and Network Protocols — WebSocket starts as an HTTP upgrade - understanding HTTP/1.1 and TCP is required
• Push Notifications — APNS/FCM - WebSocket alternative for mobile real-time when app is in the background
• DDoS and Security — WebSocket connection flood is a DoS vector; rate limiting at the WS connection level

Key Ideas

• **WebSocket**: HTTP upgrade -> TCP channel with framing; full-duplex, minimal overhead per message; wss:// for production
• **Socket.IO**: abstraction over WebSocket with rooms, namespaces, reconnect, fallback; Redis adapter for horizontal scaling
• **SSE**: one-way server->client streaming over HTTP; built-in browser reconnect; ideal for AI streaming and dashboards
• **Long polling**: HTTP fallback for restricted environments; Socket.IO uses it automatically when WebSocket is blocked

Вопросы для размышления

• A collaborative editor (like Figma or Google Docs) - which transport to choose? What happens when simultaneous changes conflict?
• A WebSocket connection dropped. How should the client handle reconnect? What happens to messages sent while the connection was down?
• ChatGPT uses SSE for token streaming. Why not WebSocket, despite its 'superiority'?

Связанные уроки

• web-05 — HTTP/1.1 and TCP are the protocol foundation that WebSocket extends via the upgrade mechanism
• web-16 — Bundlers optimize WebSocket client code for production
• mob-15 — Push notifications are an alternative real-time channel for mobile when WebSocket is unavailable in the background
• sec-15 — WebSocket connections can be a DoS vector - connection exhaustion attacks
• par-09 — Event loop is the foundation for handling thousands of WebSocket connections in Node.js without threading
• net-21-http-basics