Anyone who has taken a train from Leeds to London knows the feeling. The signal bars flicker, a page starts to load, you pass a cutting, and everything freezes mid-render. Then it lurches back. Some of that is just radio physics. But a decent chunk of it comes from an assumption baked into TCP decades ago: that a connection belongs to a fixed pair of IP addresses and ports. QUIC and HTTP/3 were designed to fix that, and mobile is where the difference shows most clearly.

QUIC in one paragraph

QUIC is a transport protocol that runs over UDP. It takes over the jobs that TCP and TLS used to split between them — reliable delivery, congestion control, encryption and multiplexed streams — and puts them in one place. HTTP/3 is not a rewrite of HTTP. It is the same requests and responses, carried over QUIC instead of TCP.

Two properties matter more than the rest. First, a QUIC connection carries many independent streams, and a lost packet only holds up the stream it belonged to. Second, encryption is not a separate negotiation bolted on afterwards: TLS 1.3 runs inside the handshake, so a new connection is typically ready in one round trip.

Why TCP struggles on a mobile link

Packet loss on a phone is normal. You walk behind a building, a cell hands you over to another mast, a carriage full of people saturates the local cell. Compared with a wired connection, the loss rate is high and the round-trip time is unpredictable.

With HTTP/2 over TCP, a single lost packet stalls every stream on that connection. TCP has no idea which stream the missing bytes belonged to, so it holds back all the data that arrived safely behind it until the gap is filled. That is why a page on a weak signal feels frozen rather than merely slow.

Connection setup is the other cost. TCP plus TLS 1.2 took several round trips before the first byte of a response. On a mobile network a round trip can easily be 50 milliseconds or more, and it is worse while the radio is waking up. HTTP/3 usually establishes a first connection in one round trip, and returning visitors can often use 0-RTT — sending request data alongside the handshake — though early data carries replay risks, so it belongs on safe, idempotent requests and not on anything that changes state.

Connection migration, and why it matters on the 17:40

In TCP, a connection is identified by four things: source IP, source port, destination IP, destination port. Change any one of them and the connection is dead. Your phone switching from office wi-fi to 5G changes the source address. So does a carrier rotating your IP. Everything built on that connection has to start again, handshakes included.

QUIC replaces the four-tuple with a connection ID that both endpoints agree on and that travels in every packet. If your address changes mid-download, the server can keep sending on the same logical connection. The keys stay valid, the congestion window is not reset to zero, and the transfer carries on.

It is not unconditional. Both ends have to support it, the new path is validated before the sender commits at full rate, and a server can decline to migrate if it does not recognise the connection ID. But when it works, the effects are visible:

• A video call that survives walking out of the house and onto mobile data.
• A large download that resumes instead of restarting after a network switch.
• A form submission or file upload that is not lost when the phone hops between masts.
• Shorter recovery after a lift, a tunnel, or a dead spot on the line to Crewe.

Where you will actually notice the latency win

HTTP/3 is not automatically faster on a fast, stable connection. On good broadband the difference between HTTP/2 and HTTP/3 is often small, and under some conditions HTTP/3 is slightly slower because QUIC's encryption runs in userspace and can cost more CPU per byte.

The gains appear when conditions are poor: loss, high round-trip times and network changes — which describes a lot of UK mobile traffic outside city centres. Concretely, users tend to see:

• Fewer stalls during page load when the signal dips, because loss on one stream no longer blocks the others.
• Faster cold connections, thanks to fewer round trips before the first response byte.
• Much less pain when the phone changes network mid-request.
• Better performance on rural and in-transit connections, where round-trip times are high and variable.

Turning it on in your own stack

For most teams this is configuration work rather than a rewrite. A sensible order:

1. Check your edge. If you sit behind a CDN or managed load balancer, HTTP/3 is usually one toggle. Look for it in the settings before planning anything custom.
2. Open UDP 443 everywhere. This is the most common reason HTTP/3 silently fails. Firewalls, security groups, WAFs and on-prem appliances often allow TCP 443 and block UDP by default.
3. Advertise it properly. Servers tell clients to upgrade with an Alt-Svc header pointing at the QUIC endpoint. Managed platforms handle this for you; if you run your own, set it and confirm in a browser's network panel.
4. Keep HTTP/2 and HTTP/1.1 fallbacks in place. Plenty of corporate networks and hotel wi-fi still block UDP, and those clients need a route that works.
5. Check your load balancing. A layer-4 balancer that hashes on IP and port can misroute migrated connections. Prefer connection-ID-aware balancing, or accept that migration will sometimes break at the balancer.
6. Measure by protocol. Split real-user monitoring dashboards by HTTP version and connection type. Aggregate numbers will hide the mobile improvements you are looking for.

Common snags

Early data is the one to watch. If you accept 0-RTT requests, decide deliberately which endpoints get that treatment, because a replayed request can be processed twice. Do not enable it for anything with side effects. Beyond that, expect some CPU overhead per connection, and test it if your servers already run hot.

A small, measurable rollout

Enable HTTP/3 on one subdomain or in staging, keep every fallback switched on, and compare mobile sessions against desktop ones. Look at time to first byte, load-completion times and, most importantly, stall or abandonment rates on 4G and 5G traffic. If the numbers hold up on the train, roll it out across the rest of the estate.

You do not need to rewrite your application. You do need to make sure a UDP packet can actually get through.

Photo: Sahil Padashala / Pexels