savearoundtrip: HTTPS-DNS-Records veröffentlichen und einen Roundtrip sparen

 (savearoundtrip.com)
1 Punkte von GN⁺ 4 시간 전 | 1 Kommentare | Auf WhatsApp teilen
  • Wenn eine Website HTTPS-DNS-Records mit Unterstützung für HTTP/3 veröffentlicht, kann der Browser bereits bei der ersten Verbindung QUIC/HTTP/3 verwenden und so einen Verbindungs-Roundtrip einsparen
  • Browser entdecken die HTTP/3-Unterstützung, indem sie sich entweder zuerst per HTTP/1 oder HTTP/2 verbinden und den Alt-Svc-Header lesen, oder indem sie bereits bei der DNS-Auflösung HTTPS-Records auslesen
  • In Firefox-Nightly-Messungen meldeten 31,4 % der Verbindungen HTTP/3 nur über den Alt-Svc-Header; in diesem Fall wird HTTP/3 erst bei späteren Verbindungen verwendet {p:31}
  • HTTPS-Records enthalten alpn, ech, ipv4hint und ipv6hint und ermöglichen damit die Protokollwahl für die erste Verbindung, ECH und Adress-Hinweise direkt in der DNS-Antwort
  • HTTPS-Records ergänzen das Verhalten bestehender Clients; Alt-Svc sollte als Fallback für Clients erhalten bleiben, die den Record nicht erhalten

Zentrale Konzepte

  • Browser entdecken die HTTP/3-Unterstützung einer Website auf zwei Arten
    • Sie verbinden sich zunächst per HTTP/1 oder HTTP/2 und lesen danach den HTTP-Header Alt-Svc
    • Oder sie prüfen sie direkt über einen HTTPS-DNS-Record noch vor dem Aufbau der Verbindung
  • Nur mit HTTPS-DNS-Records kann der Browser bereits bei der ersten Verbindung HTTP/3 verwenden und über QUIC einen Roundtrip einsparen
  • In aktuellen Build-Durchschnittsschätzungen von Firefox Nightly meldeten 31,4 % der Verbindungen HTTP/3 nicht über DNS, sondern ausschließlich über den Alt-Svc-Header
  • Der aktuelle Roundtrip zu diesem Server wird mit etwa 28 ms gemessen

Domain prüfen

  • savearoundtrip.com veröffentlicht selbst einen HTTPS-Record mit h3, IP-Hinweisen und ECH
  • Der HTTPS-Record der eingegebenen Domain wird im Browser über den DNS-over-HTTPS-Endpunkt von Cloudflare abgefragt
  • Der Alt-Svc-Header und der tatsächliche HTTP/3-Handshake lassen sich nicht direkt im Browser prüfen
    • CORS verbirgt Header über Origins hinweg
    • Der Browser kann keine kalte QUIC-Verbindung erzwingen
  • Die eingegebene Domain wird an ein kleines Open-Source-Backend gesendet, das nur die Prüfung von Alt-Svc und des tatsächlichen HTTP/3-Handshakes übernimmt
  • Es werden keine Daten gespeichert, und der tatsächliche HTTP/3-Handshake wird mit quic-go durchgeführt

Die Kosten eines Roundtrips

  • Ein Roundtrip ist der Vorgang, bei dem eine Nachricht zum Server gesendet und wieder empfangen wird, begrenzt durch die Lichtgeschwindigkeit
  • Grobe Roundtrip-Zeiten liegen bei 5–20 ms innerhalb einer Stadt, 40–80 ms zwischen Ländern und über 150 ms über Ozeane hinweg oder in Mobilfunknetzen
  • Cloudflare Radar liefert Echtzeitwerte
  • Interaktionen unter etwa 100 ms fühlen sich unmittelbar an, darüber entsteht ein Wartegefühl
  • Diese Seite benötigte vom Verbindungsaufbau bis zum ersten Paint etwa 41 ms, und der aktuelle Roundtrip zu diesem Server liegt bei rund 28 ms
  • Ein veröffentlichter HTTPS-Record kann den Browser dazu bringen, bei der ersten Verbindung statt TCP direkt QUIC zu verwenden und so diese Roundtrip-Zeit einzusparen
  • Diese Seite ist statisch und klein, daher ist das gesamte Zeitbudget gering; in echten Apps ist ein Roundtrip jedoch ebenfalls ein fixer Vorab-Kostenfaktor, der sich über mehrere Origins hinweg wiederholen kann

Verschwendete Roundtrips

  • Alt-Svc ist ein HTTP-Response-Header aus RFC 7838
  • Damit ein Client Alt-Svc lesen kann, muss er bereits eine TCP-Verbindung aufgebaut, den TLS-Handshake abgeschlossen und eine Anfrage per HTTP/1.1 oder HTTP/2 beendet haben
  • Dadurch erfährt er erst nach einer vorherigen Verbindung, dass der Server auch HTTP/3 unterstützt, sodass das Upgrade auf HTTP/3 erst bei der nächsten Verbindung erfolgt
  • Der HTTPS-Record aus RFC 9460 transportiert dasselbe Signal für HTTP/3-Unterstützung in DNS
  • Da der Client diesen Record während der ohnehin stattfindenden Namensauflösung liest, kann er noch vor dem Verbindungsaufbau von HTTP/3 erfahren
  • Mit HTTPS-DNS-Records kann QUIC/HTTP/3 bereits ab der ersten Verbindung verwendet werden, ohne vorher erst eine HTTP/1- oder HTTP/2-Verbindung zu verbrauchen

Warum HTTPS-Records besser sind

  • HTTP/3-Erkennung vor dem ersten Byte

    • Das SvcParam alpn listet die vom Endpunkt unterstützten ALPN-Protokoll-IDs auf
    • Beispiele sind h3 für HTTP/3 und h2
    • Da diese Information schon während der Namensauflösung ankommt, kann der Client QUIC sofort bei der ersten Verbindung auswählen, statt h3 erst nach einer vorherigen HTTP/1- oder HTTP/2-Verbindung zu entdecken

  • ECH: Encrypted Client Hello

    • Das SvcParam ech enthält den öffentlichen Schlüssel der ECHConfigList des Endpunkts
    • ECH verschlüsselt das TLS ClientHello einschließlich des SNI-Servernamens, damit Netzbeobachter nicht sehen können, welche Website besucht wird
    • Dieses Problem lässt sich nicht per HTTP-Header lösen, weil der öffentliche Schlüssel bereits vor dem Senden des ersten ClientHello benötigt wird
    • Da der Schlüssel zu einem Zeitpunkt benötigt wird, an dem noch keine Verbindung existiert, kann ECH nur über einen Out-of-Band-Kanal wie den HTTPS-Record in DNS gebootstrapped werden
    • Ohne HTTPS RR kann auch ECH nicht verwendet werden

  • Schnellere Verbindungsaufnahme mit IP-Hinweisen

    • Happy Eyeballs v3 führt A-, AAAA- und HTTPS-Abfragen parallel aus
    • ipv4hint und ipv6hint in der HTTPS-Antwort liefern Kandidatenadressen für Verbindungen, wenn sie vor den A/AAAA-Records eintreffen
    • Der Client kann mit der Verbindung zu den Hinweisadressen beginnen, statt auf A/AAAA-Antworten zu warten
    • A/AAAA-Records treffen weiterhin ein und ersetzen die Hinweise, sobald sie verfügbar sind
    • Alt-Svc bietet keine entsprechende Funktion

  • Eine einzige autoritative Quelle und Caching

    • Informationen zur Erreichbarkeit können mit normaler TTL innerhalb von DNS bleiben
    • Beim Alt-Svc-Ansatz sind diese Informationen auf HTTP-Header-Caches pro Origin verteilt, und es entsteht ein max-age-Dilemma
    • Ist max-age zu lang, verwenden Clients veraltete Alternativen; ist er zu kurz, fallen sie häufiger auf das vorherige Protokoll zurück
    • Browser führen DNS-Abfragen ohnehin aus, und HTTPS-Records sorgen dafür, dass diese Abfragen gleich die optimalen Verbindungsinformationen mitliefern

  • Funktionsvergleich

    • | Funktion | Alt-Svc HTTP-Header (RFC 7838) | HTTPS RR (RFC 9460) |
    • | --- | --- | --- |
    • | Zeitpunkt des Lernens | Nach vollständigem Verbindungsaufbau | Während der DNS-Auflösung |
    • | h3 bei der ersten Verbindung | Nicht möglich | Möglich |
    • | IP-Hinweise | Nicht vorhanden | ipv4hint / ipv6hint |
    • | ECH-Schlüssel | Nicht möglich | ech-Parameter |
    • | Source of Truth | HTTP-Header und fragiler Cache | DNS mit TTL |

Reale Browser-Messungen

  • In Firefox-Nightly-Messungen kann der Browser von der HTTP/3-Unterstützung entweder über den HTTP-Response-Header Alt-Svc oder über einen HTTPS-DNS-Record erfahren
  • Alt-Svc wird erst nach dem Verbindungsaufbau sichtbar, HTTPS-DNS-Records schon davor
  • Alle Verbindungen fallen in eine von vier Gruppen
    • Neither sind Verbindungen, bei denen HTTP/3 überhaupt nicht angekündigt wurde
    • Alt-Svc only sind Verbindungen, die nur per Header angekündigt wurden und bei denen HTTP/3 bei der ersten Verbindung nicht genutzt werden konnte
    • HTTPS record only sind Verbindungen, die in DNS angekündigt wurden und von Anfang an per HTTP/3 erfolgen konnten
    • Both sind Verbindungen, die sowohl in DNS als auch per Header angekündigt wurden
  • Die gemessenen Anteile der Verbindungen lagen bei 59,8 % für Neither, 31,4 % für Alt-Svc only, 2,8 % für HTTPS record only und 6 % für Both {b:60,31,3,6}
  • Diese vier Gruppen decken alle Verbindungen vollständig ab und summieren sich daher zu 100 %
  • HTTPS record only und Both hatten einen verfügbaren HTTPS-Record; Alt-Svc only markiert die Lücke, die sich mit einem Record hätte einsparen lassen
  • Die Zahlen sind rekonstruierten Verbindungs-Schätzungen aus Firefox-Nightly-GLAM-Histogrammen und als aktuelle Build-Mittelwerte nur näherungsweise

HTTPS-Records veröffentlichen

  • Ein ServiceMode-HTTPS-Record, der h3 und Adress-Hinweise ankündigt, kann in einer einzigen Zeile veröffentlicht werden
; zone file (BIND-style)
example.com.  3600  IN  HTTPS 1 . alpn="h3,h2" ipv4hint=203.0.113.10 ipv6hint=2001:db8::10
  • example.com. ist der Name, unter dem der Record veröffentlicht wird; der abschließende Punkt kennzeichnet einen vollständig qualifizierten Domainnamen
  • 3600 ist die TTL in Sekunden, für die Resolver den Record cachen dürfen
  • IN ist die Internet-DNS-Klasse wie bei allen Web-Records
  • HTTPS ist der Record-Typ aus RFC 9460
  • 1 ist die Priorität; 1 oder höher bedeutet ServiceMode mit Parametern
  • 0 ist AliasMode, der nur auf ein anderes Ziel verweist
  • . ist der Ziel-Host und steht für den Owner-Namen selbst, also example.com
  • alpn="h3,h2" listet die vom Server unterstützten Protokolle in sinnvoller Reihenfolge auf; h3 ist HTTP/3 und h2 ist HTTP/2
  • ipv4hint und ipv6hint sind Adressen, zu denen Clients sofort parallel zu A/AAAA-Abfragen eine Verbindung beginnen können
  • Die meisten Managed-DNS-Anbieter wie Cloudflare oder Route 53 bieten den HTTPS-Record-Typ direkt an
  • Ob eine Domain unterstützt wird, lässt sich mit dem Checker prüfen

Welche Funktionen reale HTTPS-Records enthalten

  • In Firefox Nightly wurde gemessen, welcher Anteil der Verbindungen mit gesehenen HTTPS-Records jeweils welche Funktionen enthielt
  • ALPN mit h3 lag bei 80,3 %, IPv4-Hinweise bei 52,9 %
  • IPv6-Hinweise lagen bei 49,4 %, ECH bei 12,8 % {b:80,53,49,13}
  • Auch diese Werte sind nur Näherungen, da sie aus GLAM-Histogrammen als Verbindungs-Schätzungen rekonstruiert wurden

FAQ

  • Ob ein CDN automatisch veröffentlicht

    • Einige CDNs veröffentlichen HTTPS-Records automatisch
    • Cloudflare liefert für geproxte Zonen automatisch HTTPS-Records mit alpn="h3"
    • Bei anderen CDNs müssen Nutzer dies selbst konfigurieren
    • Der schnellste Weg zur Prüfung ist die oben verlinkte Domain-Prüfung

  • Ob HTTPS-Records ältere Clients kaputtmachen

    • Clients, die HTTPS-Records nicht verstehen, ignorieren sie und greifen auf normale A/AAAA-Abfragen zurück
    • Wenn weiterhin ein Alt-Svc-Header gesendet wird, können solche Clients auch diesen nutzen
    • Das Veröffentlichen von HTTPS-Records ergänzt also nur das bestehende Verhalten

  • Was bei wiederholten Besuchen passiert

    • Nachdem ein Client einmal per HTTP/3 kommuniziert hat, kann er bei späteren Besuchen die QUIC-Verbindung per 0-RTT wiederaufnehmen
    • Bei 0-RTT kann die erste Anfrage sofort ohne Handshake-Roundtrip gesendet werden
    • Auch der HTTPS-Record selbst wird wie andere DNS-Antworten während seiner TTL gecacht, sodass die Abfrage bei späteren Besuchen meist ebenfalls entfällt

  • Welche Browser HTTPS-Records nutzen

    • Die großen Engines unterstützen HTTPS-Records standardmäßig aktiviert
    • Sie lesen den Record unabhängig davon, ob Besucher DNS-over-HTTPS aktiviert haben
    • Safari verwendet den Resolver des Betriebssystems
    • Chrome verwendet einen eingebauten Resolver und funktioniert über DoH oder normales DNS
    • Firefox kann beide Wege nutzen

  • Ob der Alt-Svc-Header entfernt werden sollte

    • Der Alt-Svc-Header sollte nicht entfernt werden
    • Er sollte als Fallback für ältere Clients sowie für Resolver oder Netzwerke erhalten bleiben, die HTTPS-Records nicht ausliefern
    • Browser, die HTTPS-Records lesen, erfahren HTTP/3 bereits über DNS und verschwenden keinen zusätzlichen Roundtrip mehr für die Erkennung von HTTP/3

Verwandte Beiträge

1 Kommentare

 
GN⁺ 4 시간 전
Lobste.rs-Kommentare
  • Der Webhosting-Anbieter unterstützt H3 noch nicht, aber man kann es mit einem kostenlosen Upgrade auf die neue Serverversion ausprobieren.
    Danach werde ich den HTTPS-DNS-Record setzen.
  • Apples dig ist 9.10.6, also offenbar älter als dieser Record-Typ.
    Apple sollte wohl ein neueres dig bereitstellen; ich frage mich, ob es ein bevorzugtes Tool für DNS-Lookups unter macOS gibt.

    • Ich nutze auf mehreren Plattformen gern doggo.
      Es ist nicht perfekt, hat aber insgesamt ziemlich gut funktioniert und deckt einen großen Teil dessen ab, was ich brauche.

    • Ich verwende drill aus ldns, das ich über Homebrew installiert habe.

      % drill -Q https savearoundtrip.com  
1 . alpn=h3,h2 ipv4hint=104.21.20.43,172.67.191.84 ech=AEX+DQBBzwAgACAdG3AfYFkusczSXA/kky1bgK67QViv5mNKyS3ITnrWbAAEAAEAAQASY2xvdWRmbGFyZS1lY2guY29tAAA= ipv6hint=2606:4700:3030::ac43:bf54,2606:4700:3037::6815:142b
  • Wenn es einen HTTPS-Resource-Record gibt, verbindet sich jeder Client, der ihn liest, sicher.
    Das gilt auch dann, wenn QUIC nicht unterstützt wird.
  • Ich verstehe nicht, warum dieser Beitrag mit Vibe Coding getaggt ist.
    Fast das Einzige ist, dass das CSS so aussieht, als käme es von einem LLM.
    • Der erste Commit scheint definitiv mit einem LLM erstellt worden zu sein: https://github.com/mxinden-bot/savearoundtrip/…
      Außerdem ist der Text weitschweifig. Es gibt viel Wiederholung, viel Nutzloses und seltsame Visualisierungen, sodass er bei etwa 1700 Wörtern auf eine Seitenlänge von über 7300px in voller Breite kommt.
      Mit 500 Wörtern, zwei Diagrammen und einer Gesamtlänge von unter 2000px wäre es deutlich besser.