Websocket
Prerequisites
What is $(topic) ?
Train of Thoughts
Questions ?
✅ Answer
Connection Establishment
A WebSocket connection begins as a standard HTTP/1.1 request that upgrades to the WebSocket protocol. For wss:// (secure) connections, the TLS handshake completes before the HTTP upgrade.
Client Handshake Request
The client sends an HTTP GET request with specific upgrade headers:
GET /chat HTTP/1.1
Host: server.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Origin: http://example.com
Sec-WebSocket-Protocol: chat, superchat
Sec-WebSocket-Version: 13
Required headers:
| Header | Purpose |
|---|---|
Host | Server hostname and optional port, enables virtual hosting |
Upgrade: websocket | Signals intent to switch from HTTP to WebSocket |
Connection: Upgrade | Tells intermediaries this is a protocol transition |
Sec-WebSocket-Key | Base64-encoded random 16-byte nonce, must be unique per connection |
Sec-WebSocket-Version: 13 | Protocol version (13 is the current and only stable version) |
Optional headers:
| Header | Purpose |
|---|---|
Origin | Origin of the requesting script, used for server-side access control (browser clients only) |
Sec-WebSocket-Protocol | Comma-separated list of desired subprotocols, ordered by preference |
Sec-WebSocket-Extensions | Requested extensions (e.g., permessage-deflate for compression) |
Server Handshake Response
If the server accepts the upgrade, it responds with:
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
Sec-WebSocket-Protocol: chat
Required headers:
| Header | Purpose |
|---|---|
Status 101 Switching Protocols | Confirms the protocol upgrade is accepted |
Upgrade: websocket | Echoes confirmation of the protocol switch |
Connection: Upgrade | Confirms the connection upgrade |
Sec-WebSocket-Accept | Proof the server understands WebSocket (see Magic GUID) |
Optional headers:
| Header | Purpose |
|---|---|
Sec-WebSocket-Protocol | The single subprotocol selected from the client's list |
Sec-WebSocket-Extensions | Extensions the server agrees to use |
Client Validation
Before considering the connection open, the client verifies:
- Status code is
101— any other code means the handshake failed UpgradeandConnectionheaders are present and correctSec-WebSocket-Acceptmatches the expected hash ofSec-WebSocket-Key+ magic GUID- No unrequested extensions or subprotocols appear in the response
Once validation passes, the connection transitions to the OPEN state and all subsequent traffic uses WebSocket binary framing.
Deep Dive
The Magic GUID
The WebSocket handshake in RFC 6455 relies on a hardcoded GUID: 258EAFA5-E914-47DA-95CA-C5AB0DC85B11. During the handshake, the client sends a random Sec-WebSocket-Key header. The server concatenates this key with the magic GUID, hashes the result with SHA-1, and returns the base64-encoded hash as Sec-WebSocket-Accept.
This GUID is not cryptographic and provides no security. Its sole purpose is to ensure the server actually implements the WebSocket protocol rather than being a plain HTTP server that accidentally returns 101 Switching Protocols to an Upgrade request it doesn't understand. A caching proxy or naive HTTP server would not know to perform this concatenation and hashing, so the client can detect when a response didn't come from a real WebSocket server.