WebSocket: one upgraded connection, explicit recovery semantics

WebSocket is a framed, full-duplex protocol that begins with an opening handshake. In the common HTTP/1.1 mapping, the server returns 101 and the same underlying connection carries frames. TLS secures wss, while frame masking, authorization, liveness, replay, and reconnect remain separate concerns.

Mental model

• A reverse proxy terminates one client connection and dials an upstream; do not animate a client directly to a gateway behind the proxy.
• Client frames must be masked and server frames must not be masked. Masking protects intermediaries from chosen-byte attacks; it is not confidentiality.
• Ping/Pong tests application-protocol responsiveness but heartbeat intervals are deployment choices constrained by traffic, battery, and middleboxes.
• Reconnect creates a new transport and protocol session. Delivery recovery requires an application cursor, durable source, retention policy, and idempotent apply.

Гарантии и границы

• WebSocket preserves message framing over an ordered transport, including fragmentation rules.
• The protocol defines opening and closing handshakes plus control frames; it does not define business acknowledgements or replay.
• A successful send API call does not prove remote processing.
• A broker's durability and delivery contract are independent of the WebSocket connection.

Сценарии диаграммы

HTTP opening handshake through a proxy. The client establishes TLS for wss and negotiates WebSocket; a reverse proxy creates a separate upstream connection.

Full-duplex messages, ping, and close. Either endpoint can send after opening, but control-frame and close-handshake rules still apply.

Cross-gateway fan-out. Every gateway dials the broker; broker-to-gateway animations therefore traverse those dependencies in reverse.

Reconnect with bounded resynchronization. A dropped TCP connection loses in-flight state; reconnect is a new handshake and replay is an application protocol.

Архитектурные решения

• Use WebSocket when both peers need asynchronous messages and a long-lived connection is operationally acceptable.
• Authenticate at opening and authorize each channel or action; revalidate on reconnect and permission changes.
• Choose ephemeral fan-out only when loss is acceptable. Add a durable log and cursor when users require catch-up.

Сбои и неоднозначные исходы

• Half-open connections consume capacity until transport or application liveness detects them.
• Reconnect storms can overload authentication and gateways; use jitter, admission control, and progressive recovery.
• Sticky routing is an optimization, not durable ownership. Any healthy gateway must be able to reconstruct authorized state.

Операционный checklist

• Validate Origin where browser cross-site use matters and protect credentials from CSRF-like cross-site WebSocket hijacking.
• Bound frame and message size, compression ratio, connection count, subscriptions, and outbound queue.
• Define close codes, ping policy, slow-consumer handling, cursor retention, and snapshot fallback.
• Test proxy timeouts, rolling deploys, broker loss, gateway loss, and mass reconnect.

Связанная концепция

Первичные источники

1. https://www.rfc-editor.org/rfc/rfc6455.html
2. https://www.rfc-editor.org/rfc/rfc8441.html
3. https://www.rfc-editor.org/rfc/rfc8446.html