HTTP/3 und QUIC: Was Backend-Entwickler wissen sollten

Die meisten Backend-Entwickler behandeln HTTP/3 wie eine CDN-Checkbox — etwas, das Cloudflare oder Fastly aktiviert und worüber man nie wieder nachdenkt. Das stimmt so lange, bis man einen Latenzspike debuggt, der nur in Mobilfunknetzen auftritt, oder einen Load Balancer, der UDP-Traffic stillschweigend verwirft und jeden Client zurück auf HTTP/1.1 zwingt. HTTP/3 ist mehr als eine Versionsnummer. Es ersetzt TCP durch QUIC, ein Transportprotokoll auf Basis von UDP, und diese Änderung wirkt sich auf Connection-Handling, Retries und Observability aus — auf eine Weise, wie es HTTP/2 nie getan hat.

Das Problem, das HTTP/2 nie gelöst hat

HTTP/2 führte Multiplexing ein — mehrere logische Streams über eine einzige TCP-Verbindung —, um Head-of-Line-Blocking von HTTP/1.1 auf Anwendungsebene zu beheben. Aber TCP selbst ist ein einziger geordneter Byte-Stream. Geht ein Paket verloren, blockiert TCP jeden Stream dieser Verbindung, bis die Neuübertragung eintrifft — selbst wenn das verlorene Paket zu einem Request gehörte, auf den ohnehin niemand mehr wartet.

HTTP/1.1: 6 parallel TCP connections, no multiplexing
HTTP/2:   1 TCP connection, streams multiplexed
          -> packet loss stalls ALL streams (TCP head-of-line blocking)
HTTP/3:   1 QUIC connection over UDP, streams multiplexed
          -> packet loss stalls ONLY the affected stream

Das ist die zentrale Erkenntnis: HTTP/2 hat Head-of-Line-Blocking nur eine Ebene nach oben verschoben, statt es zu beseitigen. QUIC beseitigt es auf Transportebene, indem jeder Stream eine unabhängige Loss-Recovery erhält — genau deshalb hat die IETF HTTP/3 darauf standardisiert, statt es erneut über TCP zu legen.

Was QUIC tatsächlich verändert

Drei Eigenschaften sind für Backend-Entwickler relevant, nach praktischer Wichtigkeit sortiert:

Die Connection ID ist der Punkt, den die meisten unterschätzen. Eine TCP-Verbindung stirbt in dem Moment, in dem sich die IP-Adresse eines Clients ändert — der Wechsel von WLAN zu Mobilfunk killt jeden laufenden Request. QUIC-Verbindungen werden über eine im Paket eingebettete Connection ID identifiziert, nicht über das Netzwerk-Tupel. Ein Smartphone kann also mitten im Download das Netzwerk wechseln, ohne irgendetwas neu aushandeln zu müssen.

HTTP/3 am Edge aktivieren

Die meisten Teams terminieren QUIC nicht selbst — sie überlassen das einem CDN oder Reverse Proxy und fallen für den Origin-Traffic auf HTTP/2 zurück. Betreibt man aber sein eigenes Edge mit Nginx oder Caddy, ist der Konfigurationsunterschied klein, aber leicht subtil falsch zu machen.

# ❌ HTTP/3 advertised but no fallback — clients on restrictive
# networks that block UDP/443 get stuck with no connection at all
server {
    listen 443 quic reuseport;
    ssl_certificate     /etc/ssl/certs/example.com.pem;
    ssl_certificate_key /etc/ssl/private/example.com.key;
    # missing: TCP listener + Alt-Svc header
}

# ✅ HTTP/3 with proper HTTP/2 fallback and discovery header
server {
    listen 443 ssl;
    listen 443 quic reuseport;
    http2 on;
    http3 on;
 
    ssl_certificate     /etc/ssl/certs/example.com.pem;
    ssl_certificate_key /etc/ssl/private/example.com.key;
 
    # Tells clients that already connected over TCP that QUIC
    # is available, so the *next* connection can use it directly
    add_header Alt-Svc 'h3=":443"; ma=86400';
}

Der Alt-Svc-Header ist es, der Discovery in der Praxis funktionieren lässt — der erste Request eines Browsers an eure Domain läuft noch über TCP, und erst nachfolgende Verbindungen versuchen direkt QUIC, gemäß dem in RFC 9114 definierten Verhandlungsablauf. Nginx dokumentiert dieses Modulverhalten in der HTTP/3-Modulreferenz, falls ihr die vollständige Direktivenliste braucht. Caddy geht den einfacheren Weg und aktiviert HTTP/3 standardmäßig, sobald TLS konfiguriert ist — ohne separaten quic-Listener, um den man sich kümmern müsste.

Das UDP-Blocking-Problem

Das ist die Falle, die euch tatsächlich Debugging-Stunden kostet: Ein nennenswerter Anteil an Firmennetzwerken, manche Mobilfunkanbieter und ältere Middleboxes blockieren oder drosseln UDP/443 rundweg, weil UDP historisch für alte Firewall-Regeln „kein Web-Request" bedeutete. Passiert das, scheitert HTTP/3 nicht laut und deutlich — der Client läuft bei QUIC einfach in ein Timeout und fällt still auf TCP zurück, was eine komplette Round-Trip-Latenz hinzufügt, bevor der Fallback greift.

// ❌ Assuming HTTP/3 succeeded because the request eventually completed
const res = await fetch("https://api.example.com/orders");
// no visibility into which protocol actually served this response
 
// ✅ Log the negotiated protocol so fallback rates are observable
const res = await fetch("https://api.example.com/orders");
const timing = performance.getEntriesByName(res.url).at(-1);
console.log("protocol:", timing?.nextHopProtocol); // "h3", "h2", or "http/1.1"
 
// Aggregate nextHopProtocol client-side and ship it to your
// analytics pipeline — a rising http/1.1 fallback rate on a
// specific network segment is your early signal, not a support ticket

Testen, ohne auf Browser-Telemetrie zu warten

Ihr braucht keinen Produktions-Traffic, um zu prüfen, ob HTTP/3 tatsächlich ausgehandelt wird. curl unterstützt das direkt, wenn es gegen eine QUIC-fähige TLS-Bibliothek gebaut wurde:

# Verify HTTP/3 negotiation explicitly instead of trusting Alt-Svc alone
curl --http3 -v https://example.com/ 2>&1 | grep -E "using HTTP/3|ALPN"
 
# Compare latency across protocol versions from the same location
curl -w "%{time_connect} %{time_appconnect} %{time_total}\n" \
  --http3 -o /dev/null -s https://example.com/
curl -w "%{time_connect} %{time_appconnect} %{time_total}\n" \
  --http2 -o /dev/null -s https://example.com/

Führt das von ein paar verschiedenen Netzwerkstandpunkten aus — Heim-Breitband, mobiler Hotspot und Firmen-VPN —, bevor ihr davon ausgeht, dass sich euer HTTP/3-Rollout überall gleich verhält. Die MDN-HTTP/3-Referenz ist eine gute Basis dafür, wie der aktuelle Browser-Support aussieht, falls ihr den Rollout gegenüber einem skeptischen Team rechtfertigen müsst.

Die wichtigsten Erkenntnisse

1. HTTP/3 behebt Head-of-Line-Blocking auf Transportebene, indem jeder Stream eine unabhängige Loss-Recovery bekommt — HTTP/2 hat das nur auf Anwendungsebene gelöst.
2. Die Connection ID von QUIC übersteht IP-Wechsel, was für mobile Clients weit relevanter ist als für Server-zu-Server-Traffic.
3. Kombiniert http3 on immer mit einem funktionierenden HTTP/2- oder HTTP/1.1-Fallback und einem Alt-Svc-Header — geht nie einfach davon aus, dass QUIC klaglos funktioniert.
4. UDP/443-Blocking in Firmen- und Mobilfunknetzen verursacht reale, messbare Fallback-Raten — instrumentiert nextHopProtocol clientseitig, statt zu raten.
5. Testet die Protokollverhandlung explizit mit curl --http3, bevor ihr euch allein auf CDN-Dashboards oder Browser-DevTools verlasst.
6. Die meisten Teams sollten QUIC von einem CDN terminieren lassen und den Origin-Traffic auf HTTP/2 belassen — HTTP/3 selbst zu hosten lohnt sich erst, wenn man dessen Fehlermodi wirklich versteht.