The WebSocket Handshake
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).
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: chatThe 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.
Practice what you learned
1. What HTTP status code indicates a successful WebSocket handshake?
2. What is the purpose of the Sec-WebSocket-Key header sent by the client?
3. How is Sec-WebSocket-Accept computed?
4. What is the purpose of the Sec-WebSocket-Protocol header?
5. Why can't the Origin header alone be trusted to secure a WebSocket server?
Was this page helpful?
You May Also Like
What Are WebSockets?
An introduction to the WebSocket protocol, a persistent, full-duplex communication channel over a single TCP connection used for real-time web applications.
WebSocket Frames Explained
A look under the hood at how WebSocket messages are broken into binary frames, including opcodes, masking, fragmentation, and control frames.
WebSockets vs HTTP Polling
A comparison of WebSockets against short and long HTTP polling techniques for achieving near-real-time updates in web applications.
Related Reading
Related Study Notes in Web Development
Browse all study notesWebAssembly Study Notes
WebAssembly · 30 topics
Web DevelopmentgRPC Study Notes
Protocol Buffers · 30 topics
Web DevelopmentSpring Boot Study Notes
Java · 30 topics
Web DevelopmentFlask Study Notes
Python · 30 topics
Web DevelopmentDjango Study Notes
Python · 30 topics
Web DevelopmentNext.js Study Notes
JavaScript · 30 topics