savearoundtrip : publier des enregistrements DNS HTTPS et éviter un aller-retour

 (savearoundtrip.com)
1 points par GN⁺ 4 시간 전 | 1 commentaires | Partager sur WhatsApp
  • Si un site web publie la prise en charge de HTTP/3 dans un enregistrement DNS HTTPS, le navigateur peut utiliser QUIC/HTTP/3 dès la première connexion, ce qui évite un aller-retour de connexion
  • Le navigateur découvre la prise en charge de HTTP/3 soit en se connectant d’abord en HTTP/1 ou HTTP/2 pour lire l’en-tête Alt-Svc, soit en lisant un enregistrement HTTPS dès l’étape de résolution DNS
  • Selon des mesures de Firefox Nightly, 31,4 % des connexions n’annonçaient HTTP/3 que via l’en-tête Alt-Svc ; dans ce cas, HTTP/3 n’est utilisé qu’aux connexions suivantes {p:31}
  • Les enregistrements HTTPS peuvent contenir alpn, ech, ipv4hint et ipv6hint, ce qui permet de gérer dans la réponse DNS le choix du protocole pour la première connexion, ECH et des indices d’adresse
  • Les enregistrements HTTPS s’ajoutent au fonctionnement des clients existants, et Alt-Svc doit être conservé comme repli pour les clients qui ne reçoivent pas l’enregistrement

Concepts clés

  • Le navigateur découvre la prise en charge de HTTP/3 d’un site de deux façons
    • en se connectant d’abord en HTTP/1 ou HTTP/2, puis en lisant l’en-tête HTTP Alt-Svc
    • en la vérifiant directement via une requête d’enregistrement DNS HTTPS avant d’ouvrir la connexion
  • Ce n’est qu’avec les enregistrements DNS HTTPS que le navigateur peut utiliser HTTP/3 dès la première connexion, en évitant un aller-retour grâce à QUIC
  • D’après une estimation moyenne sur les builds récentes de Firefox Nightly, 31,4 % des connexions n’annonçaient HTTP/3 que via l’en-tête Alt-Svc, et non via le DNS
  • L’aller-retour jusqu’à ce serveur est actuellement mesuré à environ 28 ms

Vérification de domaine

  • savearoundtrip.com publie lui-même un enregistrement HTTPS avec h3, des indices d’IP et ECH
  • L’enregistrement HTTPS du domaine saisi est interrogé dans le navigateur via le point de terminaison DNS-over-HTTPS de Cloudflare
  • L’en-tête Alt-Svc et la véritable poignée de main HTTP/3 ne peuvent pas être vérifiés directement dans le navigateur
    • CORS masque les en-têtes inter-origines
    • le navigateur ne peut pas forcer la création d’une connexion QUIC froide
  • Le domaine saisi est envoyé à un petit backend open source, qui ne fait que vérifier Alt-Svc et la véritable poignée de main HTTP/3
  • Aucune donnée n’est stockée, et la véritable poignée de main HTTP/3 est effectuée avec quic-go

Le coût d’un aller-retour

  • Un aller-retour consiste à envoyer un message au serveur puis à recevoir la réponse, et il est limité par la vitesse de la lumière
  • En ordre de grandeur, il faut 5 à 20 ms dans une même ville, 40 à 80 ms entre pays, et plus de 150 ms à travers un océan ou sur un réseau mobile
  • Cloudflare Radar fournit des chiffres en temps réel
  • Une interaction d’environ moins de 100 ms paraît immédiate, au-delà on commence à percevoir une attente
  • Pour cette page, il a fallu environ 41 ms entre le début de la connexion et le premier affichage, et l’aller-retour en temps réel jusqu’à ce serveur est d’environ 28 ms
  • Un enregistrement HTTPS publié permet au navigateur d’utiliser QUIC au lieu de TCP dès la première connexion et d’éliminer ce temps d’aller-retour
  • Cette page est statique et légère, donc son budget total est faible, mais dans une vraie application, un aller-retour reste un coût fixe payé dès le départ et qui peut se répéter sur plusieurs origines

L’aller-retour gaspillé

  • Alt-Svc est un en-tête de réponse HTTP défini par la RFC 7838
  • Pour lire Alt-Svc, le client doit déjà avoir ouvert une connexion TCP, terminé la poignée de main TLS, puis finalisé une requête en HTTP/1.1 ou HTTP/2
  • Avec cette méthode, le client n’apprend que trop tard que le serveur prend aussi en charge HTTP/3, et la bascule vers HTTP/3 n’a lieu qu’à la connexion suivante
  • L’enregistrement HTTPS de la RFC 9460 place le même signal de prise en charge de HTTP/3 dans le DNS
  • Comme le client lit cet enregistrement pendant la résolution de nom qu’il effectuait déjà, il peut connaître la prise en charge de HTTP/3 avant d’ouvrir la connexion
  • Avec un enregistrement DNS HTTPS, il est possible d’utiliser QUIC/HTTP/3 dès la première connexion, sans devoir d’abord consommer une connexion HTTP/1 ou HTTP/2

Pourquoi les enregistrements HTTPS sont meilleurs

  • Découverte de HTTP/3 avant le premier octet

    • Le SvcParam alpn énumère les identifiants de protocole ALPN pris en charge par le point de terminaison
    • Les exemples sont h3 pour HTTP/3 et h2
    • Comme cette information arrive pendant la résolution de nom, le client peut choisir QUIC dès la première connexion au lieu de découvrir h3 après une connexion préalable en HTTP/1 ou HTTP/2

  • ECH : Client Hello chiffré

    • Le SvcParam ech contient la clé publique ECHConfigList du point de terminaison
    • ECH chiffre le TLS ClientHello, y compris le nom de serveur SNI, afin qu’un observateur du réseau ne puisse pas voir le site visité
    • Ce problème ne peut pas être résolu avec un en-tête HTTP, car la clé publique est nécessaire avant l’envoi du premier ClientHello
    • Comme la clé est requise à un moment où aucune connexion n’existe encore, seul un canal hors bande comme l’enregistrement HTTPS du DNS peut amorcer ECH
    • Sans HTTPS RR, ECH ne peut pas être utilisé

  • Démarrer la connexion plus vite grâce aux indices d’IP

    • Happy Eyeballs v3 exécute en parallèle les requêtes A, AAAA et HTTPS
    • ipv4hint et ipv6hint dans la réponse HTTPS fournissent des adresses candidates de connexion lorsqu’elles arrivent avant les enregistrements A/AAAA
    • Le client peut commencer à se connecter à ces adresses indicatives au lieu d’attendre les réponses A/AAAA
    • Les enregistrements A/AAAA continuent d’arriver et remplacent ensuite ces indices
    • Alt-Svc n’a aucune fonctionnalité équivalente

  • Une source d’autorité unique et la mise en cache

    • Les informations d’accessibilité peuvent rester dans le DNS avec un TTL normal
    • Avec Alt-Svc, l’information est dispersée dans des caches d’en-têtes HTTP par origine, avec le dilemme du max-age
    • Si max-age est trop long, le client risque d’utiliser trop longtemps une alternative obsolète ; s’il est trop court, il reviendra plus souvent à l’ancien protocole
    • Comme les navigateurs effectuent de toute façon une résolution DNS, les enregistrements HTTPS permettent à cette résolution de transporter aussi les informations optimales de connexion

  • Comparatif des fonctionnalités

    • | Fonctionnalité | En-tête HTTP Alt-Svc (RFC 7838) | HTTPS RR (RFC 9460) |
    • | --- | --- | --- |
    • | Moment d’apprentissage | Après la connexion complète | Pendant la résolution DNS |
    • | h3 à la première connexion | Non | Oui |
    • | Indices d’IP | Sans objet | ipv4hint / ipv6hint |
    • | Clé ECH | Impossible | Paramètre ech |
    • | Source de vérité | En-tête HTTP et cache fragile | DNS avec TTL |

Mesures réelles côté navigateur

  • Dans les mesures de Firefox Nightly, le navigateur peut apprendre la prise en charge de HTTP/3 soit via l’en-tête de réponse HTTP Alt-Svc, soit via un enregistrement DNS HTTPS
  • Alt-Svc n’est visible qu’après qu’une connexion a déjà eu lieu, alors que l’enregistrement DNS HTTPS est visible avant la connexion
  • Toutes les connexions appartiennent à l’un de quatre groupes
    • Neither : aucune annonce de HTTP/3
    • Alt-Svc only : annonce uniquement via l’en-tête, donc impossible d’utiliser HTTP/3 à la première connexion
    • HTTPS record only : annonce via le DNS, donc possibilité d’utiliser HTTP/3 dès la première connexion
    • Both : annonce à la fois dans le DNS et dans l’en-tête
  • La répartition mesurée des connexions est de 59,8 % pour Neither, 31,4 % pour Alt-Svc only, 2,8 % pour HTTPS record only et 6 % pour Both {b:60,31,3,6}
  • Ces quatre groupes couvrent l’ensemble des connexions, donc leur total fait 100 %
  • HTTPS record only et Both indiquent qu’un enregistrement HTTPS exploitable existait, tandis que Alt-Svc only représente un écart qui aurait pu être évité si l’enregistrement avait été présent
  • Ces chiffres sont des estimations reconstruites par connexion à partir des histogrammes GLAM de Firefox Nightly, et restent donc approximatifs

Publier un enregistrement HTTPS

  • Un enregistrement HTTPS en ServiceMode qui annonce h3 et des indices d’adresse peut être publié sur une seule ligne
; zone file (BIND-style)
example.com.  3600  IN  HTTPS 1 . alpn="h3,h2" ipv4hint=203.0.113.10 ipv6hint=2001:db8::10
  • example.com. est le nom qui publie l’enregistrement, et le point final indique qu’il s’agit d’un nom de domaine pleinement qualifié
  • 3600 est le TTL, en secondes, pendant lequel les résolveurs peuvent mettre l’enregistrement en cache
  • IN est la classe DNS Internet, comme pour les autres enregistrements du web
  • HTTPS est le type d’enregistrement défini par la RFC 9460
  • 1 est la priorité ; toute valeur supérieure ou égale à 1 correspond au ServiceMode qui contient des paramètres
  • 0 correspond à l’AliasMode, qui ne fait que pointer vers une autre cible
  • . est l’hôte cible ; ici, cela désigne le nom du propriétaire lui-même, soit example.com
  • alpn="h3,h2" liste les protocoles pris en charge dans un ordre de préférence : h3 pour HTTP/3 et h2 pour HTTP/2
  • ipv4hint et ipv6hint fournissent des adresses permettant au client de lancer immédiatement la connexion en parallèle des requêtes A/AAAA
  • La plupart des fournisseurs DNS managés, dont Cloudflare et Route 53, proposent directement le type d’enregistrement HTTPS
  • Il est possible de vérifier la prise en charge d’un domaine via le checker

Ce que contiennent réellement les enregistrements HTTPS

  • Dans Firefox Nightly, la proportion de connexions ayant vu un enregistrement HTTPS contenant chaque fonctionnalité a été mesurée
  • Pour ALPN, h3 atteignait 80,3 %, et les indices IPv4 52,9 %
  • Les indices IPv6 représentaient 49,4 %, et ECH 12,8 % {b:80,53,49,13}
  • Ces valeurs sont approximatives, car elles proviennent d’estimations par connexion reconstruites à partir des histogrammes GLAM

FAQ

  • Les CDN le publient-ils automatiquement ?

    • Certains CDN publient automatiquement des enregistrements HTTPS
    • Cloudflare fournit automatiquement un enregistrement HTTPS avec alpn="h3" pour les zones proxifiées
    • Pour d’autres CDN, la configuration doit être faite manuellement
    • Le moyen le plus rapide de le vérifier est d’utiliser la vérification de domaine ci-dessus

  • Les enregistrements HTTPS cassent-ils les anciens clients ?

    • Les clients qui ne comprennent pas les enregistrements HTTPS les ignorent et reviennent aux requêtes A/AAAA normales
    • S’ils reçoivent toujours l’en-tête Alt-Svc, ils peuvent aussi s’en servir
    • La publication d’enregistrements HTTPS s’ajoute donc au comportement existant

  • Que se passe-t-il lors d’une revisite ?

    • Une fois qu’un client a communiqué en HTTP/3, il peut reprendre la connexion QUIC en 0-RTT lors d’une revisite
    • En 0-RTT, la première requête peut être envoyée immédiatement, sans aller-retour de poignée de main
    • L’enregistrement HTTPS lui-même est aussi mis en cache pendant son TTL, comme toute autre réponse DNS, si bien qu’une revisite évite souvent aussi la requête DNS

  • Quels navigateurs utilisent les enregistrements HTTPS ?

    • Les principaux moteurs prennent en charge les enregistrements HTTPS activés par défaut
    • Ils lisent ces enregistrements, que le visiteur ait activé DNS-over-HTTPS ou non
    • Safari utilise le résolveur du système d’exploitation
    • Chrome utilise son propre résolveur intégré, via DoH ou DNS classique
    • Firefox peut utiliser les deux approches

  • Faut-il supprimer l’en-tête Alt-Svc ?

    • Il ne faut pas supprimer l’en-tête Alt-Svc
    • Il doit continuer à être envoyé comme solution de repli pour les anciens clients et pour les résolveurs ou réseaux qui ne transmettent pas les enregistrements HTTPS
    • Les navigateurs qui lisent les enregistrements HTTPS apprennent la prise en charge de HTTP/3 via le DNS et n’ont donc pas à dépenser un aller-retour pour découvrir HTTP/3

À lire aussi

1 commentaires

 
GN⁺ 4 시간 전
Avis sur Lobste.rs
  • L’hébergeur web ne prend pas encore en charge H3, mais il est possible de tester via une mise à niveau gratuite vers la nouvelle version du serveur
    Une fois cela terminé, il prévoit de configurer les enregistrements DNS HTTPS
  • Le dig d’Apple est en 9.10.6, donc il semble plus ancien que ce type d’enregistrement
    Apple devrait sans doute fournir un dig plus récent, et je me demande quel outil vous préférez pour faire des requêtes DNS sur macOS

    • J’utilise souvent doggo sur plusieurs plateformes
      Ce n’est pas parfait, mais globalement il fonctionne plutôt bien et couvre une bonne partie de ce dont j’ai besoin

    • J’utilise drill de ldns, installé via Homebrew

      % 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
  • Avec un resource record HTTPS, tous les clients qui le lisent établiront une connexion sécurisée
    même sans prise en charge de QUIC
  • Je ne comprends pas pourquoi cet article a le tag vibe coding
    À peu près le seul argument, c’est que le CSS peut donner l’impression d’avoir été généré par un LLM
    • Le commit initial semble clairement avoir été produit avec l’aide d’un LLM : https://github.com/mxinden-bot/savearoundtrip/…
      Et l’article est verbeux. Il y a beaucoup de répétitions, de contenu inutile et de visualisations étranges, au point d’atteindre environ 1 700 mots et plus de 7 300 px de longueur en pleine largeur
      Ce serait bien mieux réduit à 500 mots, 2 diagrammes, et moins de 2 000 px de longueur totale à l’écran