WebSocket
ActiveWebSocket is a full-duplex communication protocol over a single persistent TCP connection. After an HTTP/1.1 upgrade handshake, either endpoint can send frames at any time without polling. WebSocket is the standard protocol for real-time web applications: chat, live dashboards, multiplayer games, financial tickers, and collaborative editing.
In one line
WebSocket (RFC 6455, 2011) establishes a persistent full-duplex channel over TCP via an HTTP Upgrade handshake. Once connected, either side sends frames without request-response overhead. Text frames carry UTF-8 data; binary frames carry raw bytes. WebSocket runs on port 80 (ws://) or port 443 (wss:// over TLS). Close frames carry a 2-byte code (1000–4999) to signal closure reason.
Quick Reference
| Field | Size | Description |
|---|---|---|
| Port | 80 / 443 | ws:// uses port 80 (unencrypted). wss:// uses port 443 (TLS). Same ports as HTTP/HTTPS. |
| Handshake | HTTP Upgrade | Client sends GET with Upgrade: websocket, Connection: Upgrade, and Sec-WebSocket-Key header. Server responds 101 Switching Protocols. |
| Frame types | 6 opcodes | 0x0=Continuation, 0x1=Text (UTF-8), 0x2=Binary, 0x8=Close, 0x9=Ping, 0xA=Pong. Text and Binary are the primary data frames. |
| Client masking | Required | RFC 6455 §5.3: all frames sent from client MUST be masked with a 32-bit XOR key. Server-to-client frames are never masked. |
| Max frame size | 2^63 bytes | Payload length in extended 64-bit form. Practical limits imposed by server configuration (typically 1 MB–16 MB). |
| Close codes | 1000–4999 | 1000=Normal, 1001=Going Away, 1002=Protocol Error, 1003=Unsupported Data, 1006=Abnormal Closure (local use only), 1011=Internal Error. |
| Keep-alive | Ping/Pong | Ping frame (0x9) sent by either side; receiver MUST respond with Pong (0xA). Used to detect half-open connections. Most servers send ping every 30–60 s. |
| Subprotocols | Sec-WebSocket-Protocol | Client proposes subprotocols (e.g., chat, json, mqtt) in handshake. Server selects one. Enables protocol multiplexing over a single WebSocket. |
Key Characteristics
Full-duplex
Either side sends frames at any time after the handshake. No request-response constraint. Server can push data without the client asking.
Low latency
No HTTP header overhead per message after connection establishment. A single TCP connection persists for the session lifetime.
Same-origin aware
The Origin header in the handshake lets servers enforce same-origin or CORS-equivalent policies. Servers SHOULD validate Origin against an allowlist.
Client masking
Clients must XOR-mask every frame with a random 32-bit key to prevent cache-poisoning attacks via transparent proxies. This is mandatory per RFC 6455.
Message Format
// WebSocket HTTP Upgrade Handshake
GET /chat HTTP/1.1
Host: ws.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Version: 13
Sec-WebSocket-Protocol: chat, json
Origin: https://example.com
// Server response
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
Sec-WebSocket-Protocol: chat// WebSocket frame structure (RFC 6455 §5.2)
// Byte 0: FIN(1) RSV1(1) RSV2(1) RSV3(1) Opcode(4)
// Byte 1: MASK(1) Payload len(7)
// [Extended len: 2 or 8 bytes if len=126 or 127]
// [Masking key: 4 bytes if MASK=1]
// [Payload data]
// Text frame "Hello" from client (masked)
81 85 37 fa 21 3d // FIN+Text, masked, len=5, masking key
7f 9f 4d 51 58 // "Hello" XOR masked
// Close frame 1000 Normal Closure
88 82 00 00 00 00 // FIN+Close, masked, len=2
03 e8 // Code 1000 = 0x03E8