HTTP/2 vs HTTP/3: Webprotokolle im Vergleich

HTTP/3 ist seit 2022 standardisiert, seit 2024 in den meisten Browsern und CDNs verfügbar. Trotzdem läuft die große Mehrheit des Web-Traffics noch über HTTP/2. Der Wechsel von HTTP/1.1 zu HTTP/2 war ein klares Upgrade, das jeder mitgemacht hat. HTTP/3 ist subtiler — die Vorteile sind real, aber spezifisch, und für viele Anwendungen ist der Unterschied unspürbar.

Hier mein Versuch, den Vergleich aus praktischer Perspektive zu ziehen, statt nur Marketing-Punkte abzuhaken.

Was HTTP/2 gebracht hat

HTTP/1.1 hatte ein fundamentales Problem: pro TCP-Verbindung konnte nur ein Request gleichzeitig laufen. Browser haben das mit 6+ parallelen Verbindungen pro Domain umgangen, was schnell unübersichtlich wurde. Domain-Sharding (das Verteilen von Assets auf mehrere Subdomains) war jahrelang Standard-Tuning.

HTTP/2 hat das mit Multiplexing gelöst: viele Streams auf einer Verbindung, parallel. Eine TCP-Verbindung pro Origin reicht. Dazu Header-Komprimierung (HPACK) und Server Push (das nie wirklich angekommen ist und 2022 wieder rausgenommen wurde).

Das Ergebnis war für die meisten Sites real spürbar. Page Loads wurden schneller, Connection-Overhead sank, Domain-Sharding verschwand.

Was HTTP/2 nicht löst: Head-of-Line Blocking auf TCP-Ebene

HTTP/2 multiplext auf HTTP-Ebene, nutzt aber TCP darunter. TCP garantiert, dass Pakete in der richtigen Reihenfolge an die App geliefert werden. Wenn ein Paket verloren geht, müssen alle nachfolgenden warten, bis es retransmittet wurde. Auf HTTP-Ebene blockiert das alle Streams auf der Verbindung, obwohl logisch nur einer betroffen ist.

Bei guter Verbindung ist das egal. Bei mobiler Verbindung mit Packet Loss kann es relevant werden.

HTTP/3: gleiche API, andere Transport-Schicht

HTTP/3 ist semantisch identisch zu HTTP/2 — Methods, Status Codes, Header-Konzept. Aber statt TCP nutzt es QUIC, ein Protokoll auf UDP-Basis, das die Garantien von TCP+TLS in einem rebuilt — und dabei das Head-of-Line-Problem fixt.

Die wichtigsten Verbesserungen aus Praxis-Sicht:

• 0-RTT Reconnects: bei wiederkehrenden Verbindungen kann der erste Request mit den initialen Paketen mitgeschickt werden. Spart einen Round-Trip.
• Connection Migration: ein QUIC-Connection identifiziert sich nicht über IP+Port, sondern über eine Connection-ID. Wechselt der Client von WLAN auf 5G, bleibt die Verbindung. Bei TCP wäre sie tot.
• Verbessertes Loss Recovery: kein TCP-Head-of-Line-Blocking mehr.

Wer profitiert messbar?

Sites mit hauptsächlich mobilem Traffic, vor allem in Regionen mit mittelmäßiger Konnektivität. CDN-Workloads. Live-Streaming. Video-Calls.

Wer profitiert weniger: ein typischer Desktop-Nutzer im Glasfaser-Netz beim Aufruf einer statischen Seite. Da liegt die HTTP/3-Verbesserung im einstelligen Prozent-Bereich, oft ist sie nicht messbar.

Was bei der Aktivierung zu beachten ist

Auf nginx braucht HTTP/3 mindestens Version 1.25.0 mit --with-http_v3_module. Cloudflare und die meisten CDNs haben HTTP/3 als One-Click-Option seit Jahren — wer dahinter sitzt, hat es vermutlich schon, ohne es bewusst aktiviert zu haben.

listen 443 quic reuseport;
listen 443 ssl http2;
add_header Alt-Svc 'h3=":443"; ma=86400';

Die letzte Zeile ist wichtig: sie sagt dem Browser per Header "ich kann auch HTTP/3 auf Port 443". Erst beim nächsten Connect probiert der Browser dann HTTP/3.

UDP-Port 443 muss in der Firewall freigegeben sein. Das übersieht jeder beim ersten Mal.

Was du in der Praxis siehst

In den Browser-Devtools (Network-Tab, Spalte "Protocol"):

• h2 = HTTP/2
• h3 = HTTP/3

Beim ersten Request über einen Origin siehst du oft h2, beim nächsten h3. Das ist Browsers Caching der Alt-Svc-Header.

Mit curl --http3 kannst du explizit testen — funktioniert nur mit der quictls-Variante, nicht mit dem Standard-curl.

Mein Setup

Auf meinen eigenen Servern: HTTP/2 als Standard, HTTP/3 aktiviert. Cloudflare davor für die Domains, die das brauchen. Die Performance-Unterschiede zwischen HTTP/2 und HTTP/3 sind im messbaren Bereich, aber nicht spektakulär. Die echten Performance-Gewinne kommen heutzutage aus Caching, Komprimierung und cleveren Asset-Strategien — nicht aus der Wahl des Transport-Protokolls.

Was die Zukunft bringt

QUIC wird die Basis für mehr als HTTP. WebTransport baut darauf auf, Media-over-QUIC ist im Standardisierungsprozess. Das ist die spannendere langfristige Story als die HTTP/2-vs-HTTP/3-Frage.

Für das eigene Web-Setup heute: HTTP/3 aktivieren, wenn dein Stack es unterstützt. Aber keine Performance-Erwartung haben, die über "ein paar Prozent in spezifischen Szenarien" hinausgeht.