What Happens During a WebSocket Handshake?

Think of a WebSocket Handshake as the moment two people agree to stop sending formal letters (HTTP) and just pick up the phone to talk in real-time. It's the bridge between the old-school request-response world and a modern, persistent connection.

Here's exactly how that "bridge" is built.

1. The Initial HTTP Request

The handshake always starts with the client (usually a browser) sending a standard HTTP GET request to the server. However, this isn't a normal request for a webpage; it includes specific "Upgrade" headers.

Key headers sent by the client:

• Upgrade: websocket: Tells the server the client wants to change protocols.
• Connection: Upgrade: Marks the connection as one that should be transformed.
• Sec-WebSocket-Key: A base64-encoded random value used to prove the server received the request.
• Sec-WebSocket-Version: Usually 13.

2. The Server's Decision

The server looks at those headers. If it supports WebSockets and agrees to the connection, it replies with an HTTP 101 Switching Protocols status code.

To prove it isn't just a random server, it performs a specific math trick:

1. It takes the Sec-WebSocket-Key from the client.
2. It appends a globally unique ID (GUID) string: 258EAFA5-E914-47DA-95CA-C5AB0DC85B11.
3. It hashes the result and sends it back as Sec-WebSocket-Accept.

3. Protocol Transition

Once the client receives that 101 status and verifies the key, the HTTP protocol is officially "shaken off."

The TCP/IP socket remains open, but the way data is framed changes entirely. Instead of headers and bodies, data is now sent in small frames that can travel both ways simultaneously (full-duplex).