HTTP/2 · XB Field Notes

HTTP3 rides UDP while HTTP2 stays safe over TCP

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

HTTP/3 runs over QUIC and UDP, commonly on port 443. HTTP/2 streams on a TCP connection share an ordered byte stream, so a missing segment can stall delivery for unrelated requests. QUIC provides ordered delivery per stream: losing data on one stream need not block delivery on another. Connection-wide congestion control and HTTP dependencies can still affect several streams; this is not independent congestion control for every stream.

Enabling a server module alone is insufficient. The client needs HTTP/3 support, an authoritative endpoint, acceptable TLS credentials, and a working UDP path. Discovery and fallback policies determine when that path is attempted.

Two transports, one port number

UDP:443 and TCP:443 use separate sockets with the same numeric port. An nginx server block can therefore combine listen 443 quic reuseport; with listen 443 ssl; http2 on;. The reuseport option permits per-worker listening sockets on supported systems; it is not a blanket remedy for duplicate server declarations or unrelated processes occupying the port. Check the actual configuration error and socket ownership before changing options.

QUIC integrates TLS 1.3 with transport establishment and can reduce setup round trips. Resumption may permit early application data, but does not eliminate the handshake or guarantee acceptance of 0-RTT. Retry, loss, and validation can add delay. Connection IDs support continuity across address changes when the endpoints and routing infrastructure support it.

Alt-Svc is how the client finds out

An origin can advertise Alt-Svc: h3=":443"; ma=86400 over an existing HTTP connection. This names protocol h3, the same host on port 443, and a 24-hour freshness lifetime. It does not require that connection to use HTTP/2, and prior knowledge can allow a direct HTTP/3 attempt. Clients may use a fresh alternative without waiting for a later page visit; an advertisement alone does not prove reachability.

Freshness permits reuse of the advertisement; it does not force a client to repeat a failed QUIC attempt on every connection. Clients can fall back or apply failure policies. QUIC probe timers depend on RTT estimates and backoff, while the decision to race or abandon a connection belongs to the implementation. The earlier 15-second, 300-seconds-per-day and 0.1-second figures were illustrative assumptions without a retained runnable model or trace, not measured or required fallback timings.

0-RTT and migration are the two sharp edges

0-RTT lets a returning client send application data before completing the new handshake. Early data has replay risk, so the application must define replay-safe handling and reject unsafe early operations. A previous ticket does not guarantee acceptance. An unprotected create-order request can duplicate a side effect; transport encryption alone does not provide exactly-once execution.

Migration can preserve a QUIC connection after a client address changes, subject to peer policy and path validation. A five-tuple balancer can instead send packets to a backend lacking that connection’s cryptographic state, causing interruption or reset. The earlier backend 7-to-4 example has no retained hash model or trace and is not a measured placement result.

When it breaks

A cached advertisement and blocked UDP can delay connection establishment, but neither a day-long penalty nor an HTTP/3 failure proves a middlebox fault. Missing client support, TLS errors, endpoint configuration, and server availability can produce failures too. Compare client errors and protocol-specific latency with server observations; absence from an access log alone is inconclusive. Keep a working TCP alternative and measure the actual client’s fallback policy.

Address changes can also expose incorrect routing affinity. Preserve routing to the QUIC endpoint that owns the connection state; an application cookie alone cannot route encrypted packets before QUIC termination. Validate the deployed connection-ID handling and path changes explicitly. These failures are not limited to mobile clients, and application-session continuity is a separate concern after transport succeeds.

Direct h3 discovery is possible; h2 fallback depends on both endpoints and client policy. No fixed fallback timing or successful migration is guaranteed.

Check it quickly

Use Bash, Python 3 and curl 7.88+ built with HTTP/2 and HTTP/3. Set URL to one authorized direct HTTPS GET endpoint returning 200, including its path. Choose a repeatable read-only resource. No redirects or proxies are used:

(
set -euo pipefail
: "${URL:?Set one authorized HTTPS URL with an expected 200 response}"
umask 077
tmp=$(mktemp -d)
trap 'rm -rf -- "$tmp"' EXIT
probe() {
 local label=$1 mode=$2 expected=$3 rc check_rc
 if curl --disable --silent --show-error --fail --globoff \
 --noproxy '*' --proto '=https' --connect-timeout 10 --max-time 30 \
 "$mode" --output /dev/null --dump-header "$tmp/$label.headers" \
 --write-out '%{json}\n' --url "$URL" > "$tmp/$label.json"; then
 rc=0
 else
 rc=$?
 printf '%s: curl failed (exit %s)\n' "$label" "$rc" >&2
 fi
 if python3 - "$tmp/$label.json" "$label" "$expected" "$URL" "$rc" <<'PY'
import json, math, pathlib, sys
path, label, expected, url, curl_exit = sys.argv[1:]
print(label, "curl_exit", curl_exit)
d, headers = None, None
try:
 d = json.loads(pathlib.Path(path).read_text())
 if not isinstance(d, dict):
 raise ValueError("expected a JSON object")
except (OSError, UnicodeError, ValueError) as error:
 d = None
 print(label, "metadata unavailable:", str(error), file=sys.stderr)
keys = ("url_effective", "remote_ip", "remote_port", "http_version", "http_code",
 "ssl_verify_result", "time_appconnect", "time_starttransfer", "time_total")
if d is not None:
 print(label, json.dumps({k: d[k] for k in keys + ("exitcode", "errormsg") if k in d}))
 missing = [k for k in keys if k not in d]
 if missing:
 print(label, "metadata fields unavailable:", ", ".join(missing), file=sys.stderr)
try:
 headers = pathlib.Path(path).with_suffix(".headers").read_text(encoding="iso-8859-1")
 print(label, "Alt-Svc header observations:",
 [line for line in headers.splitlines() if line.lower().startswith("alt-svc:")])
except OSError as error:
 print(label, "header observations unavailable:", str(error), file=sys.stderr)
if int(curl_exit) != 0:
 # Observations from a failed transfer are not successful validation.
 raise SystemExit(0)
try:
 ok = (d is not None and headers is not None and d["http_code"] == 200 and
 d["url_effective"] == url and d["http_version"] in ("1.1", "2", "3") and
 d["remote_ip"] and d["remote_port"] > 0 and d["ssl_verify_result"] == 0 and
 (expected == "any" or d["http_version"] == expected) and
 all(math.isfinite(d[k]) and d[k] >= 0 for k in
 ("time_appconnect", "time_starttransfer", "time_total")))
except (KeyError, TypeError, ValueError):
 ok = False
if not ok:
 raise SystemExit(label + ": unavailable or unexpected endpoint, protocol, status or timing")
PY
 then
 check_rc=0
 else
 check_rc=$?
 fi
 if [ "$rc" -ne 0 ]; then
 return "$rc"
 fi
 return "$check_rc"
}
failed=0
probe h2 --http2 2 || failed=1
probe h3-only --http3-only 3 || failed=1
probe fallback-enabled --http3 any || failed=1
exit "$failed"
)

Each successful probe checks status, URL and protocol. Failed transfers retain available observations, original exit and stderr; missing or malformed metadata is labeled unavailable. Later probes still run. –http3-only forbids fallback; –http3 permits racing older protocols. A result of 2 or 1.1 records TCP selection, not a controlled blocked-UDP experiment; 1.1 does not prove h2. time_appconnect ends at handshake completion; time_starttransfer ends at first byte. Alt-Svc observations may include interim responses and do not establish reachability.

On the corresponding authorized server, inspect configuration and local sockets separately:

(
set -euo pipefail
umask 077
tmp=$(mktemp -d)
trap 'rm -rf -- "$tmp"' EXIT
if nginx -T > "$tmp/nginx.txt" 2> "$tmp/nginx.err"; then
 cat "$tmp/nginx.err" >&2
else
 rc=$?
 cat "$tmp/nginx.err" >&2
 exit "$rc"
fi
if grep -nE 'listen .*quic|http2|http3|Alt-Svc' "$tmp/nginx.txt"; then
 :
else
 rc=$?
 printf 'No matching directives, or grep failed (exit %s)\n' "$rc" >&2
 exit "$rc"
fi
ss -H -lunp 'sport = :443' > "$tmp/udp.txt"
cat "$tmp/udp.txt"
if [ ! -s "$tmp/udp.txt" ]; then
 printf 'No local UDP:443 listener observed\n' >&2
 exit 1
fi
)

Diagnostics stay visible. Configuration matches may include comments or inactive settings; socket owners may be hidden by permissions. Neither identifies the running public endpoint without further correlation. Treat configuration output as potentially sensitive. Only shell syntax and fake/file controls ran here; actual TLS, HTTP, NGINX and fallback validation remain held.

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, per-stream delivery, connection IDs, migration, and 0-RTT, checked 2026-09-16.
nginx core listen directive, separate listeners and per-worker reuseport semantics, checked 2026-10-18.
curl manual, HTTP/3-only mode, fallback choice, errors, and handshake timing, checked 2026-10-18.
RFC 9002 QUIC recovery, RTT-dependent probe timers and exponential backoff, checked 2026-10-18.

gRPC multiplexes many streams over one HTTP/2 connection

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

gRPC’s HTTP/2 transport lets multiple RPC attempts share a connection while keeping each stream’s messages ordered. That is useful for both short calls and long-lived exchanges. It does not make the connection an unlimited independent transport for every call: bandwidth, TCP delivery, connection flow control, and implementation resources remain shared.

Match the RPC shape to the work

An HTTP/2 RPC attempt occupies a stream; a retry starts another attempt rather than replaying bytes into a completed stream. Reusing connections amortizes establishment and TLS costs, but a channel can manage multiple connections. Calls to different backends do not all magically share one TCP endpoint, and per-call costs still include serialization, metadata, framing, scheduling, and application work.

gRPC offers unary, client-streaming, server-streaming, and bidirectional-streaming methods. Only the last permits independent sequences of messages in both directions within the same RPC. Message ordering is preserved within each direction, without requiring one response per request message. Choose that shape when the application needs it, rather than assuming every gRPC method streams both ways.

HTTP/1.1 can reuse persistent connections, and WebSocket already supports bidirectional messages. Neither inherently needs a fresh handshake for every application message. gRPC’s advantages instead include its RPC contract, generated interfaces, status model, and HTTP/2 stream multiplexing. Compare complete workloads and operational constraints before claiming that streaming is universally faster or requires less buffering.

Separate call deadlines from shared transport

A deadline belongs to an RPC, not automatically to every stream on its connection. Propagate the remaining budget into downstream calls using the language’s supported context mechanism. Starting a fresh full timeout at each hop can extend work beyond the caller’s willingness to wait. Cancellation also needs cooperation from application work; it does not undo effects already committed.

Flow control has both stream and connection scopes for DATA frames. An exhausted stream window can stop that stream while siblings progress if connection credit remains available. Exhausted connection credit prevents nonempty DATA across streams in that direction; zero-length DATA with END_STREAM and control frames can still be sent. Receiver implementations can replenish connection credit independently, so one slow reader does not inevitably exhaust the entire connection.

TCP packet loss can still delay delivery shared by multiple HTTP/2 streams. Queues, CPU, and memory also create coupling outside the protocol’s stream abstraction. A successful write into a library buffer does not establish remote delivery or application consumption. Bound buffers and test slow-reader behavior in the actual client and server libraries.

When it breaks

Oversized metadata can exceed an implementation or proxy limit before the handler runs. The gRPC guide suggests an eight-kibibyte default request-header limit, not a universal maximum or one guaranteed failure status. Inspect both endpoints and intermediaries, and avoid assuming that resending unchanged metadata will fix rejection.

A long-lived stream remains on its selected backend. Connection-level load balancing can concentrate many streams, and reaching concurrent-stream limits may queue new calls rather than create another connection. Choose supported client or proxy balancing deliberately; changing connection lifetime or stream limits is not proof of redistribution. Observe backend occupancy and reconnect behavior before tuning.

gRPC shared flow control: mechanism and evidence boundaries.

Check it quickly

Save this as mux_sim.py and run python3 mux_sim.py. The standard-library model uses three ordered queues with separate stream and connection credits. Each message costs one invented unit; these are not encoded HTTP/2 frames or actual byte windows. Use assertions enabled, without -O or PYTHONOPTIMIZE: pump calls inside assert are part of the scenario. Odd stream identifiers resemble the client side without implementing the wire protocol.

from collections import deque

original = {1: ["a1", "a2", "a3"], 3: ["b1", "b2", "b3"], 5: ["c1", "c2"]}
streams = {sid: deque(items) for sid, items in original.items()}
credit = {1: 3, 3: 3, 5: 2}
connection_credit = 8
wire = []
delivered = {sid: [] for sid in streams}

def pump():
 global connection_credit
 progressed = False
 for sid in sorted(streams):
 if streams[sid] and credit[sid] > 0 and connection_credit > 0:
 payload = streams[sid].popleft()
 credit[sid] -= 1
 connection_credit -= 1
 wire.append((sid, payload))
 delivered[sid].append(payload)
 progressed = True
 return progressed

def drain():
 while pump():
 pass

assert pump()
assert wire == [(1, "a1"), (3, "b1"), (5, "c1")]
credit[3] = 0 # Model a receiver withholding this stream's credit.
drain()
assert delivered[1] == original[1] and delivered[5] == original[5]
assert delivered[3] == ["b1"] and len(wire) == 6
assert connection_credit == 2

credit[3] = 2
connection_credit = 0 # Independent negative control: no connection capacity.
assert not pump() and delivered[3] == ["b1"]
connection_credit = 2
drain()
assert delivered == original and len(wire) == 8
assert connection_credit == 0 and all(not queue for queue in streams.values())
print("wire:", wire)
print("PASS: stream credit isolates one stall; connection credit gates all modeled data")

After one pass, withholding stream 3’s credit lets streams 1 and 5 complete while stream 3 retains two queued messages. Restoring only its stream credit is insufficient when the connection control is set to zero: no message advances. Restoring connection credit then drains all eight messages, with each stream retaining its original order.

Retained exact runs establish these model rules with assertions enabled; this source review did not rerun them. They do not test a gRPC library, HTTP/2 frame encoding, TCP loss, TLS, deadline propagation, cancellation, or balancing. Keep this small experiment separate from a real integration test that deliberately slows one consumer and records stream-level versus connection-level behavior.

Sources

Python assert statement, optimization omits assertions and any calls inside them, checked 2026-10-18.
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.
gRPC flow control, buffering and slow-reader boundaries, checked 2026-10-15.
gRPC deadlines, per-RPC budgets and propagation, checked 2026-10-15.
gRPC metadata, suggested header limits, checked 2026-10-15.
gRPC performance guidance, channels, concurrent-stream queues, and long-lived streaming limits, checked 2026-10-15.

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.

Canceling one HTTP/2 request can leave its sibling and the original connection usable. Verify the body and later connection reuse separately, and keep shared TCP limits and irreversible business effects outside that narrow guarantee.

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.

HTTP/2 · 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

Match the RPC shape to the work

Separate call deadlines from shared transport

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