Alternate paths: QUIC 0-RTT, WebSocket upgrade, connection migration

A mobile user on a train reports the site reloads every time the train goes through a tunnel. Meanwhile your WebSocket-based real-time dashboard drops messages silently when one client is slow to consume. Both problems have the same root cause: the transport was designed for stable connections, but reality is not stable. HTTP/3 and WebSocket handle this differently — and both fail in ways you must explicitly design for.

Path A: HTTP/3 over QUIC

Why QUIC instead of TCP. TCP multiplexes streams over one connection, but a single lost packet stalls the entire TCP receive window until retransmission. HTTP/2 over TCP has exactly this problem: one slow stream blocks all other streams on the same connection. QUIC implements streams as independent entities — a lost packet on stream A does not block streams B, C, or D. This stream independence is the primary win on lossy networks (mobile, intercontinental links).

Merged handshake. TCP requires a separate 3-way handshake (1 RTT) before TLS can begin (another 1 RTT minimum). QUIC merges them: the QUIC Initial packet carries the TLS ClientHello. Server responds in one packet with both QUIC transport parameters and TLS ServerHello. Total: 1 RTT for a new connection instead of 2.

0-RTT resumption. For warm connections (user returning to the same origin within the session ticket’s lifetime), the client sends application data inside the QUIC Initial packet — before the server has responded. Effective RTT for first byte: 0 additional round-trips. Constraint: 0-RTT is safe only for idempotent methods (GET, HEAD). POST/PUT requests must wait for the handshake to complete (server rejects 0-RTT for non-idempotent requests with 425 Too Early).

0-RTT max early data. Servers cap how many bytes of early data they accept (typical: 16–64 KB). If the HTTP request + headers exceed this, the rest is sent after the handshake. This cap prevents attackers from using 0-RTT to inject large payloads before authentication completes.

Connection migration (mobile networks)

When Bea’s phone switches from WiFi to cellular, her IP address changes. Under TCP+HTTP/2, the TCP 4-tuple (src IP, src port, dst IP, dst port) is part of the connection identity — an IP change breaks the connection. Bea must re-establish TCP + TLS + HTTP, paying full handshake cost.

Under QUIC, connections are identified by a Destination Connection ID — an opaque token Sven issued at handshake, chosen by Sven, carried in every QUIC packet header. Bea’s kernel sends a PATH_CHALLENGE frame from the new IP. Sven responds with PATH_RESPONSE using the same Connection ID, proving the IP change is legitimate (not an attacker spoofing Bea’s original IP). All in-flight streams continue on the new path. Migration costs one extra round-trip (~50 ms on a good network), but avoids re-establishing the entire connection.

Path B: WebSocket upgrade for real-time communication

HTTP is request-response — one request, one response. For real-time bidirectional communication (chat, collaborative editing, live dashboards), the client needs to receive messages from the server without issuing a new request for each. WebSocket solves this by upgrading an HTTP connection to a persistent full-duplex channel.

Upgrade handshake. The client sends:

GET /ws HTTP/1.1
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: <base64 random 16 bytes>

The server responds:

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: <HMAC of key + magic string>

After 101, the TCP connection is repurposed as a WebSocket. Both sides exchange frames asynchronously — no request-response ordering, no headers on each message.

Frame structure. Each WebSocket frame carries:

• FIN bit (1 = final fragment, 0 = more fragments follow)
• Opcode (1=text, 2=binary, 8=close, 9=ping, 10=pong)
• Masking (client→server mandatory, XOR with 4-byte masking key — cache poisoning defence)
• Payload length + payload

Large messages are fragmented across multiple frames (FIN=0 for fragments, FIN=1 for final fragment). The receiver buffers until FIN=1 before delivering to the application.

Ping/pong heartbeats. WebSocket does not have a built-in keepalive at the TCP level. After ~75 s without a frame, many network devices time out idle TCP connections. Solution: send ping frames every 15–30 s. The receiver replies pong. If no pong is received within the timeout, the connection is dead and should be reestablished.

Backpressure failure mode. If Bea’s application is slow to consume messages (e.g., heavy JavaScript processing per message), Sven’s send buffer fills. When Sven calls write() on the socket, the kernel returns WOULDBLOCK. Naive server code that spins on WOULDBLOCK spikes CPU; naive code that drops messages loses data. Correct pattern: Sven stops reading from Bea (pauses the inbound stream) until his outbound buffer drains. Proper WebSocket libraries implement this via async/await and stream backpressure APIs.