Http3 · XB Field Notes

HTTP3 rides UDP while HTTP2 stays safe over TCP

Sat, 12 Feb 2028 00:00:00 +0000

HTTP/3 runs QUIC over UDP:443, and the reason to care is what a lost packet costs. On a TCP connection every stream shares one byte stream, so a dropped segment blocks delivery of everything behind it until the retransmission arrives. QUIC gives each stream its own loss recovery, so the same drop blocks only the streams whose data was in that packet.

The awkward part is that this is not a flag you can turn on: the client must learn the server speaks HTTP/3 before it can try, and the path it learns that over is the one you were trying to improve.

Two transports, one port number

UDP:443 and TCP:443 are separate namespaces, so a single listener can hold both. That is why an nginx server block can carry listen 443 quic reuseport; next to listen 443 ssl; http2 on; and serve both on one port number. The reuseport matters more than it looks: without it, a second bind of UDP:443 fails with EADDRINUSE, which is the error you get when two server blocks both claim the QUIC listener.

QUIC is not HTTP/2 moved onto UDP. It folds the transport and TLS handshakes into one flight — one round trip, zero on a resumed session — and carries a connection ID independent of address and port. That ID is what makes connection migration possible, and it is also what breaks load balancers that assume a flow stays on one 5-tuple.

Alt-Svc is how the client finds out

The first connection to an origin is always over HTTP/2 on TCP, because the client has no idea yet. The response carries an advertisement: Alt-Svc: h3=":443"; ma=86400. Parsed, that is protocol h3, authority :443 and a freshness lifetime of 86400 seconds, or 24 hours. On the next connection to that origin the client tries QUIC first, so the upgrade lands on a subsequent visit and never on the first one.

ma is the part that bites. While the advertisement is fresh, the client tries HTTP/3 first on every new connection — including after HTTP/3 has failed repeatedly. Model UDP:443 silently dropped by a middlebox: the client burns 15 seconds in QUIC probe-timeout backoff (1, 2, 4 then 8 seconds) before falling back to HTTP/2. At 20 visits a day that is 300 wasted seconds daily until the cache expires a day later. Start the TCP connection in parallel instead of waiting for QUIC to give up, and the identical blocked path resolves in 0.1 seconds. The fallback penalty is a design choice, not a protocol cost.

0-RTT and migration are the two sharp edges

0-RTT lets a returning client send application data in the very first flight, using a ticket from the previous session. That data is replayable — anyone who captures the flight can send it again — so only requests that are safe to repeat belong in it. A “create order” call in 0-RTT is a duplicate order waiting for a reason.

Connection migration is the other edge. Because QUIC keys the connection on its connection ID rather than the address, a client that roams from Wi-Fi to cellular keeps the same connection. Put a load balancer that hashes the 5-tuple in front of that and the continued connection lands on a different backend: with eight backends, a model of the same client before and after roaming picks backend 7 and then backend 4. The protocol’s mobility becomes the load balancer’s problem.

When it breaks

The first failure is an Alt-Svc cached on the client while the network drops UDP. It presents as a slow first byte on every navigation for a whole day, with nothing unusual in the server log — the QUIC Initials never arrive, so there is nothing to log. Compare server-side HTTP/3 connection counts against client-perceived latency; a wide gap with a healthy h2 path is the signature. Shorten ma, race the TCP connection, and do not advertise h3 on paths you cannot verify.

The second failure is connection migration breaking session affinity. A mobile client changes address mid-session, HTTP/3 keeps the connection alive, and the backend that now owns it has none of the cache or session state the old one had. It presents as intermittent auth failures, cache misses and half-completed uploads, only ever on mobile clients, which is what makes it hard to reproduce. Route on connection ID, or pin affinity to something that survives the address change.

Check it quickly

Confirm both paths are actually alive:

curl -sI https://example.com/ | grep -i alt-svc
curl -s --http3-only -o /dev/null -w '%{http_version} %{time_appconnect}\n' https://example.com/
nginx -T 2>/dev/null | grep -nE 'listen .*quic|http3|Alt-Svc'
ss -lun | grep -E ':443\b'

The first should print an h3 advertisement with a bounded ma. The second prints 3 and a small connect time if UDP works, or fails outright if the path blocks it — a failure here while the first succeeds is the middlebox case. The third shows whether the config actually wires QUIC and the header together, and the fourth proves a UDP socket is bound on 443.

Sources

RFC 9114 HTTP/3, HTTP/3 semantics over QUIC, checked 2026-09-16.
RFC 7838 HTTP Alternative Services, the Alt-Svc header and its freshness lifetime, checked 2026-09-16.
ngx_http_v3_module, the nginx QUIC and HTTP/3 directives, checked 2026-09-16.
RFC 9000 QUIC, stream-level loss recovery, connection IDs and 0-RTT, checked 2026-09-16.

HTTP/3 and QUIC recover per stream

Sun, 21 Mar 2027 00:00:00 +0000

The next version of HTTP moves from TCP to QUIC, a transport with its own reliability built on UDP. The payoff is that packet loss on one stream no longer stalls the whole connection the way it can on TCP with HTTP/2.

Why TCP was the ceiling

HTTP/2 multiplexes many streams over one TCP connection, but TCP itself only knows a single ordered byte stream. When a packet is lost, TCP retransmits and requires in-order delivery, so every stream waiting on that connection halts until recovery completes. That is the head-of-line block HTTP/2 inherits from its transport. The fix is not more TCP tuning but a different transport: give each stream its own reliable, independently-ordered delivery, so a loss in one stream does not stall its neighbors. This is the specific ceiling HTTP/3 is built to remove.

QUIC changes the transport, not the semantics

HTTP/3 keeps the ideas HTTP/2 introduced, multiplexing, header compression, and stream priority, but runs them over QUIC, which lives on UDP and owns its own reliability. QUIC implements per-stream flow control and loss recovery, carries its own encryption, and can migrate a connection when the network path changes, all features TCP ties to the connection. From an application’s point of view the semantics barely change: same methods, headers, and status codes. What moves is the way the bytes are protected, and where connection repair can happen, which is what lets one lossy stream stop dragging the whole page.

When it matters most

Per-stream recovery pays for itself on lossy paths: poor mobile coverage, congested last-mile links, and lightly packet-lossy networks, exactly the places where a single stalling stream used to hold an entire page hostage. It is also a negotiated upgrade, enabled when both the client and server agree, and falling back to HTTP/2 without any action from the site operator where QUIC is unavailable. Rolling forward is therefore gradual and compatible; the deployment risk is low, and the benefit concentrates exactly where users feel it, on unreliable connections.

When it breaks

QUIC still rides on UDP, and some networks treat that as suspicious. Enterprise firewalls and older middleboxes may throttle or drop UDP, or pass small DNS-sized datagrams while discarding larger QUIC packets. The symptom is rarely a clean error. Alt-Svc advertises HTTP/3, the client attempts QUIC, and the handshake times out before falling back to HTTP/2 over TCP. If the fallback timer is too generous, users feel the upgrade as a regression, so track handshake success by network type and keep TCP ready.

0-RTT resumption is a second trap. Replaying the ClientHello saves a round trip, but anything accepted as early data can be replayed by an observer. RFC 9001 therefore limits early data to replay-safe operations. Sending a non-idempotent POST in 0-RTT risks executing the same order twice. Servers must reject risky early data or add anti-replay handling.

Connection migration has its own edge. QUIC identifies a connection by ID rather than the four-tuple, so a phone moving from Wi-Fi to cellular can continue without a new handshake. A NAT rebinding looks similar, however, and a stale NAT binding or a load balancer that hashes on addresses can send return packets nowhere. Endpoints must validate the new path before trusting it.

Finally, do not promise that QUIC removes every queue. It removes transport-level head-of-line blocking between streams, but connection-wide congestion control still applies. A saturated bottleneck delays all streams together. Per-stream recovery isolates loss, not overload.

Check it quickly

Save the following as quic_streams.py in a scratch directory and run python3 quic_streams.py. It models four streams of ten packets each with one packet lost on stream zero, then compares an idealized QUIC scheduler against an idealized TCP scheduler. No sockets are opened; the numbers are a scheduling calculation, not a wire capture.

STREAMS = 4
PACKETS = 10
LOST_STREAM = 0
RETRANSMIT_PENALTY = 3


def quic_completion():
 """Each stream recovers on its own: only the lossy stream pays."""
 completions = []
 for stream in range(STREAMS):
 if stream == LOST_STREAM:
 completions.append(PACKETS + RETRANSMIT_PENALTY)
 else:
 completions.append(PACKETS)
 return completions


def tcp_completion():
 """One ordered byte stream: a single loss blocks every stream."""
 blocked_at = PACKETS + RETRANSMIT_PENALTY
 return [blocked_at] * STREAMS


def main():
 quic = quic_completion()
 tcp = tcp_completion()
 # Only the stream that lost a packet waits for retransmission.
 assert quic[LOST_STREAM] == PACKETS + RETRANSMIT_PENALTY, quic
 assert all(t == PACKETS for i, t in enumerate(quic) if i != LOST_STREAM), quic
 # TCP cannot release later bytes until the loss is repaired.
 assert all(t == PACKETS + RETRANSMIT_PENALTY for t in tcp), tcp
 quic_blocked = sum(1 for t in quic if t > PACKETS)
 tcp_blocked = sum(1 for t in tcp if t > PACKETS)
 assert quic_blocked == 1, quic
 assert tcp_blocked == STREAMS, tcp
 print(f"QUIC completion: {quic} (blocked streams: {quic_blocked})")
 print(f"TCP completion: {tcp} (blocked streams: {tcp_blocked})")
 print("PASS: loss stalls one QUIC stream but all TCP streams")


if __name__ == "__main__":
 main()

The QUIC schedule completes the three healthy streams at time ten while only the lossy stream waits until time thirteen. The TCP schedule completes every stream at time thirteen because the single ordered byte stream cannot release later bytes until the loss is repaired. The script asserts that isolation, then prints both vectors. The model ignores congestion and reordering; it isolates loss recovery so the difference is visible in one run.

Sources

Cloudflare: HTTP/3 and QUIC, the protocol rationale, checked 2027-03-19.
RFC 9000: QUIC, the transport protocol, checked 2027-03-19.
RFC 9114: HTTP/3, HTTP over QUIC, checked 2027-03-19.

Http3 · XB Field Notes

HTTP3 rides UDP while HTTP2 stays safe over TCP

Two transports, one port number

Alt-Svc is how the client finds out

0-RTT and migration are the two sharp edges

When it breaks

Check it quickly

Sources

HTTP/3 and QUIC recover per stream

Why TCP was the ceiling

QUIC changes the transport, not the semantics

When it matters most

When it breaks

Check it quickly

Further reading

Sources