How Does a WebSocket Connection Work? – Handshake and Frames
Learn how a WebSocket upgrades from HTTP, how frames and control messages work, how connections stay alive, and where the protocol fits.
A WebSocket is a persistent, bidirectional connection between client and server. It begins as an HTTP request and, once upgraded, carries messages in both directions with very little per-message overhead.
1. The Upgrade Handshake
GET /socket HTTP/1.1
Host: example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Version: 13
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
The 101 status is the moment HTTP semantics stop applying. The same TCP connection now carries WebSocket frames.
2. Why It Starts as HTTP
Beginning with an HTTP request means the connection passes through the existing web infrastructure — the same port, the same TLS, the same proxies and load balancers — rather than requiring a separate listener.
The accept header is derived from the client's key, which confirms the server genuinely understood the upgrade rather than echoing an ordinary response.
3. Frames
After the handshake, data travels in frames carrying a small header and a payload. Messages can be text or binary, and a large message may be split across several frames and reassembled.
Client-to-server frames are masked, a legacy protection against certain proxy-cache attacks, and libraries handle it transparently.
4. Control Frames
| Frame | Purpose |
|---|---|
| Ping | Check the peer is alive |
| Pong | Respond to a ping |
| Close | Begin an orderly shutdown with a status code |
Ping and pong matter operationally: intermediaries drop idle connections, and periodic pings keep them from being reaped.
5. Where It Fits
- Live updates — dashboards, notifications, collaborative editing.
- Chat and messaging.
- Streaming telemetry in either direction.
- Control protocols, including browser automation, which uses a WebSocket to carry JSON-RPC.
6. Compared With the Alternatives
| Approach | Direction | Overhead |
|---|---|---|
| Polling | Client asks repeatedly | High — a request per check |
| Long polling | Server holds a request open | Moderate |
| Server-sent events | Server to client only | Low, and HTTP all the way |
| WebSocket | Both directions | Lowest per message |
Where updates only flow one way, server-sent events are simpler and keep ordinary HTTP semantics. Bidirectional need is the reason to choose a WebSocket.
7. Operational Considerations
- Reconnection must be implemented; connections drop.
- State on reconnect — decide whether to resume or resynchronise.
- Backpressure — a slow consumer needs handling, or buffers grow.
- Scaling — connections are stateful, so load balancing must keep a client on one server or share state.
- Authentication happens during the handshake, since frames carry no headers.
8. Summary
A WebSocket upgrades an HTTP request into a persistent bidirectional channel carrying framed messages, with control frames for liveness and shutdown.
It suits genuinely two-way, low-latency communication. Reconnection, backpressure, and stateful scaling are the costs of that persistence, and one-way updates are usually better served by server-sent events.