Resumo

  • Happy Eyeballs protege o usuário tentando alternativas sem esperar demais por uma família lenta ou defeituosa. Esse desenho pode manter o sucesso agregado verde enquanto o IPv6 falha.
  • A evidência precisa ser separada por família: respostas DNS, candidatos, tentativas, família vencedora, erros perdedores e testes forçados em grupos de acesso representativos.

Considere um cenário explicitamente hipotético. O monitor principal está verde, as transações continuam e o suporte não recebe relatos. Uma segunda sonda, forçada a usar IPv6 em uma rede de acesso específica, não conecta. As duas observações podem ser verdadeiras. O cliente comum recebeu A e AAAA, iniciou IPv6 e depois estabeleceu IPv4 rápido o bastante para o usuário notar pouco atraso.

Isto não descreve uma interrupção de um operador identificado. Expõe um limite de medição. O sucesso de uma transação prova que algum caminho funcionou, não que todas as famílias anunciadas estavam saudáveis.

O RFC 8305 define Happy Eyeballs v2 para reduzir demora percebida quando endereços ou famílias estão bloqueados, quebrados ou abaixo do ideal. O cliente consulta A e AAAA de modo assíncrono, ordena destinos, escalona tentativas e mantém a conexão bem-sucedida, cancelando as demais. Em geral prefere IPv6, mas a meta imediata é continuidade.

Os tempos recomendados ajudam a entender a ocultação. O RFC sugere 50 ms de espera de resolução e 250 ms entre tentativas sem histórico de RTT. Implementações podem adaptar valores e usar desempenho anterior. Não são garantias universais. O fato estável é a corrida: sem telemetria das tentativas perdedoras, a conexão vencedora diz pouco sobre a falha.

O RFC 6724 acrescenta a seleção de endereços de origem e destino entre IPv6 e IPv4 e permite política administrativa diferente. Dois dispositivos consultando o mesmo nome podem ordenar candidatos e seguir caminhos distintos conforme escopo, origem disponível, configuração ou conhecimento de conectividade.

Uma taxa HTTP agregada reduz tudo a um bit. Ela não informa se AAAA chegou, qual IPv6 foi tentado, quanto esperou ou se a falha ocorreu em DNS, descoberta de vizinhos, rota, filtro, MTU de caminho ou serviço. Também não distingue preferência deliberada por IPv4 de resgate.

O registro mínimo guarda respostas A/AAAA e horários, candidatos ordenados, famílias de origem e destino, início e fim de cada tentativa, erro ou timeout perdedor, família vencedora, resolvedor, ASN ou grupo de acesso, edge, resultado da aplicação, implementação e momento. Fallback sozinho não prova a causa.

Combine o teste dual stack normal com sondas forçadas em IPv6 e IPv4. O primeiro protege a jornada do cliente; as demais verificam cada superfície. Dual stack com sucesso e IPv6 forçado com falha significa “disponível, porém degradado”, não “totalmente saudável”.

Fontes