TCP vs QUIC: concise scene-by-scene tradeoffs for mobile clients

Handset roam

Change of IP while keeping same device / app flow.

Cell → Wi‑Fi switch

New uplink path and NAT characteristics during an active session.

NAT rebinding

Source port or public IP changes but server remains unchanged.

Symmetric NAT fallback

Server sees unpredictable client 4‑tuple changes, forcing connection restart.

Decisive axis: TCP binds identity to transport endpoints (4‑tuple); QUIC binds identity to cryptographic connection state and connection IDs, enabling greater path flexibility.

1. Handshake and identity

Scene: a mobile client initiates a new session from a variable network. The differences that matter for observability and resumption are whether encryption is integrated into the transport and how identity is negotiated.

TCP	QUIC
TCP Connection established by TCP handshake; TLS is layered above (separate crypto handshake). Server and middleboxes see TCP SYN/SYN-ACK. Resumption uses TLS session mechanisms.	QUIC QUIC uses UDP with integrated TLS 1.3 semantics inside its handshake; the transport and crypto are coupled. The handshake supplies connection identifiers used for migration and resumption options such as 0‑RTT at the application level.

Indicator: Look for separate TCP SYN / TLS ServerHello vs a clear QUIC Initial packet carrying encrypted frames and TLS handshake info.
Resumption: TLS resumption on TCP may be visible as a shortened TLS exchange; QUIC resumption uses state tied to the connection ID and integrated crypto.

2. Connection mobility and state migration

Scene: the client's network path changes mid‑session. The key distinction is how connection identity survives changes that alter the 4‑tuple (src/dst IP and ports).

TCP	QUIC
TCP Connection identity is the 4‑tuple at IP/TCP. Changing source IP or port generally causes endpoints or middleboxes to treat traffic as a new connection unless proxies preserve state.	QUIC Connection IDs decouple cryptographic identity from the underlying 4‑tuple; a server that recognizes a connection ID can accept packets from a new path and continue the connection, subject to implementation policy and connection ID lifetime.

Server view: Did the server observe a new source port or new IP? A new 4‑tuple often maps to a new TCP socket; a QUIC server can continue if it receives valid frames for a known connection ID.
Client view: QUIC clients typically attempt migration by sending packets with the same connection ID; TCP clients must re‑establish or rely on NAT/proxy continuity.

3. Failure modes, recovery, and middlebox interaction

Scene: a path breaks or a NAT behavior changes. Observable signs differ: TCP exposes TCP resets, half-closed flows, and visible SYN retries; QUIC hides handshake internals inside encrypted frames and uses transport-level probes and connection IDs to recover.

TCP	QUIC
TCP Server may see an RST or timeouts on a socket; middleboxes may drop or translate TCP state. Failure often appears as socket closure or repeated SYNs from the client.	QUIC Failures often show as lost packets or unexplained silence from the client; recovery uses retransmission and connection ID re‑use or allocation. Middleboxes that inspect UDP or limit NAT mappings can prevent recovery, leading to visible connection migration failures.

Signals: Look for RST/ICMP vsQUIC Retry or absence of decrypted frames. QUIC hides TLS inside encrypted packets, so error details are less discoverable at the network layer.
Recovery: TCP restarts the 3‑way handshake; QUIC can continue when the server accepts packets for the same connection ID or may require application-level re‑establishment.

Interpretive questions (diagnostic prompts)

Did the server observe a new source IP or port for the same application flow? If yes, check whether server logs correlate that with a new socket or a saved connection ID.
Is there evidence of TCP RSTs, repeated SYNs, or ICMP messages? These point to TCP-level socket resets or middlebox interference rather than QUIC-level migration issues.
Did the client attempt 0‑RTT or fast resumption (shortened handshake)? A failed resumption often produces cryptographic retries or silent packet drops visible only as resumed‑handshake events in QUIC logs.

Field-note prompt

Practical conceptual next steps: record whether the server saw a new 4‑tuple or recognized a connection ID; capture whether the failure presented as a TCP reset, a crypto retry, or a silent stall; and map those observations to the transport tradeoffs below. Mnemonic to copy to notes: 4‑tuple→TCP | connID→QUIC.