WebSocket (RFC 6455 Full-Duplex Real-Time Protocol)

WebSocket is a standardized communication protocol (RFC 6455) providing persistent, bidirectional, full-duplex transmission channels over a single TCP connection. Unlike standard HTTP request-response architectures where every exchange incurs connection establishment and header overhead, a WebSocket connection stays open continuously, allowing both client and server to push text or binary data frames with minimal latency.

Test endpoints, send live payloads, measure round-trip latency, and inspect frames in real time with our client-side WebSocket Tester tool.

---

Technical Specifications at a Glance

Property	WebSocket (RFC 6455)	HTTP REST (Request-Response)	Server-Sent Events (SSE)
Communication Flow	Bidirectional (Full-Duplex)	Unidirectional (Client Pull)	Unidirectional (Server Push)
Connection Lifecycle	Persistent TCP connection	Short-lived per request/stream	Persistent HTTP connection
Framing & Overhead	2–10 bytes framing header	500B–2KB HTTP headers/req	data: \n\n text line framing
Data Formats	UTF-8 Text (JSON) & Binary (Blob/ArrayBuffer)	Text (JSON/XML) or Binary	Strictly UTF-8 Text
Transport Security	ws:// (Plain TCP) / wss:// (TLS/SSL)	http:// / https://	http:// / https://
Primary Use Cases	Live chat, games, financial tickers, collaborative apps	CRUD APIs, static resources	LLM token streaming, live notifications

---

The Anatomy of the WebSocket Handshake

A WebSocket session begins as a standard HTTP/1.1 GET request with protocol upgrade headers:

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

If the server accepts the upgrade, it responds with status code 101 Switching Protocols:

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

Once the handshake completes, the underlying TCP socket remains open and switches from HTTP request-response parsing to WebSocket frame processing.

---

WebSocket Frame Structure & Wire Opcodes

Messages are split into one or more sequential frames structured with RFC 6455 framing bitfields:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-------+-+-------------+-------------------------------+
|F|R|R|R| opcode|M| Payload len |    Extended payload length    |
|I|S|S|S|  (4)  |A|     (7)     |             (16/64)           |
|N|V|V|V|       |S|             |   (if payload len==126/127)   |
| |1|2|3|       |K|             |                               |
+-+-+-+-+-------+-+-------------+ - - - - - - - - - - - - - - - +
|     Extended payload length continued, if payload len == 127  |
+ - - - - - - - - - - - - - - - +-------------------------------+
|                               |Masking-key, if MASK set to 1  |
+-------------------------------+-------------------------------+
| Masking-key (continued)       |          Payload Data         |
+-------------------------------- - - - - - - - - - - - - - - - +
:                     Payload Data continued ...                :
+---------------------------------------------------------------+

Key Protocol Opcodes

• 0x1 — Text Frame: UTF-8 encoded text payload (e.g. JSON strings).
• 0x2 — Binary Frame: Arbitrary raw binary data (e.g. Protocol Buffers, ArrayBuffers, audio streams).
• 0x8 — Connection Close: Initiates clean termination with a 16-bit status code and optional reason string.
• 0x9 — Ping: Heartbeat request frame used to keep TCP connections alive.
• 0xA — Pong: Heartbeat response frame automatically returned upon receiving a Ping.

---

Subprotocol Negotiation

The Sec-WebSocket-Protocol header allows the client and server to agree on an application-level message format during the initial handshake:

1. graphql-ws / graphql-transport-ws: The official standard for GraphQL subscriptions and live operations.
2. JSON-RPC 2.0: Stateless remote procedure call framing widely used in Web3/Ethereum node interactions and Language Server Protocols (LSP).
3. STOMP: Simple Text Oriented Messaging Protocol for enterprise message brokers like RabbitMQ and ActiveMQ.
4. WAMP: Web Application Messaging Protocol combining PubSub and Routed RPC.

---

Standard RFC 6455 Close Codes

When a WebSocket connection closes, the close event carries a 16-bit unsigned integer representing the termination cause:

Code	Name	Description
1000	Normal Closure	Purposeful session shutdown (e.g. user logged out or page closed).
1001	Going Away	Endpoint is terminating (e.g. server restart or client tab navigation).
1002	Protocol Error	Endpoint received a malformed frame violating RFC 6455.
1003	Unsupported Data	Received binary data when only text was negotiated, or vice-versa.
1006	Abnormal Closure	Connection dropped unexpectedly (TCP reset, TLS failure, or timeout without close frame).
1008	Policy Violation	Endpoint rejected the connection due to authentication or authorization failure.
1011	Internal Server Error	Server encountered an unhandled exception and terminated the connection.

---

Frequently Asked Questions

Why do cloud load balancers terminate idle WebSocket connections?

Intermediate proxies (such as AWS ALB, Cloudflare, Nginx, or Envoy) enforce default idle timeouts (typically 30–60 seconds). If no data frames travel across the connection during this window, the proxy silently tears down the TCP socket. Implement regular heartbeat pings (e.g. every 15–30 seconds) to maintain keep-alive status.

How do I handle authentication in browser WebSocket clients?

The browser's native WebSocket API does not permit adding custom HTTP headers (such as Authorization: Bearer <token>). Common industry solutions include:

1. Passing short-lived authentication tokens via URL query parameters (wss://api.example.com/ws?token=xyz).
2. Sending a dedicated authentication frame immediately after the onopen event (e.g. connection_init).
3. Using secure, HttpOnly, SameSite session cookies sent automatically during the initial upgrade handshake.

Can I test WebSocket servers locally without public exposure?

Yes. Because our WebSocket Tester runs directly inside your browser without passing traffic through external cloud servers, you can connect directly to ws://localhost:8080, ws://127.0.0.1:3000, or private intranet IPs.