WebSocket handshake, framing, and connection lifecycle

WebSocket enables a client and server to exchange messages in both directions over one connection. RFC 6455 defines an HTTP/1.1 Upgrade handshake followed by frames over TCP. A browser sends an Origin value that a server can check, but Origin is not user authentication or authorization. Browser client frames are masked. Data frames carry text or binary messages, while control frames support operations such as ping, pong, and close. Frame boundaries are transport framing; they do not provide a durable application event log or replay cursor.

Expert perspective: persistent connections still disconnect

Cloudflare’s network documentation describes behavior on its own proxy and load-balancing products: idle WebSockets can be closed, and reconnecting clients may reach a different origin unless session affinity is configured. These are product-specific operational details, not universal WebSocket timeout values. RFC 6455 does not provide reconnection, message storage, or recovery. Deployments, mobile network changes, proxy idle policies, and server restarts can all end a connection. Heartbeats can help detect or prevent some idle closures, but do not guarantee a live path or message delivery. Configure them with both endpoint and intermediary policies in mind.

The protocol does not define application semantics

The protocol specifies framing, ping/pong control messages, and a closing handshake. It does not define business event schemas, durable ordering across reconnects, retries, deduplication, or authorization. TCP orders bytes within a live connection, but logical ordering after reconnect and duplicate prevention require application sequence identifiers and acknowledgements. If compression extensions are enabled, assess CPU and memory costs as well as compression-related risks. Bound message sizes and per-connection buffers, and define backpressure behavior when producers outpace consumers.

Security, scaling, and deployment checks

wss: protects transport with TLS; it does not replace message validation or per-action authorization. Servers should validate allowed browser origins and consider cross-site WebSocket hijacking when cookies authenticate a connection. Recheck identity, session expiry, and subscription permissions as needed. Long-lived connections are distributed when established, not independently load-balanced for each message. Capacity planning should include connections, file descriptors, memory, graceful draining, and reconnect storms. Cloudflare’s idle and affinity behavior applies to its own product path. Test the complete CDN/proxy/origin route for idle periods, ping/pong, large messages, backpressure, and reconnect after an origin restart.

References