Connection Migration

A conventional TCP connection is identified by source address, source port, destination address and destination port. Change any of them — as happens when a device moves from WiFi to mobile, or when a carrier network reassigns an address — and the connection is dead. The application discovers this at some later timeout and starts again.

Connection migration means the session survives the change. There are two ways to achieve it, and the distinction matters.

At the transport. QUIC identifies connections by a connection ID rather than by the address tuple, so a path change carries the connection with it. No new handshake, no application involvement, no interruption.

At the application. The transport connection dies and the application reconstructs the session: a session identifier plus a sequence number, so reconnecting means "send me what I missed from position N" rather than "give me everything again". This is what long-lived messaging protocols implement, and it is available regardless of transport.

Why it matters

For mobile clients, network changes are routine rather than exceptional — a user walks out of WiFi range several times a day. Without migration, each one is a full reconnection: handshake, authentication, session re-establishment, full state fetch. That is expensive for the client, expensive for the server, and visible to the user as an interruption.

At fleet scale it is worse: a network event affecting many clients simultaneously produces a mass reconnection whose cost is several times the steady-state load, because a reconnect is far more expensive than a message.

Implementation patterns

• Session identity separate from connection identity, so the session outlives the socket.
• Sequence numbers on every message, so a gap is detectable and resumption is precise.
• A bounded server-side replay buffer, with a defined fall-back to full resynchronisation when the gap exceeds it. Bounded is essential — an unbounded buffer is a memory leak per disconnected client.
• Heartbeats in both directions, because a TCP connection can be dead for minutes with neither side noticing. Half-open connections are the characteristic silent failure of long-lived sessions.
• Server-enforced reconnect backoff with jitter, since client-side politeness is ignored by old and third-party clients.
• Admission control prioritising resumes over cold connects during a mass reconnection, because a resume is cheap and a cold connect is not.

Industry example

Short-video and streaming platforms adopted QUIC substantially for this property: a viewer moving from WiFi to mobile keeps playing rather than stalling while a new connection is established and the player rebuffers. On mobile-first platforms this is a directly measurable engagement effect, not a theoretical nicety.

Chat and collaboration platforms achieve the equivalent at the application layer, because their sessions carry state a transport cannot reconstruct. A client reconnecting after a tunnel or a lift sends its last sequence number and receives only the messages it missed. The same mechanism is what makes a rolling deployment survivable: the server tells clients to reconnect on a staggered schedule, and because resuming is cheap, the migration is nearly invisible.

That is the underrated benefit — cheap resumption turns both mass disconnection and routine deployment from incidents into non-events.

Failure scenarios

• Reconnection requiring a full state fetch, making every network blip expensive and every mass event a self-amplifying overload.
• Unbounded replay buffers, consuming memory for clients that never return.
• Migration without re-validating identity, which is a security hole: a connection that survives a path change must still be bound to an authenticated session.
• No heartbeats, so half-open connections accumulate and clients sit silently disconnected.
• All clients reconnecting immediately, because backoff was implemented only client-side.

Trade-offs

Transport-level migration requires QUIC, which brings its own costs — middlebox hostility, higher CPU, and load balancing that must route by connection ID rather than by address tuple. Application-level resumption requires protocol design, server-side buffering and careful gap handling.

Both are real investments, and both pay for themselves in any system with mobile clients or long-lived sessions, because they convert the most common disruption from an expensive event into a cheap one.

Interview question

"A user on your mobile app moves from WiFi to cellular mid-session. Walk me through what happens with a plain WebSocket over TCP, what changes with QUIC, and what you would implement at the application layer if you could not change transport."