WebSocket Connection Workbench

Trace the HTTP upgrade, frame flow, heartbeat risk, close behavior, and reconnection decisions behind browser-to-IoT WebSocket links

animation
websocket
protocols
real-time
iot
Learner-ready WebSocket connection workbench with HTTP Upgrade and RFC 8441 scenarios, frame-field inspector, client masking notes, heartbeat and idle-timeout diagnosis, close/reconnect feedback, quick reference, guided practice, and primary source links.
HTTP Upgrade Full-duplex frames Browser IoT link

WebSocket Connection Workbench

WebSocket starts as an HTTP request, upgrades to a persistent message channel, and then moves small frames in both directions over one connection. Use this workbench to see what changes at each state and where browser IoT dashboards usually fail: idle paths, missed heartbeats, close handling, and reconnection.

Opening signalHTTP/1.1 101 Switching Protocols
Browser API states0 connecting, 1 open, 2 closing, 3 closed
Client frame ruleBrowser frames to the server are masked
IoT fitDashboards, control panels, live telemetry
Beginner ramp

What to notice first

Start with the scenario buttons, then step through the exchange. The scene, stage cards, frame fields, and diagnosis cards all update together.

It is not repeated HTTP polling

After the upgrade, either endpoint can send messages without waiting for a new browser request.

The browser hides some wire details

JavaScript gets `open`, `message`, `error`, and `close` events. It does not expose raw protocol Ping/Pong controls.

Small frames still have rules

Text and binary frames carry application data. Ping, pong, and close are control frames with stricter size and fragmentation rules.

Failure is often silent first

NATs, proxies, mobile network changes, or server restarts can leave a connection looking idle until a heartbeat or write detects the problem.

Interactive workbench

Trace the connection and the current frame

Use Play or Step to move through the current scenario. Adjust payload size and heartbeat timing to see the frame overhead and connection health change.

HTTP upgrade request

The browser asks the server to switch this HTTP connection to WebSocket.

CONNECTING = 0
WebSocket message flow A browser, network path, and IoT application server with the active WebSocket stage highlighted. Browser WebSocket API Network path proxy / NAT / TLS IoT server app endpoint GET /telemetry Upgrade: websocket Sec-WebSocket-Key and Version 13 are sent in the request. readyState: CONNECTING idle path is healthy upgrade validator
FIN1

Single unfragmented message in this teaching model.

Opcode0x1 text

Application text payload.

MASK1 + key

Client-to-server browser frames are masked.

Length field7-bit

Payload length fits in the base field.

Header bytes6 B

2 base + 4 masking-key bytes.

Total frame70 B

Header plus selected payload size.

Protocol checks

Use these facts to read the animation accurately

The model keeps the learner-facing numbers simple, but the labels follow RFC 6455 and the browser WebSocket API.

Opening handshake
GET + Upgrade: websocket + Sec-WebSocket-Key -> 101 + Sec-WebSocket-Accept
For HTTP/1.1, the server accepts the upgrade with status 101. The key/accept pair proves this is a WebSocket handshake, not authentication.
Frame overhead
header = 2 + extended-length bytes + masking-key bytes
Server frames can be 2, 4, or 10 header bytes before payload. Client frames include a 4-byte masking key, so the comparable browser-to-server sizes are 6, 8, or 14 bytes.
Heartbeat
healthy if heartbeat interval is safely below the path idle timeout
RFC Ping/Pong frames exist, but browser JavaScript does not expose a ping method. Browser apps commonly send application-level heartbeat messages.
Close behavior
normal close: opcode 0x8 + code 1000; abnormal close: no close frame received
Close code 1006 is reserved for local reporting of an abnormal closure and is not sent as a Close frame on the wire.
Quick reference

What to remember after the animation

Ready states

0 CONNECTING, 1 OPEN, 2 CLOSING, and 3 CLOSED are the browser API states. They describe the JavaScript object, not every TCP/TLS detail.

Data opcodes

0x1 carries UTF-8 text. 0x2 carries binary data. Continuation frames use 0x0 when a message is fragmented.

Control opcodes

0x8 closes, 0x9 pings, and 0xA pongs. Control frames are short and must not be fragmented.

Protocol choice

WebSocket is strong for browser dashboards and live control. Constrained devices often use MQTT, CoAP, or another IoT-specific protocol behind the gateway.

Guided practice

Try these checks

1. Spot the upgrade

Run Clean upgrade and step to stage 2. Which response code confirms the switch from HTTP request/response to WebSocket frames?

2. Compare direction

Set frame direction to server -> client. What happens to the MASK field and why is it different from browser-to-server traffic?

3. Break the idle path

Run Idle timeout, then lower the path idle timeout or raise the heartbeat interval. Which diagnosis card changes first?

4. Avoid retry storms

Raise the reconnect attempt number. Why should a fleet add jitter and a maximum delay instead of reconnecting every device immediately?

Deeper material: browser API versus wire protocol

The browser WebSocket constructor gives scripts a message-oriented API. Scripts send strings, Blobs, ArrayBuffers, or typed arrays and receive events. They do not build raw RFC frames directly. The browser implementation handles client masking, UTF-8 validation for text messages, fragmentation, TLS integration for `wss://`, and protocol-level responses such as Pong to an incoming Ping.

  • Use `wss://` for production browser dashboards unless the link is inside a deliberately controlled local lab.
  • Use the `Sec-WebSocket-Protocol` header only when client and server agree on an application subprotocol such as MQTT or a custom JSON protocol.
  • Do not treat `Sec-WebSocket-Key` as a secret. Authentication belongs in cookies, tokens, mTLS, or an application-level challenge tied to the WebSocket session.
  • Plan reconnection as application behavior. The browser API does not automatically reconnect a closed WebSocket.
Primary sources

Where the protocol details come from

RFC 6455

The WebSocket Protocol: HTTP/1.1 opening handshake, frame format, masking, opcodes, close behavior, and security considerations.

WHATWG WebSockets Standard

The browser-facing WebSocket API, ready states, events, and integration with the web platform.

RFC 8441

Bootstrapping WebSockets with HTTP/2 using extended CONNECT and the `:protocol` pseudo-header.

IANA WebSocket registries

Registered close codes, opcodes, extension names, and subprotocol names.
Related animations

Build the surrounding mental model

HTTP request/response TCP handshake TLS/DTLS handshake Protocol scenario selector