savearoundtrip: publique registros DNS HTTPS e elimine uma ida e volta

 (savearoundtrip.com)
1 pontos por GN⁺ 4 시간 전 | 1 comentários | Compartilhar no WhatsApp
  • Se um site publicar suporte a HTTP/3 em registros DNS HTTPS, o navegador poderá usar QUIC/HTTP/3 já na primeira conexão, reduzindo em 1 ida e volta do estabelecimento da conexão
  • O navegador pode descobrir o suporte a HTTP/3 conectando primeiro via HTTP/1 ou HTTP/2 e lendo o cabeçalho Alt-Svc, ou lendo o registro HTTPS já na etapa de consulta DNS
  • Em medições do Firefox Nightly, 31,4% das conexões anunciavam HTTP/3 apenas pelo cabeçalho Alt-Svc; nesses casos, o HTTP/3 só é usado em conexões posteriores {p:31}
  • Os registros HTTPS podem incluir alpn, ech, ipv4hint e ipv6hint, permitindo tratar no próprio retorno DNS a escolha de protocolo da primeira conexão, ECH e dicas de endereço
  • Os registros HTTPS funcionam como um acréscimo para clientes existentes, e o Alt-Svc deve ser mantido como fallback para clientes que não receberem o registro

Conceitos principais

  • O navegador descobre o suporte a HTTP/3 de um site de duas formas
    • conectando primeiro via HTTP/1 ou HTTP/2 e então lendo o cabeçalho HTTP Alt-Svc
    • verificando diretamente na consulta ao registro DNS HTTPS antes de abrir a conexão
  • Só com registros DNS HTTPS o navegador pode usar HTTP/3 já na primeira conexão, reduzindo em 1 ida e volta por meio do QUIC
  • Em uma estimativa média de builds recentes do Firefox Nightly, 31,4% das conexões anunciavam HTTP/3 apenas pelo cabeçalho Alt-Svc, e não via DNS
  • Atualmente, uma ida e volta até este servidor é medida em cerca de 28 ms

Verificação de domínio

  • savearoundtrip.com publica por conta própria um registro HTTPS com h3, dicas de IP e ECH
  • O registro HTTPS do domínio informado é consultado no navegador por meio do endpoint DNS-over-HTTPS da Cloudflare
  • O cabeçalho Alt-Svc e o handshake HTTP/3 real não podem ser verificados diretamente no navegador
    • o CORS oculta cabeçalhos de origem cruzada
    • o navegador não pode forçar a criação de uma conexão QUIC fria
  • O domínio informado é enviado para um pequeno backend open source, que só faz a verificação de Alt-Svc e do handshake HTTP/3 real
  • Os dados não são armazenados, e o handshake HTTP/3 real é feito com quic-go

O custo de uma ida e volta

  • Uma ida e volta é o processo de enviar uma mensagem ao servidor e receber a resposta, limitado pela velocidade da luz
  • Aproximadamente, o tempo de ida e volta fica entre 5 e 20 ms dentro de uma cidade, 40 e 80 ms entre países, e acima de 150 ms em travessias oceânicas ou redes móveis
  • O Cloudflare Radar fornece números em tempo real
  • Interações abaixo de cerca de 100 ms parecem imediatas; acima disso, já dão sensação de espera
  • Esta página levou cerca de 41 ms do início da conexão até a primeira pintura, e a ida e volta em tempo real até este servidor é de cerca de 28 ms
  • Um registro HTTPS publicado permite que o navegador use QUIC em vez de TCP já na primeira conexão, reduzindo esse tempo de ida e volta
  • Esta página é estática e pequena, então o orçamento total de tempo também é pequeno, mas em apps reais uma ida e volta continua sendo um custo fixo pago logo na entrada e que pode se repetir em várias origens

Ida e volta desperdiçada

  • Alt-Svc é um cabeçalho de resposta HTTP definido na RFC 7838
  • Para ler Alt-Svc, o cliente já precisou abrir uma conexão TCP, concluir o handshake TLS e terminar a requisição via HTTP/1.1 ou HTTP/2
  • Nesse modelo, o cliente só descobre que o servidor também suporta HTTP/3 depois da conexão anterior, então o upgrade para HTTP/3 acontece apenas na conexão seguinte
  • O registro HTTPS da RFC 9460 coloca o mesmo sinal de suporte a HTTP/3 no DNS
  • Como o cliente lê esse registro durante a resolução de nome que já faria de qualquer forma, ele pode saber do suporte a HTTP/3 antes de abrir a conexão
  • Ao usar registros DNS HTTPS, é possível usar QUIC/HTTP/3 já na primeira conexão, sem consumir antes uma conexão HTTP/1 ou HTTP/2

Por que registros HTTPS são melhores

  • Descoberta de HTTP/3 antes do primeiro byte

    • O SvcParam alpn lista os IDs de protocolo ALPN suportados pelo endpoint
    • Exemplos incluem h3, de HTTP/3, e h2
    • Como essa informação chega durante a resolução de nome, o cliente pode escolher QUIC já na primeira conexão, em vez de descobrir h3 só depois de uma conexão HTTP/1 ou HTTP/2 anterior

  • ECH: Client Hello criptografado

    • O SvcParam ech carrega a chave pública ECHConfigList do endpoint
    • O ECH criptografa o TLS ClientHello, incluindo o nome do servidor no SNI, para que observadores de rede não consigam ver qual site está sendo acessado
    • Isso não pode ser resolvido com cabeçalhos HTTP, porque a chave pública é necessária antes do envio do primeiro ClientHello
    • Como a chave é necessária quando ainda não existe conexão, só um canal fora de banda como o registro HTTPS no DNS pode inicializar o ECH
    • Sem HTTPS RR, também não há ECH

  • Início de conexão mais rápido com dicas de IP

    • O Happy Eyeballs v3 faz consultas A, AAAA e HTTPS em paralelo
    • ipv4hint e ipv6hint dentro da resposta HTTPS fornecem endereços candidatos para conexão quando chegam antes dos registros A/AAAA
    • O cliente pode começar a conexão usando esses endereços de dica, em vez de esperar pelas respostas A/AAAA
    • Os registros A/AAAA continuam chegando e substituem as dicas quando disponíveis
    • Alt-Svc não tem nada equivalente

  • Fonte única de autoridade e cache

    • As informações de alcançabilidade podem permanecer no DNS com TTL normal
    • Na abordagem com Alt-Svc, as informações ficam espalhadas em caches de cabeçalhos HTTP por origem, criando o dilema do max-age
    • Se o max-age for longo demais, o cliente usa alternativas desatualizadas por mais tempo; se for curto demais, volta com mais frequência ao protocolo anterior
    • Como os navegadores já fazem consulta DNS de qualquer forma, registros HTTPS permitem que essa consulta também entregue informações ideais de conexão

  • Comparação de recursos

    • | Recurso | Cabeçalho HTTP Alt-Svc (RFC 7838) | HTTPS RR (RFC 9460) |
    • | --- | --- | --- |
    • | Momento da descoberta | Depois da conexão completa | Durante a resolução DNS |
    • | h3 na primeira conexão | Não | Sim |
    • | Dicas de IP | Não se aplica | ipv4hint / ipv6hint |
    • | Chave ECH | Impossível | parâmetro ech |
    • | Fonte da verdade | Cabeçalhos HTTP e cache frágil | DNS com TTL |

Medições reais em navegadores

  • Nas medições do Firefox Nightly, o navegador pode descobrir suporte a HTTP/3 pelo cabeçalho de resposta HTTP Alt-Svc ou por um registro DNS HTTPS
  • Alt-Svc só aparece depois que a conexão já foi feita, enquanto o registro DNS HTTPS aparece antes da conexão
  • Todas as conexões se encaixam em um dos quatro grupos
    • Neither: conexões em que HTTP/3 não era anunciado de forma alguma
    • Alt-Svc only: conexões anunciadas apenas por cabeçalho, sem possibilidade de usar HTTP/3 já na primeira conexão
    • HTTPS record only: conexões anunciadas via DNS, podendo usar HTTP/3 desde a primeira conexão
    • Both: conexões anunciadas tanto no DNS quanto no cabeçalho
  • A distribuição medida foi: Neither 59,8%, Alt-Svc only 31,4%, HTTPS record only 2,8% e Both 6% {b:60,31,3,6}
  • Os quatro grupos cobrem todas as conexões, portanto a soma é 100%
  • HTTPS record only e Both tinham registros HTTPS utilizáveis, enquanto Alt-Svc only representa a lacuna que poderia ter sido eliminada se houvesse registro
  • Os números são estimativas por conexão reconstruídas a partir de histogramas GLAM do Firefox Nightly e representam uma média aproximada de builds recentes

Publicando um registro HTTPS

  • Um registro HTTPS em ServiceMode que anuncia h3 e dicas de endereço pode ser publicado em uma única linha
; zone file (BIND-style)
example.com.  3600  IN  HTTPS 1 . alpn="h3,h2" ipv4hint=203.0.113.10 ipv6hint=2001:db8::10
  • example.com. é o nome que publica o registro; o ponto final indica um nome de domínio totalmente qualificado
  • 3600 é o TTL, em segundos, durante o qual resolvedores podem armazenar o registro em cache
  • IN é a classe de DNS da internet, igual à dos demais registros web
  • HTTPS é o tipo de registro definido na RFC 9460
  • 1 é a prioridade; valores 1 ou maiores indicam ServiceMode com parâmetros
  • 0 indica AliasMode, que apenas aponta para outro destino
  • . é o host de destino e significa o próprio nome do proprietário, example.com
  • alpn="h3,h2" lista os protocolos suportados pelo servidor em ordem de preferência; h3 é HTTP/3 e h2 é HTTP/2
  • ipv4hint e ipv6hint são endereços que permitem ao cliente iniciar a conexão imediatamente junto com as consultas A/AAAA
  • A maioria dos provedores de DNS gerenciado, como Cloudflare e Route 53, oferece diretamente o tipo de registro HTTPS
  • O suporte do domínio pode ser verificado no checker

O que os registros HTTPS reais carregam

  • No Firefox Nightly, foi medida a proporção de conexões que, ao ver um registro HTTPS, continham cada recurso
  • O h3 em ALPN apareceu em 80,3% dos casos, e a dica IPv4 em 52,9%
  • A dica IPv6 apareceu em 49,4%, e ECH em 12,8% {b:80,53,49,13}
  • Esses números são estimativas por conexão reconstruídas a partir de histogramas GLAM, portanto são aproximados

FAQ

  • O CDN publica isso automaticamente?

    • Alguns CDNs publicam registros HTTPS automaticamente
    • A Cloudflare fornece automaticamente um registro HTTPS com alpn="h3" para zonas com proxy ativado
    • Em outros CDNs, o usuário precisa configurar manualmente
    • A forma mais rápida de verificar é usar a verificação de domínio acima

  • Registros HTTPS quebram clientes antigos?

    • Clientes que não entendem registros HTTPS simplesmente os ignoram e voltam às consultas normais A/AAAA
    • Se você ainda estiver enviando o cabeçalho Alt-Svc, esses clientes também poderão usá-lo
    • Publicar registros HTTPS é uma adição ao comportamento existente

  • E em revisitas?

    • Depois que o cliente usa HTTP/3 uma vez, ele pode retomar a conexão QUIC em revisitas com 0-RTT
    • Com 0-RTT, a primeira requisição pode ser enviada imediatamente, sem uma ida e volta de handshake
    • O próprio registro HTTPS também fica em cache pelo TTL, como outras respostas DNS, então em revisitas normalmente a consulta também é evitada

  • Quais navegadores usam registros HTTPS?

    • Os principais engines já oferecem suporte a registros HTTPS com ativação padrão
    • Eles leem o registro independentemente de o visitante ter ativado DNS-over-HTTPS ou não
    • O Safari usa o resolvedor do sistema operacional
    • O Chrome usa um resolvedor interno próprio e funciona via DoH ou DNS comum
    • O Firefox pode usar ambos os métodos

  • Devo remover o cabeçalho Alt-Svc?

    • O cabeçalho Alt-Svc não deve ser removido
    • Ele deve continuar sendo enviado como fallback para clientes antigos e para resolvedores ou redes que não entreguem registros HTTPS
    • Navegadores que leem registros HTTPS descobrem o HTTP/3 pelo DNS e deixam de gastar uma ida e volta para descobrir o suporte a HTTP/3

Leituras relacionadas

1 comentários

 
GN⁺ 4 시간 전
Opiniões no Lobste.rs
  • A hospedagem web ainda não oferece suporte a H3, mas é possível testar com um upgrade gratuito para uma nova versão do servidor
    Quando terminar, pretendo configurar o registro DNS HTTPS
  • O dig da Apple é 9.10.6, então parece ser mais antigo que esse tipo de registro
    A Apple provavelmente deveria fornecer um dig mais atualizado, e fiquei curioso para saber se existe alguma ferramenta preferida para consultas DNS no macOS

    • Gosto de usar o doggo em várias plataformas
      Não é perfeito, mas no geral funcionou muito bem e cobre boa parte do que eu preciso

    • Uso o drill do ldns instalado 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
  • Se houver um registro de recurso HTTPS, qualquer cliente que o leia fará uma conexão segura
    Isso vale mesmo sem suporte a QUIC
  • Não entendi por que este post recebeu a tag vibe coding
    Quase tudo se resume a que o CSS talvez pareça ter saído de um LLM
    • O commit inicial claramente parece ter sido criado com um LLM: https://github.com/mxinden-bot/savearoundtrip/…
      E o texto é prolixo. Há muita repetição, conteúdo inútil e visualizações estranhas, então com cerca de 1700 palavras a página em largura total passa de 7300px
      Ficaria bem melhor se fosse reduzido para algo como 500 palavras, 2 diagramas e menos de 2000px de comprimento total