savearoundtrip: Publica registros DNS HTTPS y evita una ida y vuelta

 (savearoundtrip.com)
1 puntos por GN⁺ 4 시간 전 | 1 comentarios | Compartir por WhatsApp
  • Si un sitio web publica compatibilidad con HTTP/3 en registros DNS HTTPS, el navegador puede usar QUIC/HTTP/3 desde la primera conexión y reducir una ida y vuelta de conexión
  • El navegador descubre la compatibilidad con HTTP/3 conectándose primero por HTTP/1 o HTTP/2 para leer el encabezado Alt-Svc, o leyendo registros HTTPS durante la consulta DNS
  • En mediciones de Firefox Nightly, 31.4% de las conexiones anunciaron HTTP/3 solo con el encabezado Alt-Svc; en esos casos, HTTP/3 solo se usa en conexiones posteriores {p:31}
  • Los registros HTTPS incluyen alpn, ech, ipv4hint e ipv6hint, por lo que la selección de protocolo de la primera conexión, ECH y las pistas de direcciones se resuelven dentro de la respuesta DNS
  • Los registros HTTPS se agregan al comportamiento existente para clientes actuales, y Alt-Svc debe mantenerse como fallback para clientes que no reciban el registro

Conceptos clave

  • El navegador descubre si un sitio soporta HTTP/3 de dos maneras
    • Puede conectarse primero por HTTP/1 o HTTP/2 y luego leer el encabezado HTTP Alt-Svc
    • Puede verificarlo directamente en la consulta del registro DNS HTTPS antes de abrir la conexión
  • Solo al usar registros DNS HTTPS el navegador puede usar HTTP/3 desde la primera conexión y ahorrar una ida y vuelta mediante QUIC
  • En estimaciones promedio de builds recientes de Firefox Nightly, el 31.4% de las conexiones anunció HTTP/3 únicamente con el encabezado Alt-Svc, no vía DNS
  • Actualmente, una ida y vuelta hacia este servidor se mide en aproximadamente 28 ms

Verificación de dominio

  • savearoundtrip.com publica por sí mismo un registro HTTPS con h3, pistas de IP y ECH
  • El registro HTTPS del dominio ingresado se consulta desde el navegador a través del endpoint DNS-over-HTTPS de Cloudflare
  • El encabezado Alt-Svc y el handshake HTTP/3 real no pueden verificarse directamente desde el navegador
    • CORS oculta encabezados de origen cruzado
    • El navegador no puede forzar la creación de una conexión QUIC en frío
  • El dominio ingresado se envía a un pequeño backend de código abierto, y ese backend solo verifica Alt-Svc y el handshake HTTP/3 real
  • No se almacenan datos, y el handshake HTTP/3 real se realiza con quic-go

El costo de una ida y vuelta

  • Una ida y vuelta es el proceso de enviar un mensaje al servidor y recibir la respuesta, y está limitada por la velocidad de la luz
  • El tiempo aproximado de ida y vuelta es de 5 a 20 ms dentro de una ciudad, 40 a 80 ms entre países y más de 150 ms a través de océanos o en redes móviles
  • Cloudflare Radar ofrece cifras en tiempo real
  • Las interacciones de menos de unos 100 ms se sienten instantáneas; por encima de eso, ya se perciben como espera
  • Esta página tardó aproximadamente 41 ms desde el inicio de la conexión hasta el primer render, y la ida y vuelta en tiempo real hacia este servidor es de unos 28 ms
  • Un registro HTTPS publicado puede hacer que el navegador use QUIC en lugar de TCP en la primera conexión, reduciendo ese tiempo de ida y vuelta
  • Esta página es estática y pequeña, así que su presupuesto total de tiempo es bajo, pero en aplicaciones reales una ida y vuelta sigue siendo un costo fijo al inicio y puede repetirse en múltiples orígenes

Ida y vuelta desperdiciada

  • Alt-Svc es un encabezado de respuesta HTTP definido en RFC 7838
  • Para leer Alt-Svc, el cliente ya tuvo que abrir una conexión TCP, completar el handshake TLS y terminar una solicitud por HTTP/1.1 o HTTP/2
  • Con este enfoque, el cliente solo se entera de que el servidor también soporta HTTP/3 después de la conexión previa, así que el cambio a HTTP/3 ocurre en la siguiente conexión
  • El registro HTTPS de RFC 9460 pone la misma señal de compatibilidad con HTTP/3 dentro del DNS
  • Como el cliente lee este registro durante la resolución de nombres que ya iba a realizar, puede conocer la compatibilidad con HTTP/3 antes de abrir la conexión
  • Si se usa un registro DNS HTTPS, puede emplearse QUIC/HTTP/3 desde la primera conexión sin tener que gastar antes una conexión HTTP/1 o HTTP/2

Por qué el registro HTTPS es mejor

  • Descubrimiento de HTTP/3 antes del primer byte

    • El SvcParam alpn enumera los identificadores de protocolo ALPN que soporta el endpoint
    • Ejemplos son h3 para HTTP/3 y h2
    • Como esta información llega durante la resolución de nombres, el cliente puede elegir QUIC desde la primera conexión en lugar de descubrir h3 después de una conexión previa por HTTP/1 o HTTP/2

  • ECH: Client Hello cifrado

    • El SvcParam ech contiene la clave pública ECHConfigList del endpoint
    • ECH cifra el TLS ClientHello, incluido el nombre del servidor en SNI, para que observadores de la red no puedan ver qué sitio se visita
    • Esto no puede resolverse con encabezados HTTP porque la clave pública se necesita antes de enviar el primer ClientHello
    • Como la clave se requiere antes de que exista cualquier conexión, solo un canal fuera de banda como el registro HTTPS en DNS puede inicializar ECH
    • Sin HTTPS RR, ECH tampoco puede usarse

  • Inicio de conexión más rápido con pistas de IP

    • Happy Eyeballs v3 realiza consultas A, AAAA y HTTPS en paralelo
    • ipv4hint e ipv6hint dentro de la respuesta HTTPS proporcionan direcciones candidatas cuando llegan antes que los registros A/AAAA
    • El cliente puede comenzar a conectarse usando las direcciones sugeridas en lugar de esperar la respuesta A/AAAA
    • Los registros A/AAAA siguen llegando y reemplazan las pistas una vez disponibles
    • Alt-Svc no tiene una función equivalente

  • Una sola fuente autoritativa y cacheo

    • La información de alcanzabilidad puede permanecer dentro del DNS con TTL normal
    • Con Alt-Svc, la información queda dispersa en cachés de encabezados HTTP por origen y aparece el dilema de max-age
    • Si max-age es demasiado largo, el cliente usa alternativas desactualizadas; si es demasiado corto, vuelve más seguido al protocolo anterior
    • Como el navegador igual tiene que hacer una consulta DNS, el registro HTTPS permite que esa consulta entregue también la información óptima para la conexión

  • Comparación de funciones

    • | Función | Encabezado HTTP Alt-Svc (RFC 7838) | HTTPS RR (RFC 9460) |
    • | --- | --- | --- |
    • | Momento de aprendizaje | Después de completar la conexión | Durante la resolución DNS |
    • | h3 en la primera conexión | No | Sí |
    • | Pistas de IP | No aplica | ipv4hint / ipv6hint |
    • | Clave ECH | Imposible | Parámetro ech |
    • | Fuente de verdad | Encabezados HTTP y caché frágil | DNS con TTL |

Medición real en navegadores

  • En mediciones de Firefox Nightly, el navegador puede conocer la compatibilidad con HTTP/3 mediante el encabezado de respuesta HTTP Alt-Svc o mediante el registro DNS HTTPS
  • Alt-Svc solo se ve después de conectarse, mientras que el registro DNS HTTPS se ve antes de abrir la conexión
  • Todas las conexiones pertenecen a uno de cuatro grupos
    • Neither corresponde a conexiones donde no se anunció HTTP/3 en absoluto
    • Alt-Svc only corresponde a conexiones anunciadas solo por encabezado, donde no fue posible usar HTTP/3 en la primera conexión
    • HTTPS record only corresponde a conexiones anunciadas por DNS, que podían ir por HTTP/3 desde la primera conexión
    • Both corresponde a conexiones anunciadas tanto por DNS como por encabezado
  • La proporción de conexiones medidas fue: Neither 59.8%, Alt-Svc only 31.4%, HTTPS record only 2.8% y Both 6% {b:60,31,3,6}
  • Los cuatro grupos cubren el total de conexiones, así que suman 100%
  • HTTPS record only y Both tenían un registro HTTPS utilizable, mientras que Alt-Svc only representa el espacio que podría haberse ahorrado si ese registro hubiera existido
  • Las cifras son estimaciones por conexión reconstruidas a partir de histogramas GLAM de Firefox Nightly, por lo que son aproximadas

Publicar un registro HTTPS

  • Un registro HTTPS en ServiceMode que anuncie h3 y pistas de dirección puede publicarse en una sola línea
; zone file (BIND-style)
example.com.  3600  IN  HTTPS 1 . alpn="h3,h2" ipv4hint=203.0.113.10 ipv6hint=2001:db8::10
  • example.com. es el nombre que publica el registro, y el punto final indica un nombre de dominio completamente calificado
  • 3600 es el TTL en segundos durante el cual un resolvedor puede almacenar en caché el registro
  • IN es la clase DNS de Internet, igual que en otros registros web
  • HTTPS es el tipo de registro definido por RFC 9460
  • 1 es la prioridad; valores de 1 o más indican ServiceMode, que contiene parámetros
  • 0 indica AliasMode, que solo apunta a otro destino
  • . es el host objetivo y significa el propio nombre del propietario, es decir example.com
  • alpn="h3,h2" enumera los protocolos soportados por el servidor en orden preferido; h3 es HTTP/3 y h2 es HTTP/2
  • ipv4hint e ipv6hint son direcciones con las que el cliente puede iniciar la conexión de inmediato junto con las consultas A/AAAA
  • La mayoría de los proveedores DNS administrados, como Cloudflare y Route 53, ofrecen directamente el tipo de registro HTTPS
  • Puedes verificar si un dominio lo soporta con el checker

Qué funciones incluyen realmente los registros HTTPS

  • En Firefox Nightly se midió qué proporción de las conexiones que vieron un registro HTTPS incluía cada función
  • h3 dentro de ALPN fue 80.3%, e IPv4 hint fue 52.9%
  • IPv6 hint fue 49.4%, y ECH fue 12.8% {b:80,53,49,13}
  • Estas cifras también son estimaciones por conexión reconstruidas a partir de histogramas GLAM, así que son aproximadas

FAQ

  • Si el CDN lo publica automáticamente

    • Algunos CDN publican registros HTTPS automáticamente
    • Cloudflare ofrece automáticamente registros HTTPS con alpn="h3" para zonas proxied
    • En otros CDN, el usuario debe configurarlo manualmente
    • La forma más rápida de comprobarlo es usar la verificación de dominio de arriba

  • Si el registro HTTPS rompe clientes antiguos

    • Los clientes que no entienden registros HTTPS los ignoran y vuelven a consultas A/AAAA normales
    • Si todavía envías el encabezado Alt-Svc, esos clientes también pueden usarlo
    • Publicar un registro HTTPS es una adición al comportamiento existente

  • Qué pasa en visitas repetidas

    • Después de que un cliente se comunica una vez por HTTP/3, en visitas repetidas puede reanudar la conexión QUIC con 0-RTT
    • Con 0-RTT, la primera solicitud puede enviarse de inmediato sin una ida y vuelta de handshake
    • El propio registro HTTPS también se almacena en caché durante su TTL como cualquier otra respuesta DNS, así que en una revisita normalmente también se omite la consulta

  • Qué navegadores usan registros HTTPS

    • Los motores principales soportan registros HTTPS habilitados por defecto
    • Leen el registro sin importar si el visitante activó DNS-over-HTTPS o no
    • Safari usa el resolvedor del sistema operativo
    • Chrome usa su propio resolvedor integrado, ya sea vía DoH o DNS normal
    • Firefox puede usar ambos métodos

  • Si se debe eliminar el encabezado Alt-Svc

    • No se debe eliminar el encabezado Alt-Svc
    • Debe seguir enviándose como fallback para clientes antiguos y para resolvedores o redes que no entreguen registros HTTPS
    • Los navegadores que leen registros HTTPS aprenden sobre HTTP/3 desde DNS y evitan gastar una ida y vuelta para descubrirlo

Lecturas relacionadas

1 comentarios

 
GN⁺ 4 시간 전
Comentarios en Lobste.rs
  • El proveedor de hosting web todavía no soporta H3, pero se puede probar con una actualización gratis a una nueva versión del servidor
    Cuando termine, planeo configurar el registro DNS HTTPS
  • El dig de Apple es 9.10.6, así que parece ser una versión anterior a este tipo de registro
    Apple debería ofrecer un dig más reciente, y me pregunto si hay alguna herramienta preferida para hacer consultas DNS en macOS

    • Me gusta usar doggo en varias plataformas
      No es perfecto, pero en general me ha funcionado bastante bien y cubre muchas de las funciones que necesito

    • Uso drill de ldns, instalado con 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
  • Si existe un registro de recurso HTTPS, cualquier cliente que lo lea se conectará de forma segura
    Incluso si no soporta QUIC
  • No entiendo por qué esta publicación tiene la etiqueta vibecoding
    Casi todo se reduce a que el CSS podría parecer salido de un LLM
    • El commit inicial sí parece claramente generado con un LLM: https://github.com/mxinden-bot/savearoundtrip/…
      Y además el texto es verboso. Tiene mucha repetición, contenido inútil y visualizaciones raras, así que con unas 1700 palabras la página completa supera los 7300 px de largo a ancho completo
      Quedaría mucho mejor si se redujera a unas 500 palabras, 2 diagramas y menos de 2000 px de largo total