Das Internet-Lexikon

HTTP/2 vs. HTTP/3

Was sich zwischen den beiden aktuellen HTTP-Versionen technisch unterscheidet und warum HTTP/3 auf UDP statt TCP setzt.

HTTP/1.1 prägte das Web über zwei Jahrzehnte, stieß aber mit wachsender Seitenkomplexität zunehmend an Grenzen. HTTP/2 und HTTP/3 lösen diese Grenzen auf grundlegend unterschiedliche Weise - und wer verstehen will, warum HTTP/3 nicht einfach “HTTP/2, aber schneller” ist, muss beim Transportprotokoll darunter ansetzen.

1. Das Problem von HTTP/1.1

HTTP/1.1 kann pro TCP-Verbindung immer nur eine Anfrage gleichzeitig verarbeiten, bevor die nächste beginnen kann (ohne Pipelining-Erweiterungen, die sich in der Praxis kaum durchsetzten). Browser umgingen das, indem sie mehrere parallele TCP-Verbindungen zum selben Server öffneten - meist eine begrenzte Anzahl pro Domain - mit zusätzlichem Overhead durch mehrfachen Verbindungsaufbau und mehrfachen TLS-Handshake.

2. Was HTTP/2 verbessert

HTTP/2 führt Multiplexing ein: Über eine einzige TCP-Verbindung können mehrere Anfragen und Antworten gleichzeitig, ineinander verschachtelt übertragen werden. Zusätzlich komprimiert HTTP/2 Header mit dem HPACK-Verfahren, um wiederholte, redundante Informationen zwischen Anfragen zu reduzieren - bei vielen kleinen Ressourcen mit ähnlichen Headern (etwa Cookies, User-Agent) summiert sich das spürbar. Eine dritte, in der Praxis umstrittene Funktion war Server Push, bei dem der Server Ressourcen ungefragt mitschickt, bevor der Client sie anfordert - die Funktion wurde von wichtigen Browsern inzwischen wieder entfernt bzw. nicht mehr unterstützt, weil sie in der Praxis selten den erhofften Nutzen brachte und Caching-Verhalten verkomplizierte.

3. Das verbleibende Problem: Head-of-Line-Blocking

Da HTTP/2 weiterhin auf TCP aufbaut, kann ein einzelnes verlorenes Datenpaket den gesamten Datenstrom blockieren, bis es erneut übertragen wurde - selbst wenn Daten für andere, eigentlich unabhängige Anfragen bereits vollständig angekommen sind. Das liegt daran, dass TCP eine strikte, byteweise Reihenfolge garantiert: Alle nachfolgenden Daten müssen warten, bis die Lücke geschlossen ist. Dieses als “Head-of-Line-Blocking” bekannte Problem betrifft besonders Verbindungen mit Paketverlusten, etwa in mobilen Netzwerken oder bei WLAN mit schwachem Signal.

4. Was HTTP/3 anders macht

HTTP/3 ersetzt TCP durch QUIC, ein auf UDP aufbauendes Transportprotokoll. QUIC behandelt einzelne Datenströme innerhalb einer Verbindung unabhängig voneinander, sodass ein verlorenes Paket nur den betroffenen Stream verzögert, nicht die gesamte Verbindung - das löst das Head-of-Line-Blocking auf Transportebene, nicht nur auf HTTP-Ebene wie bei HTTP/2. Zusätzlich integriert QUIC Verschlüsselung direkt ins Protokoll (TLS 1.3 ist fester Bestandteil, nicht optional wie bei klassischem TCP+TLS) und beschleunigt den Verbindungsaufbau, da Transport- und Verschlüsselungs-Handshake in weniger Roundtrips kombiniert werden als bei separatem TCP- und TLS-Handshake.

5. Verbindungswechsel ohne Neuaufbau

Ein oft übersehener praktischer Vorteil von QUIC: Eine Verbindung wird nicht wie bei TCP über die Kombination aus IP-Adresse und Port identifiziert, sondern über eine eigene Connection-ID. Wechselt ein mobiles Gerät etwa von WLAN zu Mobilfunk und ändert sich dabei die IP-Adresse, kann eine bestehende QUIC-Verbindung unter Umständen fortgesetzt werden, statt komplett neu aufgebaut werden zu müssen. Bei TCP erzwingt ein solcher Netzwerkwechsel praktisch immer einen kompletten Verbindungsneuaufbau.

6. Warum UDP nicht automatisch “schneller” bedeutet

Ein verbreitetes Missverständnis ist, UDP sei grundsätzlich schneller als TCP und QUIC gewinne allein dadurch. Tatsächlich ist UDP für sich genommen unzuverlässig - es garantiert weder Zustellung noch Reihenfolge von Paketen. QUIC baut auf UDP als schlankem Fundament auf, implementiert aber eigene Mechanismen für Zuverlässigkeit, Reihenfolge und Flusskontrolle - nur eben pro Stream statt für die gesamte Verbindung. Der Geschwindigkeitsvorteil von HTTP/3 kommt also nicht von UDP selbst, sondern davon, dass QUIC diese Mechanismen flexibler und stream-bewusst implementiert, als TCP es kann.

7. Middlebox- und Firewall-Hürden

Weil QUIC auf UDP läuft, blockieren manche restriktive Firewalls, Unternehmensnetzwerke oder ältere Netzwerkgeräte (sogenannte Middleboxes) UDP-Verkehr auf dem für HTTP/3 genutzten Port standardmäßig stärker als TCP-Verkehr auf Port 443. Browser und Server begegnen dem in der Praxis mit einem automatischen Fallback: Schlägt HTTP/3 fehl oder wird es nicht unterstützt, greift die Verbindung transparent auf HTTP/2 oder HTTP/1.1 zurück. Website-Betreiber müssen sich um diesen Fallback im Regelfall nicht kümmern, sollten aber wissen, dass ein Teil der Nutzer aus diesem Grund faktisch nie über HTTP/3 verbunden ist.

8. Aktivierung in der Praxis

Beide Protokollversionen erfordern serverseitige Unterstützung, sind für Website-Betreiber aber meist ohne Codeänderung über Hosting- oder CDN-Konfiguration aktivierbar. Viele CDNs bieten HTTP/2 und HTTP/3 standardmäßig oder per Schalter an; bei selbst betriebenen Servern hängt die Unterstützung von der eingesetzten Webserver-Software und deren Version ab. Wichtig: HTTP/2 und HTTP/3 setzen beide verschlüsseltes HTTPS voraus (bei HTTP/3 ist das protokollbedingt zwingend) - ohne gültiges TLS-Zertifikat lässt sich keine der beiden Versionen nutzen.

9. Wie du prüfst, welches Protokoll tatsächlich verwendet wird

  1. In den Browser-Entwicklertools den Netzwerk-Tab öffnen, eine Anfrage an die eigene Domain auswählen und die Spalte “Protocol” einblenden (in Chrome per Rechtsklick auf die Spaltenüberschrift) - sie zeigt h2 oder h3 für die tatsächlich genutzte Version.
  2. Da HTTP/3 bei Fehlschlag automatisch auf HTTP/2 zurückfällt, sollte diese Prüfung wiederholt und nicht nach einem einzelnen Testlauf als endgültig angenommen werden.
  3. Serverseitig lässt sich über die Response-Header (etwa ein Alt-Svc-Header, der HTTP/3-Unterstützung ankündigt) prüfen, ob der Server HTTP/3 überhaupt anbietet.

10. Praktische Einordnung

Für die meisten Websites bringt der Wechsel zu HTTP/2 bereits deutliche Verbesserungen gegenüber HTTP/1.1, insbesondere bei Seiten mit vielen einzelnen Ressourcen. HTTP/3 zeigt seine Stärken besonders bei mobilen Verbindungen mit höherer Paketverlustrate und bei Nutzern, die häufig zwischen Netzwerken wechseln. Bei stabilen, kabelgebundenen Verbindungen mit geringem Paketverlust fällt der wahrnehmbare Unterschied zwischen HTTP/2 und HTTP/3 in der Praxis oft deutlich geringer aus.

Weiterführend