Wahrscheinlich surfst du längst über HTTP/3, ohne es zu merken. Große Seiten wie Google, YouTube, Cloudflare oder Facebook liefern ihre Inhalte heute per HTTP/3 aus – und dein Browser wechselt still und leise darauf, sobald der Server es anbietet. Aber was steckt eigentlich dahinter? Warum ist das Ganze schneller als das gute alte HTTP/2? Und wie siehst du auf einen Blick, ob eine Webseite schon HTTP/3 spricht?

Genau darum geht es in diesem Artikel – und am Ende zeige ich dir ein kleines Browser-Plugin, das ich selbst dafür gebaut habe.

Kurzer Rückblick: HTTP/1.1 und HTTP/2 laufen über TCP

Um zu verstehen, warum HTTP/3 so ein Sprung ist, müssen wir kurz einen Schritt zurückgehen.

HTTP/1.1 (aus dem Jahr 1997) und HTTP/2 (2015) haben eines gemeinsam: Sie laufen beide über TCP (Transmission Control Protocol). TCP ist das zuverlässige Arbeitspferd des Internets. Es sorgt dafür, dass jedes Datenpaket ankommt, in der richtigen Reihenfolge, und fordert verlorene Pakete erneut an. Klingt gut – und ist es auch. Aber TCP hat eine Eigenheit, die ausgerechnet beim modernen Web zum Flaschenhals wird.

Bevor überhaupt Daten fließen, braucht TCP einen Drei-Wege-Handshake (SYN, SYN-ACK, ACK). Kommt Verschlüsselung dazu – und die ist heute Pflicht – legt TLS obendrauf noch einen eigenen Handshake. Das sind im schlechtesten Fall mehrere Runden hin und her, bevor das erste Byte deiner Webseite ankommt.

Das eigentliche Problem: Head-of-Line-Blocking

HTTP/2 hat schon einen cleveren Trick eingeführt: Multiplexing. Statt für jede Datei (CSS, JavaScript, Bilder) eine eigene Verbindung aufzumachen, schickt HTTP/2 alles parallel über eine einzige TCP-Verbindung, aufgeteilt in viele „Streams“.

Der Haken: TCP selbst weiß nichts von diesen Streams. Für TCP ist alles ein einziger, streng geordneter Byte-Strom. Geht unterwegs ein einzelnes Paket verloren, hält TCP den kompletten Strom an, bis dieses eine Paket erneut angekommen ist – obwohl die Pakete für alle anderen Streams längst da sind. Dieses Phänomen nennt man Head-of-Line-Blocking (HoL). Ein verlorenes Paket blockiert also Daten, die mit ihm gar nichts zu tun haben. Besonders in mobilen Netzen mit Paketverlust bremst das massiv.

Und genau hier setzt HTTP/3 an.

QUIC: HTTP/3 wirft TCP über Bord und setzt auf UDP

HTTP/3 ist im Kern nichts anderes als HTTP über QUIC. Und QUIC (ursprünglich von Google entwickelt, heute vom IETF standardisiert) macht etwas Radikales: Es verabschiedet sich von TCP und setzt stattdessen auf UDP (User Datagram Protocol).

Moment – UDP? Das „unzuverlässige“ Protokoll ohne Empfangsbestätigung, das man von DNS, Videostreaming und Gaming kennt?

Genau das. Der Clou: QUIC baut alle guten Eigenschaften von TCP (Zuverlässigkeit, Reihenfolge, Überlastkontrolle) selbst neu nach – aber im User-Space, direkt über UDP, und pro Stream getrennt. UDP dient hier nur als schlanker, schneller Transport-Umschlag. Die eigentliche Intelligenz steckt in QUIC obendrauf.

Warum UDP als Basis? Weil UDP praktisch keine eigenen Regeln aufzwingt und in jeder Netzwerk-Hardware bereits durchgeleitet wird. Es ist das perfekte „leere Blatt“, auf dem QUIC ein modernes Transportprotokoll aufbauen kann, ohne sich mit den jahrzehntealten Einschränkungen von TCP herumzuschlagen. Und weil TCP tief in Betriebssystemkernen und Middleboxen (Router, Firewalls) verdrahtet ist, ließe es sich ohnehin kaum noch grundlegend ändern – über UDP kann QUIC sich viel schneller weiterentwickeln.

Ports: HTTP/3 spricht über UDP 443

Ein Punkt, der viele überrascht: Auch HTTP/3 läuft über Port 443 – aber eben UDP 443 statt TCP 443. Für HTTPS bist du gewohnt, dass TCP-Port 443 offen ist. Für HTTP/3 muss zusätzlich der UDP-Port 443 durch Firewalls und NAT erlaubt sein.

Das ist in der Praxis eine häufige Stolperfalle: Ist UDP 443 irgendwo geblockt (manche restriktiven Firmen- oder Hotelnetze tun das), fällt der Browser einfach still auf HTTP/2 über TCP zurück. Die Seite funktioniert weiter – nur eben ohne den Geschwindigkeitsvorteil.

Warum HTTP/3 schneller ist – die vier großen Vorteile

1. Kein Head-of-Line-Blocking mehr. Weil QUIC die Streams auf Transport-Ebene wirklich unabhängig macht, blockiert ein verlorenes Paket nur noch seinen eigenen Stream. Alle anderen laufen ungestört weiter. Genau das Problem von HTTP/2 ist damit gelöst.

2. Verschlüsselung ist eingebaut. QUIC hat TLS 1.3 fest integriert. Es gibt keinen getrennten „erst TCP, dann TLS“-Handshake mehr – Verbindungsaufbau und Verschlüsselung passieren in einem Rutsch. Das spart eine komplette Roundtrip-Runde.

3. Schnellerer Verbindungsaufbau & 0-RTT. Beim ersten Kontakt braucht QUIC oft nur einen einzigen Roundtrip (1-RTT). Warst du schon mal auf einer Seite, kann QUIC per 0-RTT die Verbindung sogar ohne zusätzlichen Roundtrip wieder aufnehmen – die ersten Nutzdaten fliegen praktisch sofort los. Gerade auf Verbindungen mit hoher Latenz (Mobilfunk, große Distanzen) ist das spürbar.

4. Connection Migration. Kennst du das: Du verlässt das WLAN und dein Handy wechselt ins Mobilfunknetz – und alle Verbindungen brechen kurz ab? Bei TCP ist eine Verbindung fest an die IP-Adressen und Ports gebunden. QUIC dagegen identifiziert eine Verbindung über eine eigene Connection ID. Wechselst du das Netz, läuft dieselbe QUIC-Verbindung einfach weiter – der Download stockt nicht.

Unterm Strich heißt das: weniger Wartezeit beim Verbindungsaufbau, robuster bei Paketverlust, stabiler beim Netzwechsel. Für den Nutzer fühlt sich das Web damit einfach flotter an.

Und woran erkennst du jetzt, ob eine Seite HTTP/3 nutzt?

Technisch verrät ein Server, dass er HTTP/3 kann, über den alt-svc-Header (Alternative Services) in seiner Antwort. Steht da ein h3, weiß dein Browser: „Diese Seite kann ich beim nächsten Mal über HTTP/3 laden.“

Genau deshalb passiert übrigens etwas Interessantes: Beim allerersten Besuch einer Seite lädt dein Browser sie oft noch über HTTP/2 – und wechselt erst beim zweiten Aufruf auf HTTP/3, weil er den alt-svc-Hinweis zuerst lernen muss.

Nachschauen kannst du das prinzipiell über die Entwicklertools (F12 → Netzwerk → Spalte „Protokoll“, da steht dann h3, h2 oder http/1.1). Aber Hand aufs Herz: Wer klappt schon für jede Seite die DevTools auf?

Mein kleines Plugin: HTTP-Version direkt in der Toolbar

Weil mich genau das gestört hat, habe ich mir ein kleines Browser-Plugin gebaut – den HTTP/3 & QUIC Checker. Die Idee ist bewusst minimalistisch: Es zeigt dir die HTTP-Version der aktuellen Seite direkt als Ziffer im Toolbar-Symbol an, ohne dass du irgendwo klicken musst:

  • 🟢 Grüne „3″ – die Seite kann HTTP/3 / QUIC.
  • 🟡 Gelbe „2″ – die Seite läuft über HTTP/2.
  • ⚪ Graue „1″ – nur HTTP/1.1.
  • ⚪ Graues „?“ – noch keine Daten (z. B. auf internen Browser-Seiten), einfach neu laden.

Willst du es genauer wissen, klickst du auf das Symbol und bekommst in einem kleinen Fenster das Ergebnis im Klartext – inklusive des tatsächlich genutzten Protokolls.

Das Plugin ist absichtlich so gebaut, dass es nicht stört: Es läuft einfach still mit, du kannst es dauerhaft aktiv lassen und siehst beim Surfen nebenbei, ob du gerade auf HTTP/2 oder HTTP/3 unterwegs bist. Für mich ist das mittlerweile ein netter kleiner Realitäts-Check, wie weit HTTP/3 im echten Web schon verbreitet ist – und ehrlich gesagt sieht man ziemlich schnell: erstaunlich weit.

Ein paar Details, die mir wichtig waren:

  • Datenschutz: Die Erkennung passiert komplett lokal in deinem Browser. Es werden keine Daten gesammelt, gespeichert oder verschickt. Kein Tracking, keine Server im Hintergrund.
  • Leichtgewichtig: Manifest V3, winzig, liest nur das, was zur Protokoll-Erkennung nötig ist.
  • 33 Sprachen: Die Oberfläche passt sich automatisch an deine Browsersprache an.

Hol’s dir – kostenlos

Wenn du also beim Surfen sehen willst, ob eine Seite schon im HTTP/3-Zeitalter angekommen ist, probier es einfach aus:

Installieren, eine beliebige Seite öffnen und auf die Ziffer oben rechts schauen. Viel Spaß beim Beobachten, wie grün dein Web schon ist. 

Ansichten: 49