QUIC vs. HTTP/2: Was HTTP/3 wirklich schneller macht
HTTP/3 ist nicht „HTTP/2, aber schneller". Es ist HTTP/2 auf einem anderen Transport – und praktisch alle Vorteile kommen aus diesem Wechsel, nicht aus dem Protokoll darüber.
Head-of-Line-Blocking: der eigentliche Grund
HTTP/2 kann mehrere Anfragen parallel über eine Verbindung schicken (Multiplexing). Das löste ein echtes Problem von HTTP/1.1. Nur: Alle diese Streams laufen durch eine TCP-Verbindung, und TCP garantiert die Reihenfolge aller Bytes.
Geht ein einziges Paket verloren, hält TCP alles Nachfolgende zurück, bis das Paket erneut angekommen ist – auch die Daten von Streams, die mit dem verlorenen Paket nichts zu tun haben. Zehn parallele Downloads, ein verlorenes Paket, und alle zehn stocken.
QUIC kennt die Streams selbst und verwaltet sie unabhängig. Ein Paketverlust in Stream 3 hält Stream 7 nicht auf. Das ist der Kern des Ganzen – und der Grund, warum der Unterschied bei einem sauberen Kabelanschluss kaum auffällt und in einem vollen Zug oder schlechten WLAN sehr wohl.
Handshake: eine Runde weniger
Eine HTTPS-Verbindung über TCP braucht erst den TCP-Handshake, dann den TLS-Handshake – bei TLS 1.3 also zwei Umläufe, bevor das erste Byte Nutzdaten fließt.
QUIC verschmilzt beides: Transport- und Verschlüsselungsaufbau passieren gemeinsam, ein Umlauf genügt. Bei einer Wiederverbindung zu einem bekannten Server geht sogar 0-RTT – die erste Anfrage reist mit dem allerersten Paket mit.
In Zahlen: Bei 30 ms Latenz spart das ~30 ms, bei 200 ms Mobilfunklatenz ~200 ms. Deshalb ist der Effekt mobil deutlich spürbarer als am Schreibtisch.
Connection Migration
Eine TCP-Verbindung ist über IP-Adresse und Port definiert. Wechselt das Handy von WLAN auf Mobilfunk, ändert sich die IP – die Verbindung ist tot und alles beginnt von vorn.
QUIC identifiziert Verbindungen über eine eigene Connection ID, unabhängig von der IP. Der Wechsel vom WLAN aufs Mobilnetz unterbricht einen laufenden Download deshalb nicht. Für klassische Websites ist das ein Randfall, für Streaming und lange Uploads ein großer Vorteil.
Wo HTTP/3 wenig bringt
Fairerweise: Es gibt Fälle, in denen der Gewinn nahe null liegt.
- Stabile Verbindungen mit wenig Paketverlust. Ohne Verluste gibt es kein Head-of-Line-Blocking, das man umgehen könnte.
- Wenige, große Dateien. Multiplexing-Vorteile zeigen sich bei vielen kleinen Requests.
- Server-CPU. QUIC läuft im User Space statt im Kernel und ist rechenintensiver als TCP. Bei sehr hohem Durchsatz kann HTTP/3 sogar minimal teurer sein.
Trotzdem gibt es kaum ein Argument dagegen: Browser fallen automatisch auf HTTP/2 zurück, wenn QUIC nicht geht. Das Risiko ist praktisch null, der Gewinn für mobile Besucher real.
Und was ist mit HTTP/2?
HTTP/2 verschwindet nicht. Jeder HTTP/3-fähige Server spricht weiterhin HTTP/2, schon weil die erste Verbindung darüber läuft (siehe Alt-Svc). Die realistische Aufteilung heute: HTTP/3 für Browser, die es können und dürfen, HTTP/2 als solider Unterbau für alles andere.
Ob deine Seite beides anbietet, zeigt dir der HTTP/3 Check in Sekunden.
