HTTP/3 trägt nun ein Drittel des Webs – und QUIC steht erst am Anfang

Rund 30 % des gesamten Webverkehrs fließt inzwischen über HTTP/3, so die Daten des HTTP Archive und Cloudflares jährlicher Year in Review. Google bedient mehr als 90 % seiner eigenen Dienste – Search, YouTube, Gmail – über QUIC. Meta leitet den Großteil seines CDN-Verkehrs auf die gleiche Weise. Fastly, Cloudflare und AWS CloudFront haben HTTP/3 standardmäßig aktiviert. Dies ist kein experimentelles Protokoll mehr. Es ist der Standardtransport für die größten Web-Eigenschaften, und sein Anteil wächst um etwa 3–5 Prozentpunkte pro Jahr.

Das Problem, das HTTP/2 nicht löste

HTTP/2 kam 2015 und behob ein echtes Problem: das Head-of-Line Blocking von HTTP/1.1 auf Anwendungsebene, bei dem eine langsame Antwort alles andere in derselben Verbindung blockierte. HTTP/2 führte Multiplexing ein – mehrere logische Streams über eine einzige TCP-Verbindung – sowie Header-Kompression via HPACK. Die Seitenladezeiten verbesserten sich messbar, vor allem auf Verbindungen mit hoher Latenz.

Aber HTTP/2 behielt TCP als Transportschicht, und TCP hat ein eigenes Head-of-Line Blocking-Problem, das Multiplexing nicht beheben kann. TCP garantiert geordnete Auslieferung: Wenn ein Segment verloren geht, müssen alle nachfolgenden Segmente – auch die zu völlig unabhängigen HTTP/2-Streams – warten, bis das verlorene Segment erneut gesendet wurde, bevor TCP sie an die Anwendung ausliefert. Bei 1% Paketverlust kann dies mehrere unabhängige Ressourcen-Streams gleichzeitig aufhalten. In einem Mobilfunknetz mit 2–3% Paketverlust (typisch für LTE am Rand der Abdeckung) verstärkt sich die Latenzauswirkung drastisch.

TLS Handshakes waren das zweite Problem. HTTP/2 über TLS 1.2 erforderte 2 Round-Trips (RTTs), bevor Anwendungsdaten fließen konnten – einen für den TCP-SYN/SYN-ACK/ACK, einen für die TLS-Aushandlung. Auf einer mobilen Verbindung mit 80ms RTT entspricht das 160ms Overhead vor dem ersten Byte Inhalt. TLS 1.3 reduzierte dies auf 1-RTT, aber der eigene 3-Wege-Handshake von TCP blieb unvermeidbar. Connection Migration – was passiert, wenn man von Wi-Fi zu Mobilfunk wechselt – bedeutete, dass TCP-Verbindungen abbrachen und von vorne beginnen mussten.

Was QUIC eigentlich ist

QUIC ist ein Transportprotokoll, das über UDP läuft. Es wurde 2012 von Google entwickelt, etwa 2013 intern eingesetzt und im Mai 2021 von der IETF als RFC 9000 standardisiert. HTTP/3 (RFC 9114) ist nichts anderes als HTTP-Semantik, die auf QUIC statt auf TCP aufsetzt.

Die wesentlichen architektonischen Entscheidungen von QUIC:

• UDP-basiertes Multiplexing mit unabhängigen Streams: QUIC implementiert Stream-Multiplexing auf der Transportschicht, nicht auf der Anwendungsschicht. Jeder Stream hat eigene Flusskontrolle und eigene Verlustbehandlung. Ein verlorenes Paket betrifft nur den Stream, zu dem es gehört – andere Streams liefern weiterhin Daten ohne Unterbrechung. Dadurch wird das Head-of-Line Blocking von TCP auf Transportebene eliminiert.
• Integriertes TLS 1.3: QUIC setzt TLS nicht auf den Transport auf; TLS 1.3 ist integraler Bestandteil des Protokolls. Handshake und Verschlüsselungsaushandlung erfolgen gleichzeitig mit dem Verbindungsaufbau. Eine neue QUIC-Verbindung benötigt 1-RTT, bevor Anwendungsdaten fließen – ein Round-Trip weniger als TLS 1.2 über TCP.
• 0-RTT-Verbindungswiederaufnahme: Wenn ein Client erneut eine Verbindung zu einem Server aufnimmt, mit dem er bereits kommuniziert hat, kann QUIC Anwendungsdaten bereits mit dem allerersten Paket senden (0-RTT-Modus). Der Client nutzt Session-Ticket-Daten der vorherigen Verbindung, um die Anfrage sofort zu verschlüsseln. Bei einer typischen mobilen Wiederverbindung – Wechsel zwischen Wi-Fi und Mobilfunk – kann die erste HTTP-Anfrage ausgehen, bevor der Handshake abgeschlossen ist, was die gefühlte Latenz bei wiederholten Besuchen nahe Null bringt.
• Connection Migration: QUIC identifiziert Verbindungen mit einer 64-Bit-Connection-ID, nicht mit einem 4-Tupel aus IP-Adressen und Ports. Wenn Ihr Gerät die IP-Adresse wechselt – etwa von Wi-Fi zu 5G oder zwischen Mobilfunkmasten – läuft die QUIC-Verbindung ohne Unterbrechung weiter. Kein TCP-Reset, kein neuer Handshake, keine abgebrochenen Streams. Der Server empfängt Pakete von der neuen IP-Adresse, die dieselbe Connection-ID referenzieren, und setzt nahtlos fort.

Leistungsnachweise: Was die Zahlen zeigen

Die Leistungsgewinne von QUIC treten am deutlichsten unter zwei Bedingungen auf: hoher Paketverlust und häufige Netzwerkübergänge. Google veröffentlichte interne A/B-Testergebnisse, die zeigen, dass QUIC die Suchlatenz um 8% im Median und um bis zu 28% im 99. Perzentil (Tail-Latenz) im Vergleich zu HTTPS über TCP reduzierte. Die QUIC-Daten von YouTube zeigten eine 15%ige Reduzierung von Pufferunterbrechungen.

Cloudflares Benchmarks von 2023 zu HTTP/3 vs. HTTP/2 über ein simuliertes Netz mit 1% Paketverlust ergaben mediane Verbesserungen der Seitenladezeit von 12–18% bei ressourcenintensiven Seiten. Bei 3% Paketverlust – realistisch für überlastete Mobilfunknetze – stieg die Verbesserung auf 25–35%. In einem sauberen, latenzarmen Netz mit 0% Paketverlust ist der Leistungsunterschied zwischen HTTP/2 und HTTP/3 gering (unter 5%), da sich das Head-of-Line Blocking von TCP nur bei Segmentverlusten bemerkbar macht.

Der 0-RTT-Wiederaufnahmevorteil ist schwieriger zu isolieren, aber messbar. Meta berichtete, dass die Aktivierung von 0-RTT für wiederkehrende Besucher auf seinem CDN die Time-to-First-Byte (TTFB) um 30–60ms in mobilen Verbindungen reduzierte, was sich direkt in schnelleren Largest Contentful Paint (LCP)-Werten niederschlägt – das Core Web Vital, das am stärksten mit der Benutzererfahrung und dem Google-Suchranking korreliert.

Eine Einschränkung: 0-RTT birgt eine Replay-Schwachstelle. Ein Angreifer, der 0-RTT-Daten abfängt, kann sie wiedergeben, um doppelte Anfragen zu senden. Deshalb ist 0-RTT nur für idempotente Anfragen (GET, HEAD) sicher und muss bei zustandsändernden Operationen (POST, Zahlungen) deaktiviert oder sorgfältig behandelt werden. Moderne Serverimplementierungen handhaben dies automatisch, aber es ist gut, die Einschränkung zu kennen.

Wer HTTP/3 heute einsetzt

Die Verbreitungslandschaft Mitte 2026 ist beachtlich:

• Cloudflare: HTTP/3 seit 2020 standardmäßig für alle Kunden aktiviert. Cloudflare betreibt auch eine der meistgenutzten QUIC-Implementierungen (quiche), die Open Source ist und von Firefox und anderen Projekten verwendet wird.
• Google: Setzt QUIC intern für Search, YouTube, Gmail, Google Drive und Maps ein. Der Chrome-Browser hat QUIC seit 2015 an Bord. Googles QUIC-Implementierung (quic-go und das C++ cronet) ist die Referenzimplementierung für weite Teile des Ökosystems.
• Meta: Setzt HTTP/3 für den CDN-Traffic von Facebook, Instagram und WhatsApp ein. Meta pflegt eine eigene QUIC-Implementierung (mvfst), die 2019 als Open Source veröffentlicht wurde und in Produktion mit Milliarden von Nutzern läuft.
• Fastly, Akamai, AWS CloudFront: Alle bieten HTTP/3 als CDN-Option an, Fastly aktiviert es standardmäßig seit 2022.

Auf der Serversoftware-Seite: nginx hat QUIC/HTTP/3-Unterstützung in v1.25.0 (veröffentlicht Juni 2023) als stabiles Feature hinzugefügt. Caddy liefert HTTP/3 standardmäßig seit v2.4 aktiviert. LiteSpeed und seine Open-Source-Variante OpenLiteSpeed haben HTTP/3-Unterstützung seit 2020. Apache httpd bietet HTTP/3 über das Modul mod_quic an, das in Apache 2.4.55 noch experimentell ist. Der H2O-Server hat QUIC-Unterstützung. Node.js hat eine experimentelle QUIC-API. Die Deno-Laufzeitumgebung unterstützt HTTP/3 nativ.

Was Webentwickler tun müssen

Für die meisten Entwickler, die ein CDN oder einen Cloud Load Balancer nutzen, ist HTTP/3 bereits aktiv – überprüfen Sie es, aktivieren Sie es nicht. Wenn Sie Ihre eigene Serverinfrastruktur betreiben, ist dies der praktische Weg:

Überprüfen Sie, ob HTTP/3 aktiv ist:

• Verwenden Sie curl --http3 https://ihredomain.de -I und prüfen Sie auf HTTP/3 in der Antwortzeile. Erfordert curl, das mit QUIC-Unterstützung kompiliert wurde (curl --version | grep HTTP3).
• In Chrome DevTools: Öffnen Sie das Network-Panel, klicken Sie mit der rechten Maustaste auf die Spaltenüberschriften und aktivieren Sie „Protocol". HTTP/3-Verbindungen werden als h3 angezeigt. HTTP/2 als h2.
• Firefox DevTools zeigt dasselbe in der Protocol-Spalte des Network-Panels.
• Cloudflares quic.cloud-Checker und das Tool http3check.net bieten eine schnelle externe Überprüfung.

HTTP/3 auf nginx aktivieren (1.25+): Fügen Sie listen 443 quic reuseport; neben Ihrer bestehenden listen 443 ssl;-Direktive hinzu, dann fügen Sie add_header Alt-Svc 'h3=":443"; ma=86400'; hinzu, um Browsern QUIC anzukündigen. Der Alt-Svc-Header ist die Art und Weise, wie Clients erfahren, dass HTTP/3 verfügbar ist – die erste Verbindung verwendet HTTP/2, und nachfolgende Verbindungen aktualisieren auf HTTP/3.

HTTP/3 auf Caddy aktivieren: Nichts zu konfigurieren – Caddy aktiviert HTTP/3 standardmäßig, wenn TLS aktiv ist. Bestätigen Sie über die Protokollspalte in DevTools.

Firewall-Konfiguration ist ein häufiger Stolperstein: QUIC läuft auf UDP-Port 443. Viele Unternehmensfirewalls blockieren oder drosseln UDP-Traffic. Wenn HTTP/3 nicht ausgehandelt wird, fallen Browser automatisch auf HTTP/2 zurück – Endnutzer sehen keine Fehler, erhalten aber auch kein QUIC. Wenn Sie debuggen, warum HTTP/3 in einem bestimmten Netzwerk nicht genutzt wird, prüfen Sie, ob UDP/443 offen ist.

Stellen Sie die Überlastregelung für QUIC noch nicht manuell ein. QUIC-Implementierungen verwenden standardmäßig BBR (Bottleneck Bandwidth and RTT) als Überlastregelung, die auf den meisten modernen Netzen besser abschneidet als CUBIC (TCP-Standard). Sofern Sie keine spezifischen, gemessenen Leistungsprobleme haben, sind die Voreinstellungen korrekt.

0-RTT: Die meisten Serverimplementierungen aktivieren 0-RTT für GET-Anfragen automatisch. Wenn Ihre Anwendung zustandsändernde Operationen beim Seitenladen ausführt (ungewöhnlich, aber möglich), prüfen Sie diese Anfragearten. Die Standardempfehlung lautet, 0-RTT-Daten als potenziell wiederholt zu betrachten und entsprechend zu gestalten – verwenden Sie idempotente Token oder prüfen Sie den Zustand auf Anwendungsebene.

Der weitere Weg

HTTP/3 und QUIC entwickeln sich weiter. QUIC Version 2 (RFC 9369, veröffentlicht 2023) fügt Verbesserungen bei der Connection Migration und einen neuen Mechanismus zur Versionsaushandlung hinzu. WebTransport – eine Browser-API, die QUIC-Streams und Datagramme direkt für JavaScript bereitstellt – wird in Chrome und Firefox ausgeliefert und ermöglicht bidirektionale Kommunikation mit niedriger Latenz ohne den Overhead von WebSocket. MASQUE (Multiplexed Application Substrate over QUIC Encryption), ein Protokoll der IETF-Arbeitsgruppe, baut VPN-ähnliche Tunnel auf QUIC auf und ist bereits in iCloud Private Relay im Einsatz.

Für den Webentwickler, der TCP und HTTP versteht, ist QUIC die gleiche Aufgabe, die nun richtig gelöst ist: zuverlässige, geordnete Zustellung dort, wo sie nötig ist (pro Stream), ohne die globale Ordnungsbedingung, die TCP auf verlustbehafteten Strecken pathologisch macht. Das Protokoll ist stabil, die Werkzeuge existieren, und die Leistungsnachweise sind eindeutig. Wenn Ihr Traffic über ein modernes CDN läuft, profitieren Ihre Nutzer bereits. Wenn nicht, besteht der Upgrade-Pfad aus einer einzigen nginx-Konfigurationszeile.