How does the WebSocket handshake and protocol upgrade work?
Learn how the WebSocket handshake works, from the HTTP Upgrade request and Sec-WebSocket-Key to the 101 response and full-duplex framed messaging.
Expected Interview Answer
A WebSocket connection starts as a normal HTTP GET request carrying an Upgrade: websocket header and a random Sec-WebSocket-Key; if the server agrees it replies with 101 Switching Protocols and a computed Sec-WebSocket-Accept, after which the same TCP connection speaks the WebSocket protocol.
The client generates a base64 Sec-WebSocket-Key nonce. The server concatenates it with a fixed GUID, SHA-1 hashes it, base64-encodes the result, and returns it as Sec-WebSocket-Accept, proving it understood the handshake. Once the 101 response is sent, no more HTTP semantics apply; both sides exchange framed, optionally masked messages full-duplex over the persistent connection.
- Reuses existing HTTP ports 80 and 443 and infrastructure
- Sec-WebSocket-Accept proves a genuine WebSocket server
- Cleanly upgrades one connection without a new socket
- Allows subprotocol and extension negotiation
- Works through many proxies that already understand HTTP
AI Mentor Explanation
The handshake is like a substitute fielder showing the umpire a signed authorisation card at the boundary rope before entering play. The umpire checks the signature matches the official register, gives a nod, and only then does the player cross onto the field, after which normal cricket, not paperwork, governs everything that follows.
Step-by-Step Explanation
Step 1
Client sends upgrade request
The browser sends an HTTP GET with Upgrade: websocket, Connection: Upgrade, and a random Sec-WebSocket-Key.
Step 2
Server computes accept value
The server appends the fixed GUID to the key, SHA-1 hashes it, and base64-encodes it into Sec-WebSocket-Accept.
Step 3
Server replies 101
It returns 101 Switching Protocols with the Accept header, and optionally a chosen subprotocol and extensions.
Step 4
Connection is upgraded
The same TCP connection now speaks WebSocket; HTTP request-response semantics no longer apply.
Step 5
Framed messages flow
Both sides exchange framed messages full-duplex, with client-to-server frames masked for safety.
What Interviewer Expects
- Knowing the handshake starts as HTTP GET with Upgrade
- Explaining Sec-WebSocket-Key and Sec-WebSocket-Accept
- The fixed GUID plus SHA-1 plus base64 computation
- The 101 Switching Protocols response
- Awareness of frame masking and subprotocol negotiation
Common Mistakes
- Thinking WebSockets use a brand new non-HTTP port
- Forgetting the 101 status code
- Not knowing Sec-WebSocket-Accept is computed, not echoed
- Ignoring client-to-server frame masking
- Assuming HTTP semantics continue after upgrade
Best Answer (HR Friendly)
“A WebSocket connection begins as an ordinary web request that politely asks to be upgraded. The server checks a security code, agrees with a special response, and from then on the same connection stays open for instant two-way messaging.”
Code Example
GET /chat 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=Follow-up Questions
- How is Sec-WebSocket-Accept calculated on the server?
- Why are client-to-server frames masked?
- What is Sec-WebSocket-Protocol used for?
- How do ping and pong frames keep a connection alive?
- How does wss differ from ws at the transport level?
MCQ Practice
1. Which HTTP status code signals a successful WebSocket upgrade?
The server replies with 101 Switching Protocols to confirm the connection has switched to the WebSocket protocol.
2. How does the server produce Sec-WebSocket-Accept?
The server concatenates the client key with a fixed GUID, SHA-1 hashes it, and base64-encodes the result.
3. After the upgrade, how are client-to-server frames sent?
The protocol requires client-to-server frames to be masked to mitigate certain proxy and cache-poisoning attacks.
Flash Cards
How does a WebSocket handshake start? — As an HTTP GET with Upgrade: websocket, Connection: Upgrade, and a Sec-WebSocket-Key.
What status confirms the upgrade? — 101 Switching Protocols, sent by the server.
How is Sec-WebSocket-Accept computed? — Client key concatenated with a fixed GUID, SHA-1 hashed, then base64-encoded.
Why mask client frames? — Masking client-to-server frames mitigates proxy cache-poisoning and injection attacks.