Http2 · 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.

gRPC multiplexes many streams over one HTTP/2 connection

Sat, 16 Jan 2027 00:00:00 +0000

Multiplexing shares the transport and keeps ordering within each stream, which is why long-lived pushes fit this model better than request-reply websockets.

One connection, many streams

HTTP/2 multiplexes many logical streams over a single TCP connection, and gRPC makes each call a stream, so a chatty microservice stops reopening sockets per request. That one shared connection means connection setup, TLS handshake, and idle bookkeeping happen once instead of per call. Streams are independent in ordering and cancellation, so a slow, long-lived stream does not block a short one on the same pipe. The practical effect is a low army of connection state, with per-call overhead shrinking to a frame header.

Streaming beats HTTP/1.1 fan-out

Because gRPC is streaming in both directions, a server can begin sending a partial result before the client finishes sending the request, and a client can keep pushing frames over the same call. That fits search, large-file streaming, log shipping, and interactive feeds where a single reply would force the whole payload to buffer first. It also makes fan-out cheaper than HTTP/1.1, where a burst of calls would each need its own connection and its own handshake. Everything that needs a back-and-forth loop maps naturally onto one long-lived stream instead of a series of separate requests.

The elegance of sharing one connection is real, but it is still bounded by the transport. A retry requires a new stream, not a replay on the same one, and backpressure still matters, since a slow consumer can stall the shared connection for everyone else. Deadlines therefore cut across the whole pipe, so one hair-loss deadline on a stream can surface as latency for every stream on that connection. The practical habit is to give each call a real deadline and a way to cancel, rather than letting the shared pipe silently donate time to someone else’s stuck call.

When it breaks

A stalled flow-control window looks like a healthy connection with zero throughput. HTTP/2 keeps a stream-level and a connection-level window, and only the receiver advances them with WINDOW_UPDATE. A slow consumer first parks its own stream; once the connection window fills, every stream behind it stalls too. Separate the two signals in dashboards, and give each RPC a bounded buffer and a consumer timeout.

Oversize metadata fails fast and retries cannot help. gRPC sends initial metadata as HTTP/2 headers with caps near eight kilobytes. An auth token plus tracing baggage plus tenant tags can cross the limit, and the call dies with RESOURCE_EXHAUSTED before business logic runs. Keep metadata small, move correlation blobs out of band, and remember binary metadata pays base64 inflation.

Long-lived connections defeat naive balancing. Clients that each hold one multiplexed connection pin all streams to the backend chosen at dial time, leaving new pods idle while old ones saturate. Fix it with client-side balancing or proxyless xDS, periodic MaxConnAge reconnects, and a cap on concurrent streams per connection.

Lost deadline propagation turns one slow leaf into whole-tree latency. gRPC carries the budget as grpc-timeout, but a gateway that fans out with a fresh timeout or a background context silently drops it. Derive downstream calls from the incoming context, keep each attempt shorter than the end-to-end deadline, and cancel siblings after the first failure.

Check it quickly

Save the following as mux_sim.py and run python3 mux_sim.py. It uses only the standard library to model one connection carrying three logical streams as interleaved frames. Stream 2 sends one frame and then stalls to simulate an exhausted window, while the scheduler must finish streams 1 and 3. Assertions check per-stream order and wire interleaving.

from collections import deque

# One shared connection, three logical streams. Each stream is an
# ordered queue of application messages; the wire is a single log of
# interleaved (stream_id, payload) frames.
streams = {
 1: deque(["a1", "a2", "a3"]),
 2: deque(["b1", "b2", "b3"]),
 3: deque(["c1", "c2"]),
}
stalled = set() # streams whose flow-control window is exhausted
wire = [] # shared transport log
delivered = {sid: [] for sid in streams}


def pump():
 """One round-robin pass: each ready stream emits at most one frame."""
 progressed = False
 for sid in sorted(streams):
 if sid in stalled:
 continue
 if streams[sid]:
 payload = streams[sid].popleft()
 wire.append((sid, payload))
 delivered[sid].append(payload)
 progressed = True
 return progressed


def drain():
 while pump():
 pass


# Round one: every stream places its opening frame on the wire.
assert pump() is True
assert wire == [(1, "a1"), (2, "b1"), (3, "c1")], wire

# Stream 2 exhausts its window and stops sending WINDOW_UPDATE.
stalled.add(2)
drain()

# Siblings must complete while stream 2 is stuck on one frame.
assert delivered[1] == ["a1", "a2", "a3"], delivered[1]
assert delivered[3] == ["c1", "c2"], delivered[3]
assert delivered[2] == ["b1"], delivered[2]
assert len(wire) == 6, wire
assert list(streams[2]) == ["b2", "b3"]

# The window reopens: stream 2 resumes on the same connection.
stalled.discard(2)
drain()

assert delivered[2] == ["b1", "b2", "b3"], delivered[2]
for sid, items in delivered.items():
 assert items == sorted(items), (sid, items) # per-stream order preserved
assert len(wire) == 8, wire
assert all(not q for q in streams.values())

print("wire:", wire)
print("PASS: 3 streams, 8 frames, one shared wire; stall of stream 2 did not block 1 and 3")

The script pumps one round so each stream places its opening frame, then stalls stream 2. The next drain must complete streams 1 and 3 while stream 2 stays at one frame, proving one blocked stream does not block its siblings. Reopening the window drains the rest, and the final check confirms in-order arrival on one log. This models scheduling only, without HPACK, TLS, or real flow-control bytes, so confirm window and deadline behavior on a gRPC stack before tuning production.

Sources

gRPC core concepts, defines streams over HTTP/2, checked 2026-06-01.
RFC 9113: HTTP/2, streams, multiplexing, and flow control, checked 2026-09-09.

HTTP/2 multiplexing fixes a queue

Sat, 16 Jan 2027 00:00:00 +0000

HTTP/2 removes HTTP response-order constraints by multiplexing streams, but those streams still share a TCP connection and its failure modes. One useful boundary is cancellation: terminating a request need not destroy its sibling requests or the reusable connection. That is a scoped capability, not a guarantee that streams never affect each other.

A stream is not the socket

HTTP/2 identifies individual streams within the connection. RFC 9113 defines RST_STREAM to terminate one stream, either for cancellation or because of a stream error. It is not a TCP reset of the whole socket. An implementation can stop one exchange while other streams continue, provided the connection itself remains usable.

This differs from HTTP/1.1 persistence, which already allows multiple exchanges on a connection. HTTP/2 adds interleaving and stream-specific lifecycle control; it does not invent connection reuse. Shared TCP ordering, congestion, connection-level DATA flow control, and server resources still bound progress. A connection failure can disrupt several requests together even when a request-scoped cancellation does not.

Cancellation also does not reverse completed work. The server might already have committed a transaction or called another service. A canceled client read cannot establish whether that operation happened. Retry decisions therefore still need application semantics, idempotency guarantees, or a way to inspect the outcome.

Headers are not a completed response

A successful response status precedes the body. A server can send and flush HTTP 200, then wait indefinitely or fail while sending content. Treat status, body completion, and business outcome as separate observations. A request is not successfully consumed merely because Client.Do returned a response object.

In Go, the outgoing request context controls cancellation. For an incoming HTTP/2 request, cancellation can cancel the server’s request context without closing the entire connection. Handlers must observe that context when waiting or calling dependencies; the runtime cannot automatically undo arbitrary application work. Client.Timeout also covers body reading after headers arrive.

When it breaks

Canceling a shared parent context can intentionally stop several requests. Closing the underlying connection also has broader scope than canceling one request. Choose request-owned cancellation for request-owned deadlines; do not impose a socket-wide deadline and describe its effect as isolated to one HTTP/2 stream.

Abandoned bodies can retain resources or consume flow-control credit. Read responses to completion when appropriate, and close every body when finished or canceled. Library-specific buffering and window updates determine whether unread data impedes siblings. Stream limits, connection credit, and backend capacity remain relevant; successful cancellation in a tiny fixture does not establish behavior under saturation.

Check it quickly

Save this as cancel_probe.go and run go run cancel_probe.go with Go 1.23 or newer. A local server negotiates HTTP/2 over verified TLS 1.3. Two handlers flush 200 headers before withholding their bodies. The client then cancels the first request, while the sibling remains open on the same numbered TCP connection.

package main

import (
 "context"
 "crypto/tls"
 "errors"
 "fmt"
 "io"
 "net"
 "net/http"
 "net/http/httptest"
 "net/http/httptrace"
 "runtime"
 "sync/atomic"
 "time"
)

type connectionKey struct{}

func must(err error) {
 if err != nil {
 panic(err)
 }
}

func check(ok bool, message string) {
 if !ok {
 panic(message)
 }
}

func main() {
 cancelObserved, releaseSurvivor, stop := make(chan struct{}), make(chan struct{}), make(chan struct{})
 var connections, handled atomic.Int64
 server := httptest.NewUnstartedServer(http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
 handled.Add(1)
 w.Header().Set("X-Connection-ID", fmt.Sprint(r.Context().Value(connectionKey{})))
 w.Header().Set("Content-Type", "text/plain")
 w.WriteHeader(http.StatusOK)
 w.(http.Flusher).Flush()
 switch r.URL.Path {
 case "/cancel":
 select {
 case <-r.Context().Done():
 close(cancelObserved)
 case <-stop:
 }
 case "/survive":
 select {
 case <-releaseSurvivor:
 fmt.Fprint(w, "survived")
 case <-r.Context().Done():
 case <-stop:
 }
 case "/after":
 fmt.Fprint(w, "ready")
 }
 }))
 server.Config.ConnContext = func(ctx context.Context, _ net.Conn) context.Context {
 return context.WithValue(ctx, connectionKey{}, connections.Add(1))
 }
 server.EnableHTTP2 = true
 server.TLS = &tls.Config{MinVersion: tls.VersionTLS13, MaxVersion: tls.VersionTLS13}
 server.StartTLS()
 defer server.Close()
 defer close(stop)
 config := server.Client().Transport.(*http.Transport).TLSClientConfig.Clone()
 check(!config.InsecureSkipVerify, "certificate verification must stay enabled")
 transport := &http.Transport{TLSClientConfig: config, ForceAttemptHTTP2: true, MaxConnsPerHost: 1}
 defer transport.CloseIdleConnections()
 client := &http.Client{Transport: transport, Timeout: 2 * time.Second}
 open := func(ctx context.Context, route string) *http.Response {
 request, err := http.NewRequestWithContext(ctx, http.MethodGet, server.URL+route, nil)
 must(err)
 response, err := client.Do(request)
 must(err)
 check(response.StatusCode == 200 && response.Proto == "HTTP/2.0", "HTTP/2 response required")
 check(response.Header.Get("X-Connection-ID") == "1", "streams must share the first TCP connection")
 check(response.TLS.Version == tls.VersionTLS13 && response.TLS.NegotiatedProtocol == "h2", "TLS 1.3 and h2 required")
 check(len(response.TLS.VerifiedChains) > 0, "verified server certificate required")
 return response
 }
 firstContext, cancel := context.WithCancel(context.Background())
 defer cancel()
 first := open(firstContext, "/cancel")
 survivor := open(context.Background(), "/survive")
 cancel()
 body, readError := io.ReadAll(first.Body)
 closeError := first.Body.Close()
 must(closeError)
 check(errors.Is(readError, context.Canceled) && len(body) == 0, "first stream must report cancellation")
 select {
 case <-cancelObserved:
 case <-time.After(2 * time.Second):
 panic("server did not observe stream cancellation")
 }
 close(releaseSurvivor)
 body, readError = io.ReadAll(survivor.Body)
 closeError = survivor.Body.Close()
 must(readError)
 must(closeError)
 check(string(body) == "survived", "sibling stream must complete")
 var reused atomic.Bool
 var handshakes atomic.Int64
 trace := &httptrace.ClientTrace{
 GotConn: func(info httptrace.GotConnInfo) { reused.Store(info.Reused) },
 TLSHandshakeStart: func() { handshakes.Add(1) },
 }
 after := open(httptrace.WithClientTrace(context.Background(), trace), "/after")
 body, readError = io.ReadAll(after.Body)
 closeError = after.Body.Close()
 must(readError)
 must(closeError)
 check(string(body) == "ready" && reused.Load() && handshakes.Load() == 0, "connection must remain reusable")
 check(connections.Load() == 1 && handled.Load() == 3, "three streams must use one TCP connection")
 fmt.Println("cancel: context canceled; server observes cancellation")
 fmt.Println("survive: body complete on connection 1")
 fmt.Println("after: connection 1 reused, no new TLS handshake")
 fmt.Println(runtime.Version())
}

The first body’s read must return an error matching context.Canceled and no bytes. The server must independently observe cancellation of that request’s context. Only then does the program release the sibling, whose complete body must equal survived. Thus two successful header responses produce different body outcomes without requiring separate connections.

A third request must return ready on connection one. GotConn reports reuse, TLSHandshakeStart remains zero for that request, and the server asserts three handled requests but only one accepted TCP connection. These observations distinguish a surviving connection from a client silently replacing a broken one.

All assertions passed on macOS with Go 1.27.0. Each request has a two-second timeout, server cancellation observation has its own two-second bound, and cleanup releases waiting handlers. Certificate verification stays enabled; the program neither changes public services nor installs a trust root.

This checks observable Go behavior, not captured wire frames: it does not decode or assert a particular RST_STREAM error code. The protocol explanation comes from RFC 9113. It also does not test packet loss, flow-control exhaustion, connection failure, production side effects, or throughput. Those require separate experiments before drawing stronger isolation or retry conclusions.

Sources

RFC 9113: HTTP/2, stream termination, shared flow control, and TCP limitations, checked 2026-09-09.
Go net/http, request cancellation, response bodies, transport reuse, and timeouts, checked 2026-09-09.
Go crypto/tls, protocol negotiation and verified certificate chains, checked 2026-09-09.

Http2 · 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

gRPC multiplexes many streams over one HTTP/2 connection

One connection, many streams

Streaming beats HTTP/1.1 fan-out

When it breaks

Check it quickly

Further reading

Sources

HTTP/2 multiplexing fixes a queue

A stream is not the socket

Headers are not a completed response

When it breaks

Check it quickly

Further reading

Sources

Http2 · 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

gRPC multiplexes many streams over one HTTP/2 connection

One connection, many streams

Streaming beats HTTP/1.1 fan-out

Deadlines share the same pipe

When it breaks

Check it quickly

Further reading

Sources

HTTP/2 multiplexing fixes a queue

A stream is not the socket

Headers are not a completed response

When it breaks

Check it quickly

Further reading

Sources