Unlock Real-Time Web Communication: A Deep Dive into WebSocket Handshake and Frame Structure

Overview

In the previous article we examined a simple HTTP request; this piece introduces the WebSocket protocol, focusing on its most essential aspects.

What is WebSocket

Background

Before WebSocket, web applications that required bidirectional communication relied on HTTP polling, which forced servers to maintain many separate connections and added high overhead due to extra headers.

WebSocket was created to solve these problems.

Definition

WebSocket is a protocol that provides full‑duplex communication over a single TCP connection, allowing the server to push data to the client.

After a single handshake, the browser and server establish a persistent connection for two‑way data transfer.

Basic Frame Structure Analysis

The following diagram (from RFC6455 §5.2) shows the WebSocket frame layout.

FIN (1 bit): indicates the final fragment of a message.

RSV1, RSV2, RSV3 (1 bit each): must be 0 unless an extension defines a meaning.

Opcode (4 bits): defines the frame type (e.g., %x0 continuation, %x1 text, %x2 binary, %x8 connection close, %x9 ping, %xA pong).

Mask (1 bit): when set to 1, a 32‑bit masking key is present and the payload is masked.

Payload length (7, 7+16, or 7+64 bits): length of the payload data in bytes.

Masking‑Key (0 or 4 bytes): present only if Mask is 1.

Payload data: the actual application data.

Why Masking?

Masking protects against early‑protocol attacks such as proxy cache poisoning, not against eavesdropping.

Packet Capture Analysis

Demo and Inspection

A simple demo was built to capture WebSocket traffic. The page offers connect/disconnect functions, sends a name, and the server replies with "Hello, <name>".

Handshake request:

<code>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</code>

Handshake response:

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

Key request fields:

Upgrade: upgrades HTTP to WebSocket.

Connection: Upgrade.

Sec-WebSocket-Key: used by the server to generate a unique accept key.

Sec-WebSocket-Version: protocol version.

Sec-WebSocket-Protocol: sub‑protocol negotiation.

Sec-WebSocket-Extensions: optional extensions.

Sec-WebSocket-Accept: server‑generated accept key.

Capture Steps

The demo performs the following actions:

Connect to WebSocket.

Send the text "LUOZHOU".

Disconnect.

Wireshark capture shows two HTTP requests before the WebSocket upgrade: an initial framework request and the actual handshake request (GET /gs-guide-websocket/690/.../websocket). The server responds with status 101, indicating the protocol switch.

Subsequent packets reveal that client‑to‑server frames are masked (opcode:1, masked), while server‑to‑client frames are not, confirming the masking rule.

Conclusion

WebSocket enables efficient bidirectional communication for web applications, reducing server load compared to polling.

Masking prevents early‑protocol attacks; only client‑to‑server frames are masked.

The Sec‑WebSocket‑Key is generated by concatenating client and server strings, applying SHA‑1, and Base64‑encoding the result.

The handshake relies on an HTTP 101 response to upgrade the protocol.