Resumo

  • O RFC 6555 descreveu em 2012 uma disputa curta entre famílias de endereços; o RFC 8305 substituiu essa ideia em 2017 por um agendador que combina DNS assíncrono, ordenação, tentativas espaçadas e cancelamento.
  • O intervalo recomendado de 250 ms distribui custo entre a espera percebida e a carga de conexões especulativas; reduzi-lo não é gratuito.
  • O mecanismo contorna falhas iniciais de TCP/IP, mas não corrige a aplicação nem a rota perdedora e pode prolongar dependência de IPv4.

O problema que originou Happy Eyeballs era uma contradição prática. Um host dual stack podia receber destinos IPv6 e IPv4, respeitar a preferência arquitetural por IPv6 e ainda oferecer uma experiência pior quando esse caminho estivesse lento ou quebrado. Publicado como Proposed Standard em abril de 2012, o RFC 6555 decidiu que a pessoa não deveria pagar, em silêncio, todo o tempo dessa transição.

Seu algoritmo de exemplo preservava a ordem de preferência do host. A primeira conexão era iniciada; após um intervalo curto, começava a primeira tentativa da outra família. Firefox e Chrome usavam 300 ms. A conexão estabelecida primeiro era mantida e a concorrente descartada. Sem histórico, IPv6 continuava preferido. O texto também alertava contra criar carga IPv4 desnecessária ao longo de uma transição que seria extensa.

O temporizador funcionava como preço do risco. Se fosse longo, a falha do caminho preferido continuaria visível para o usuário. Se fosse curto, até conexões saudáveis tenderiam a produzir uma segunda tentativa, consumindo pacotes, estado e processamento do servidor. Menos latência de cauda exigia mais trabalho redundante.

A experiência de implantação mostrou que o caso real não cabia em dois endereços e um cronômetro. Em dezembro de 2017, o RFC 8305, também Proposed Standard, tornou o RFC 6555 obsoleto e definiu quatro etapas articuladas: consultas DNS assíncronas, ordenação de todos os destinos, tentativas assíncronas lançadas em intervalos e retenção de um sucesso com cancelamento das demais.

O DNS participa da decisão. O RFC 8305 recomenda enviar AAAA primeiro e A logo em seguida, sem esperar a primeira consulta terminar. Se A responder antes, um Resolution Delay recomendado de 50 ms dá a AAAA uma oportunidade breve. A primeira resposta não precisa congelar a lista: novos resultados que cheguem durante o estabelecimento podem ser incorporados.

Depois vem a ordem dos destinos. As regras de seleção de endereço formam a base, mas a implementação pode considerar RTT histórico ou uso anterior na mesma rede. As famílias são intercaladas, impedindo que vários endereços quebrados de uma só família esgotem a fila antes que uma alternativa viável seja testada. O histórico precisa respeitar o contexto de rede; o que funcionou numa rede não vira verdade universal.

O Connection Attempt Delay padrão recomendado é 250 ms. O RFC 8305 recomenda mínimo de 100 ms, determina que nunca fique abaixo de 10 ms e recomenda máximo de dois segundos. O First Address Family Count recomendado é um. Esses números nasceram de medições empíricas e podem ser ajustados conforme redes e dispositivos mudem. Um intervalo menor compra resposta mais rápida com paralelismo; um maior poupa carga, mas expõe a escolha errada por mais tempo.

O escopo inclui múltiplos endereços, respostas DNS que mudam durante a tentativa, informação histórica e redes somente IPv6 com NAT64/DNS64. O limite também é explícito: Happy Eyeballs trata da falha inicial de conexão TCP/IP. Uma conexão de transporte pode terminar numa aplicação inoperante. A corrida não repara o caminho que perdeu.

Esse limite cria um problema de observabilidade. O RFC 6555 já reconhecia que a disputa dificultaria diagnosticar falhas por família. O RFC 8305 mantém a preocupação, inclusive com problemas operacionais como MTU de caminho que podem ficar escondidos atrás de outra rota. Para a pessoa, o serviço funcionou. Para quem opera a infraestrutura, talvez tenha desaparecido a reclamação que justificaria investigar.

Happy Eyeballs é, portanto, um acordo de compatibilidade. O cliente gasta um pouco de capacidade para preservar a preferência por IPv6 sem transformar usuários em cobaias. Ao mesmo tempo, IPv4 permanece como seguro, junto com seus endereços escassos e custos. Seguro muda incentivos: quando o fallback é rápido, uma rota IPv6 ruim gera menos pressão; quando IPv4 vence sempre, a dependência se consolida. O algoritmo administra a transição, mas não define seu fim.