English
DeutschHTTP/3 beim ersten Besuch: Wie ein Client das Protokoll entdeckt und was zwanzig Seiten geantwortet haben
Inhalt
Eine Protokollfassung lässt sich nicht einfach verlangen. HTTP/1.1 und HTTP/2 werden während des verschlüsselten Verbindungsaufbaus ausgehandelt, in einem Schritt, in dem beide Seiten auflisten, was sie sprechen. HTTP/3 kann an diesem Schritt nicht teilnehmen, weil es gar nicht dieselbe Art Verbindung benutzt.
Zwanzig große Seiten wurden je einmal geöffnet. Sechs davon sprechen HTTP/3. Keine einzige der zwanzig Verbindungen hat es benutzt.
Was HTTP/3 anders macht
HTTP/1.1 und HTTP/2 laufen beide über TCP. HTTP/3 läuft über QUIC, und das sitzt stattdessen auf UDP.
Der praktische Gewinn liegt im Umgang mit Verlusten. Unter HTTP/2 teilen sich mehrere Anfragen eine TCP-Verbindung, und ein einziges verlorenes Paket bremst sie alle aus, bis es erneut geschickt wurde: Jeder Strom wartet auf einen. QUIC hält die Ströme unabhängig, ein verlorenes Paket verzögert also nur das, wozu es gehörte.
Der Preis dafür ist ein völlig anderer Transportweg. Wer HTTP/3 will, muss eine UDP-Verbindung zu einem Port aufbauen, an dem vielleicht jemand lauscht und vielleicht nicht – und das lässt sich nicht während eines TCP-Aufbaus herausfinden, weil es keinen TCP-Aufbau gibt.
Wie ein Programm erfährt, dass es HTTP/3 gibt
Es gibt zwei Wege, und beide müssen vor der Verbindung liegen, die ihn nutzen würde.
Der erste ist ein Header. Ein Server, der über HTTP/2 antwortet, kann Alt-Svc: h3=":443" mitschicken. Das heißt: Denselben Inhalt gibt es auch über HTTP/3 auf diesem Port, und das Angebot gilt so und so viele Sekunden. Das Programm merkt sich das und nutzt es beim nächsten Mal.
Der zweite ist das DNS. Ein HTTPS-Eintrag kann das Protokoll benennen, bevor überhaupt eine Verbindung besteht, und das ist der einzige Weg, der bei einem wirklich ersten Besuch trägt.
Beides sind Ankündigungen, keines ist eine Anfrage. Einfach HTTP/3 zu versuchen und zurückzufallen geht nicht, denn ein misslungener UDP-Versuch kostet eine Wartezeit, und die ist schlimmer als der Verzicht.
Was zwanzig Seiten geantwortet haben
Am 2. September 2026 öffnete ein Programm, das HTTP/3 beherrscht, jede Seite einmal und folgte dabei den Weiterleitungen. Alle zwanzig Seiten antworteten mit Status 200.
Achtzehn Verbindungen kamen über HTTP/2 zustande. Zwei über HTTP/1.1: nginx.org und www.gnu.org, beides alteingesessene Projektseiten.
Keine einzige über HTTP/3 – auch nicht bei den sechs Seiten, deren Antwort es ankündigte. Denn die Ankündigung steckt in der Antwort, und zu diesem Zeitpunkt ist die Verbindung längst zustande gekommen.
Der zweite Abruf sieht anders aus
Drei der Seiten wurden danach zweimal hintereinander gefragt, wobei das Programm behielt, was ihm beim ersten Mal gesagt worden war.
Bei cloudflare.com, bbc.com und w3.org lief der erste Abruf über HTTP/2 und der zweite über HTTP/3, jedes Mal. Am Server hat sich dazwischen nichts geändert. Der einzige Unterschied war, dass das Programm einmal da gewesen war.
So sieht die Verbreitung von HTTP/3 in der Praxis aus: Die erste Seite eines Besuchs wird nie darüber ausgeliefert, alles danach vielleicht. Ob das ins Gewicht fällt, hängt davon ab, welchen Anteil eines Besuchs die erste Anfrage ausmacht – bei einer einzelnen gelesenen und wieder verlassenen Seite einen ziemlich großen.
Angekündigt und unerreichbar, und umgekehrt
Zwei Seiten fielen in entgegengesetzte Richtungen aus dem Muster.
python.org baute jede erzwungene HTTP/3-Verbindung auf, schickte aber keinen Alt-Svc-Header und führte auch keinen DNS-Eintrag. Das Protokoll wird gesprochen und nirgends angekündigt, ein Browser hat also keine Möglichkeit, davon zu erfahren.
spiegel.de kündigte HTTP/3 in der Antwort an, doch fünf erzwungene Versuche aus diesem Netz kamen nie zustande. Das ist eine Aussage über diese Messung und nicht über die Seite: Eine UDP-Verbindung kann unterwegs an Dingen scheitern, die mit dem Server nichts zu tun haben.
Der DNS-Weg erwies sich ebenfalls als selten. Von zehn geprüften Namen führten drei einen HTTPS-Eintrag: cloudflare.com, www.cloudflare.com und w3.org.
Was daraus folgt
Für den Betrieb einer Seite ist die Reihenfolge das Brauchbare.
Alt-Svc zu schicken kostet einen Header und hebt jede Anfrage nach der ersten auf HTTP/3. Das ist die billige Hälfte, und sechs von zwanzig Seiten haben sie.
Der HTTPS-Eintrag im DNS ist die Hälfte, die schon die erste Anfrage erreicht, und genau die hat fast niemand gesetzt. Wo ein Besuch typischerweise aus einer Seite besteht, läge dort der Gewinn.
Und eine Messung, ob eine Seite HTTP/3 unterstützt, beantwortet eine andere Frage als die, ob eine Seite über HTTP/3 benutzt wird. Die zwanzig hier unterstützen das eine und wurden mit dem anderen benutzt.
Wie der HTTPS-Eintrag aufgebaut ist, welche Parameter er trägt und was zwanzig Domains in einer eigenen Messung am 5. September 2026 darin veröffentlicht haben, beschreibt Der HTTPS-Eintrag im DNS: HTTP/3 finden, ohne den Umweg.
Fragen und Antworten
Was muss am Netz stimmen, bevor eine Seite Alt-Svc schickt?
Der UDP-Port 443 muss auf dem ganzen Weg offen sein. Viele Aufbauten sind nur für TCP eingerichtet: Die Firewall des Servers erlaubt 443/tcp, der Router leitet nur TCP weiter, ein vorgeschalteter Filter des Anbieters lässt UDP nicht durch. HTTP/2 funktioniert dann tadellos, und nichts deutet auf das Problem hin.
Schickt die Seite in diesem Zustand Alt-Svc, laufen Browser bei der nächsten Anfrage in einen Verbindungsversuch, der nie zustande kommt. Sie fallen auf HTTP/2 zurück, doch der Artikel nennt den Preis: Ein misslungener UDP-Versuch kostet Wartezeit. Die Ankündigung macht die Seite dann langsamer statt schneller.
Zwei Dinge helfen. Erstens eine Prüfung von außerhalb des eigenen Netzes mit einem Programm, das HTTP/3 erzwingen kann; wie das Beispiel spiegel.de zeigt, hängt das Ergebnis vom Weg ab. Zweitens ein kurzer Wert für ma im Header, also die Gültigkeit der Ankündigung in Sekunden. Fehlt ma, gilt die Ankündigung nach RFC 7838 für 24 Stunden, und so lange bleibt eine falsche Ankündigung im Umlauf, auch wenn sie längst entfernt wurde.
Zählt HTTP/3 auch, wenn ein CDN vor der Seite steht?
Ja, aber nur auf der Strecke zwischen Browser und CDN. Der Ursprungsserver dahinter kann weiter HTTP/1.1 oder HTTP/2 sprechen, und den Alt-Svc-Header schickt dann meist das CDN, nicht der eigene Server.
Wie sieht ein HTTPS-Eintrag im DNS aus?
In seiner einfachsten Form so:
example.com. 3600 IN HTTPS 1 . alpn=h3,h2
Die 1 ist die Priorität und zeigt an, dass der Eintrag Dienstparameter trägt; der Punkt danach bedeutet, dass derselbe Name gemeint ist; alpn listet die Protokolle, die der Server spricht. Ein Browser, der diesen Eintrag abfragt, weiß damit schon vor der ersten Verbindung, dass HTTP/3 angeboten wird.
Zwei Voraussetzungen gehören dazu. Der DNS-Anbieter muss den Eintragstyp HTTPS unterstützen, was nicht jeder tut. Und der Eintrag ersetzt keinen offenen UDP-Port 443: Er kündigt nur an, genau wie Alt-Svc, und eine Ankündigung ohne erreichbaren Port kostet dieselbe Wartezeit, diesmal schon beim ersten Besuch.
Passend dazu
