Computer Networks
WebSocket: Two-Way Communication
HTTP is like postal mail: the client sends a letter and waits for a reply. But what if the server wants to write first? WebSocket is a phone call: the line is open, speak whenever you want.
- **Slack/Discord** - millions of WebSocket connections for instant messaging
- **Trading terminals** - quotes update 10-100 times per second via WebSocket
- **Figma/Google Docs** - other users' cursors and changes in real time
Предварительные знания
Why WebSocket is Needed
HTTP was designed for request-response: the client asks, the server responds. But what if the server needs to send data to the client without a request? Stock quotes, chat messages, player positions - all of this requires **push from the server**.
**WebSocket** (RFC 6455) - a full-duplex communication protocol over TCP. One connection, data in both directions at any time. Perfect for real-time applications.
WebSocket uses the same ports as HTTP (80/443) and starts with an HTTP request. This allows it to pass through proxies and firewalls. After the connection is established, HTTP "steps aside" - the binary WebSocket protocol takes over.
What HTTP problem does WebSocket solve?
Upgrade Handshake: Protocol Switch
A WebSocket connection starts with a regular HTTP request. The client sends the `Upgrade: websocket` header, and if the server agrees - it responds with status **101 Switching Protocols**. After that, the TCP connection switches to the WebSocket protocol.
**Sec-WebSocket-Key/Accept** - a protection mechanism against accidental connection. The client sends a random key, the server concatenates it with a magic string and returns the SHA-1 hash. This is not encryption - it's a verification that both sides understand the protocol.
After the handshake the TCP connection remains open. Both sides can send **frames** - small data packets with a minimal header. The connection lives until one side closes it or a disconnect occurs.
Which HTTP status indicates a successful switch to WebSocket?
WebSocket Frames: Data Structure
After the handshake, data is transmitted as **frames**. Each frame has a header (2-14 bytes) and a payload. Frame types: text (UTF-8), binary, control (ping/pong/close).
**Masking** - the client is required to mask the payload using a 4-byte key. This protects against cache poisoning attacks through proxies. The server sends data without masking.
Large messages can be split into multiple frames (fragmentation). FIN=0 means "more to follow", FIN=1 means the last frame. This allows streaming data without buffering the entire message.
Why is the client required to mask the payload in WebSocket?
WebSocket Use Cases and Alternatives
WebSocket is ideal for scenarios with frequent two-way updates. But not every real-time application needs WebSocket - sometimes SSE or even polling is sufficient.
**Server-Sent Events (SSE)** - one-way push from the server over HTTP. Simpler than WebSocket, automatic reconnect, but only server→client. Not suitable for chat, but great for notifications.
**Socket.IO** - a popular library that abstracts the transport layer. It tries to use WebSocket but automatically falls back to long-polling if WS is unavailable. Adds rooms, broadcasting, and reconnect.
**WebTransport** - a new standard for real-time in the browser over HTTP/3 (QUIC). Supports unreliable datagrams (like UDP) and multiple streams. For games and video it may replace WebSocket.
WebSocket is always better than HTTP for real-time applications
WebSocket adds complexity (state, reconnect, scaling). For simple push notifications, SSE is simpler and more reliable
WebSocket requires managing connections on the server side, which complicates horizontal scaling. SSE works over HTTP and passes easily through CDN, proxies, and load balancers. Choose the technology for the task: SSE for push, WebSocket for full-duplex.
For which scenario does SSE suit better than WebSocket?
Key Ideas
- **WebSocket** - a full-duplex protocol over TCP, starts with HTTP Upgrade (status 101)
- **Frames** - minimal overhead (2-14 bytes), masking is required for the client, types: text/binary/control
- **Alternatives** - SSE for one-way push, Socket.IO for abstraction, WebTransport for UDP-like in the browser
Related Topics
WebSocket builds on HTTP and is used in modern infrastructure:
- HTTP Basics — WebSocket starts with an HTTP Upgrade request
- Load Balancing — WebSocket connections require sticky sessions or special balancing
Вопросы для размышления
- Why does WebSocket use HTTP for the initial handshake rather than its own protocol?
- What problems arise when horizontally scaling WebSocket servers?
- In what case would you choose long polling over WebSocket?