The WebSocket Handshake

Analogy categoryAnalogies

Every WebSocket connection begins its life as an ordinary HTTP GET request carrying a few special headers: Upgrade: websocket, Connection: Upgrade, a Sec-WebSocket-Key, and a Sec-WebSocket-Version. If the server understands and accepts the request, it replies not with a normal 200 OK but with HTTP status 101 Switching Protocols, and from that point on the same TCP socket is reinterpreted using the WebSocket framing format instead of HTTP.

🏏

Cricket analogy: Like a player requesting to switch from batting gear to keeping gloves mid-innings — the umpire (server) must formally approve the change before play resumes under new rules.

The Client's Upgrade Request

The client's request includes a Sec-WebSocket-Key — a random, base64-encoded nonce that has nothing to do with authentication — plus a Sec-WebSocket-Version header set to 13, the current RFC 6455 version. It may also list one or more application-level Sec-WebSocket-Protocol values it's willing to speak, and it typically includes an Origin header indicating which page initiated the connection.

🏏

Cricket analogy: Like a team submitting a formal team sheet before the toss, listing the exact players (headers), a unique match reference number (the key nonce), and which competition rules apply (version).

text

GET /chat HTTP/1.1
Host: example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Version: 13
Sec-WebSocket-Protocol: chat, superchat
Origin: https://example.com

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
Sec-WebSocket-Protocol: chat

The Server's 101 Response

To prove it genuinely implements the WebSocket protocol rather than just echoing headers, the server must compute Sec-WebSocket-Accept by concatenating the client's Sec-WebSocket-Key with a fixed, RFC-defined GUID, hashing the result with SHA-1, and base64-encoding it. Once the client verifies this value matches its own computation, the handshake is complete and both sides begin exchanging data as WebSocket frames instead of HTTP messages.

🏏

Cricket analogy: Like the umpire cross-checking the team sheet against the official fixture list using a secret verification code only genuine match officials know, before formally declaring 'play has begun under Test match rules.'

The fixed GUID 258EAFA5-E914-47DA-95CA-C5AB0DC85B11, defined in RFC 6455, is concatenated with the client's Sec-WebSocket-Key, SHA-1 hashed, and base64-encoded to produce Sec-WebSocket-Accept. This proves the server genuinely understands the WebSocket protocol — a caching proxy that merely echoes headers back couldn't compute the correct value.

Subprotocols and Origin Checks

Sec-WebSocket-Protocol lets a client offer a list of application-level subprotocols it can speak — such as a custom chat format or a standard like graphql-ws — and the server picks and echoes back the one it will use. Because browsers do not enforce same-origin restrictions on WebSocket connections the way they do for fetch or XHR, servers must independently validate the Origin header to guard against unauthorized cross-origin connections, a class of attack known as cross-site WebSocket hijacking (CSWSH).

🏏

Cricket analogy: Like a franchise checking not just that a player showed up, but which specific playing contract (IPL vs domestic) governs them, while also verifying they actually belong to that franchise and aren't sneaking in from a rival team's dressing room.

Browsers do not apply the same-origin policy to WebSocket connections the way they do to fetch/XHR, so a malicious page can open a WebSocket to your server and the browser will happily send along the user's cookies. Servers must validate the Origin header and pair it with real authentication (tokens, SameSite cookies) to prevent cross-site WebSocket hijacking (CSWSH) — Origin alone isn't sufficient since non-browser clients can spoof it freely.

The WebSocket handshake begins as a normal HTTP GET request carrying Upgrade: websocket and Connection: Upgrade headers.
The client sends a random Sec-WebSocket-Key nonce and the protocol version (13) it supports.
The server proves it understands WebSockets by returning a correctly computed Sec-WebSocket-Accept header.
Sec-WebSocket-Accept is derived by hashing the client's key concatenated with a fixed RFC-defined GUID using SHA-1, then base64-encoding it.
A successful handshake response has HTTP status 101 Switching Protocols.
Sec-WebSocket-Protocol lets client and server negotiate an application-level subprotocol like graphql-ws.
Because browsers don't enforce same-origin restrictions on WebSockets, servers must validate Origin and use real authentication to prevent hijacking.