From Handshake To Frames
A WebSocket starts as an HTTP request that asks to upgrade the connection. Once the server agrees, both sides drop the request response pattern and exchange frames freely in both directions.
Frame Anatomy
Each frame carries a small header followed by a payload.
- An opcode marks the frame as text, binary, close, ping, or pong.
- A bit marks whether this frame is the final piece of a message.
- A length field describes the payload size, which can be small or extended.
A long message can be split across several frames, with continuation frames following the first.
Masking
Frames sent from the client to the server are masked with a random key carried in the frame. The server unmasks them.
- Masking prevents certain proxy cache poisoning attacks.
- The key changes per frame so the bytes look random on the wire.
- Server to client frames are not masked.
Control Frames
Ping and pong frames keep a connection alive and check liveness. A close frame begins an orderly shutdown, optionally carrying a status code that explains why.
Key idea
A WebSocket upgrades from HTTP then exchanges opcode tagged frames in both directions, with client frames masked for safety and control frames managing liveness and close.