IRCNF

HTTP/3 ist jetzt der Standard: Was sich geändert hat und warum es so lange dauerte

Teilen:
HTTP/3 ist jetzt der Standard: Was sich geändert hat und warum es so lange dauerte

Der Großteil der Internetgeschichte wurde der Webverkehr über TCP abgewickelt – ein zuverlässiges, aber in die Jahre gekommenes Transportprotokoll aus den 1970ern. 2026 ist das nicht mehr der Standard. HTTP/3, aufgebaut auf dem QUIC-Protokoll, ist vom Experimentellen zum Erwarteten übergegangen. Über 34 % der Top-10-Millionen-Websites liefern nun HTTP/3 aus, 92 % der Browser unterstützen es nativ, und große CDNs wie Cloudflare, Fastly und Akamai haben es an ihren Edge-Knoten standardmäßig aktiviert. Was sich geändert hat, warum es wichtig ist – und was der Übergang nicht gelöst hat.

Das Problem, das HTTP/3 tatsächlich löst

Um zu verstehen, warum HTTP/3 existiert, muss man das Head-of-Line-Blocking verstehen – ein Fehler, der HTTP/2 innewohnt und den die meisten Nutzer nie bemerkt haben. HTTP/2 erlaubte mehrere Anfragen in einer einzigen TCP-Verbindung, ein großer Fortschritt gegenüber HTTP/1.1. Doch TCP verarbeitet Daten als einen einzigen geordneten Stream. Geht ein Paket verloren, warten alle anderen Anfragen auf dieser Verbindung, bis das verlorene Paket erneut gesendet und empfangen wird. Eine Paketverlustrate von 1 % – auf Mobilfunknetzen keine Seltenheit – kann einen Großteil des HTTP/2-Vorteils zunichtemachen.

QUIC, bei Google entwickelt und 2021 von der IETF standardisiert, löst dieses Problem, indem es über UDP statt TCP läuft und das Multiplexing auf Protokollebene handhabt. Jeder Stream ist unabhängig. Ein verlorenes Paket verzögert nur den Stream, zu dem es gehört, nicht jede andere Anfrage auf der Verbindung.

Der Leistungsunterschied in der Praxis

Der Leistungsunterschied zwischen HTTP/2 und HTTP/3 ist nicht einheitlich. Bei schnellen, niedrig-latenzigen Verbindungen – Heimfaser, Büro-Ethernet – ist der Unterschied gering und manchmal negativ. Tests bei 1 Gbps ergaben, dass HTTP/3 bis zu 45 % weniger Durchsatz als HTTP/2 liefert, was auf den höheren Pro-Paket-Verarbeitungsaufwand von QUIC im Userspace statt im Kernel zurückzuführen ist.

Wo HTTP/3 deutlich gewinnt, ist bei hohem Paketverlust und hoher Latenz: Mobilfunknetze, Fernverbindungen und überlastete Infrastruktur. Studien zeigen, dass HTTP/3 auf Netzwerken mit mittlerem bis hohem Paketverlust 30 bis 60 % schneller lädt als HTTP/2. Die 0-RTT-Verbindungswiederaufnahme von QUIC spart bei wiederholten Besuchen Hunderte von Millisekunden. Für eine globale Plattform, bei der ein erheblicher Teil der Nutzer über 4G- oder 5G-Verbindungen mit unterschiedlicher Signalqualität zugreift, ist dieser Unterschied bedeutsam.

Verbindungsmigration: Die Funktion, über die niemand spricht

Eine der praktisch nützlichsten Funktionen von QUIC erhält weit weniger Aufmerksamkeit, als sie verdient: die nahtlose Verbindungsmigration. TCP-Verbindungen sind an eine bestimmte IP-Adresse und einen Port gebunden. Wenn das Telefon von WLAN auf Mobilfunk wechselt – oder zwischen Funkzellen – bricht die Verbindung ab und muss neu aufgebaut werden. QUIC verwendet eine Connection ID, die über Netzwerkwechsel hinweg bestehen bleibt, sodass ein aktiver Download oder Videostream einen Netzwerkwechsel ohne Unterbrechung oder erneuten Handshake übersteht.

Für Mobilnutzer im Jahr 2026, die regelmäßig zwischen WLAN, 5G und LTE wechseln, ist dies eine erhebliche Verbesserung der Lebensqualität, die in keinem Benchmark auftaucht.

Die Realität der Adoption

Die Adoption verlief auf Client-Seite schneller als auf Server-Seite. Alle großen Browser – Chrome, Firefox, Safari, Edge – unterstützen HTTP/3 nativ. Auf Server-Seite ist das Bild gemischter. Nginx unterstützt HTTP/3 seit Version 1.25.0, Caddy aktiviert es standardmäßig, und jedes große CDN wickelt es an seinen Edge-Knoten ab, selbst für Ursprungsserver, die nicht dafür konfiguriert wurden.

Einige Unternehmensumgebungen haben sich langsamer angepasst, insbesondere solche mit Legacy-Überwachungstools, die auf TCP-spezifische Paketinspektion angewiesen sind. Netzwerkgeräte, die TCP-Streams für Sicherheits- oder Compliance-Zwecke analysieren, müssen aktualisiert oder ersetzt werden, um QUICs UDP-basierten Verkehr zu verarbeiten. In einigen Regionen, insbesondere Teilen Chinas, haben Netzwerkbetreiber den Verkehr aktiv zu HTTP/2 gelenkt, mit Verweis auf den Effizienzvorteil von TCP in ihrer Infrastruktur.

Was kommt als Nächstes

Die IETF arbeitet bereits an Verfeinerungen des QUIC-Standards. Das HTTP/3-Ökosystem reift schnell: Server-Implementierungen werden effizienter, die Lücke zwischen Userspace- und Kernel-Paketverarbeitung schrumpft, und die Unterstützung für QUIC in Load Balancern und WAFs ist bei großen Anbietern inzwischen Standard. Für Entwickler, die heute neue Dienste bereitstellen, ist die Aktivierung von HTTP/3 neben HTTP/2 mit geringem Aufwand verbunden und erzielt Leistungsgewinne für einen wachsenden Nutzeranteil, ohne dass Nutzer auf schnellen Festnetzverbindungen etwas einbüßen.

Der Protokollwechsel, der stets in weiter Ferne zu liegen schien, ist nun schlicht die Infrastruktur, auf der das Web läuft.

Teilen:
HTTP/3 ist jetzt der Standard: Was sich geändert hat und warum es so lange dauerte | IRCNF - Intelligent Reliable Custom Next-gen Frameworks