← TCP/IP: fundamentos e diagnóstico
12 / 12 · 60 MIN

Candidatos, fases de falha e escalamento

Analisa tentativas por endereço, distingue fallback sequencial de Happy Eyeballs e prepara um handover baseado no fluxo real.

Localizar a fase que falhou

Organiza a linha temporal em preparação do endereço, tentativa de ligação, aceitação pela aplicação, autenticação e resposta funcional. No laboratório, connect pode terminar antes de o servidor chamar accept para aquela ligação. A observação não mostra autenticação nem persistência. Num serviço fictício de posições, um health check que só liga ao socket pode continuar verde enquanto a aplicação deixa trabalho por aceitar. Não concluas que isto aconteceu em produção sem métricas, mas usa o mecanismo para escolher a observação seguinte: ligação, aceitação, leitura e resultado são marcos diferentes.

Registar cada candidato e o selecionado

O script reserva e liberta uma porta IPv6 local para criar uma tentativa recusada, e depois tenta o listener IPv4 conhecido. Confirma explicitamente ECONNREFUSED e a resposta FALLBACK-OK. Como outra aplicação pode reutilizar a porta libertada, o script falha se a observação esperada não ocorrer; não presume uma reserva permanente. Regista a lista de candidatos, família, endereço, erro e resultado final. Uma tentativa falhada não prova indisponibilidade total quando outra completa a troca. Também não demonstra que IPv6 está avariado em todo o host: os outros grupos IPv6 do mesmo ensaio funcionam.

Limitar o custo e conhecer o algoritmo

A tentativa seguinte recebe apenas o tempo restante do orçamento inicial de dois segundos. Os sockets falhados são fechados e nenhum candidato novo deve começar depois do prazo. O ensaio usa uma lista fornecida e tentativas estritamente sequenciais. Happy Eyeballs, descrito no RFC 8305, inclui resolução, ordenação e tentativas assíncronas escalonadas que podem coexistir. Não apresentes o ciclo didático como implementação completa desse algoritmo. Num cliente real, identifica a biblioteca e a política efetiva antes de prometer latência de fallback ou substituir a seleção por um endereço fixo retirado de um log.

Comparar o contexto que realmente falha

Um teste do host e uma aplicação num network namespace podem ter rotas, dispositivos e regras diferentes. A documentação iproute2 descreve esse isolamento e a gestão de configuração por contexto. Neste bloco, os casos Linux são análise documental; não foram criados namespaces nem executados comandos Linux. Para investigar o caso fictício, pede candidatos resolvidos, origem, rota efetiva e erro dentro do contexto autorizado da aplicação. Não copies rotas do host apenas porque o seu teste funciona. Mesmo uma origem explicitamente ligada por bind não demonstra qual gateway foi escolhido nem que o retorno funciona.

Escrever uma mensagem útil em inglês

Preenche a grelha abaixo para dois eventos: rejeição de um nome com flags numéricas e recusa de ligação a um candidato numérico. Escreve o que foi observado, o impacto, a hipótese ainda aberta e a ação seguinte. Usa getnameinfo com flags numéricas quando a recolha deve preservar endereço e porta sem pedir nomes reversos. Guarda o nome originalmente pedido num campo separado. Este é um exercício proposto ao formando, sem workshop humano realizado. A passagem de turno deve permitir localizar a fase e o endpoint; a expressão genérica connection failed não chega para atribuir responsabilidade técnica.

Aceitar o que a evidência demonstra

Os dez grupos demonstram mecanismos locais de endereço, binding, seleção e correlação. Não medem DNS real, percurso externo, NAT, proxy, PMTU, TLS, carga ou persistência. O facto de ::1 responder rapidamente não estabelece um SLA entre centros de dados. Para a aceitação de um serviço fictício, define uma matriz por família, origem autorizada, endpoint, dependências e resultado funcional. Atribui responsáveis aos ensaios em falta e regista versões do runtime e opções efetivas. Ao reproduzir noutro sistema operativo, compara propriedades sem exigir os mesmos números internos das constantes, portas efémeras ou índices locais.

PROPOSED ENDPOINT HANDOVER WORKSHEET
Requested name/configuration:
Runtime, host and network context:
Candidate list: family | transport | address | port | order
Attempt: phase | local endpoint | remote endpoint | elapsed | exact error
Selected candidate and complete application response:
Observed facts:
Business impact and unresolved hypotheses:
Next authorized collection, owner and next update:
Acceptance matrix: family | source | endpoint | dependency | expected result

Example: Numeric-only address preparation rejected a hostname before connect.
Example: One IPv6 candidate was refused; the IPv4 candidate returned FALLBACK-OK.
Scope: local synthetic observations, not external-path acceptance.
No human workshop has been performed.
NA PRÁTICA

Simulação: o candidato IPv6 é recusado e o IPv4 devolve FALLBACK-OK. Redige um update que explique a disponibilidade parcial e peça a evidência necessária para investigar o candidato degradado.

Armadilhas comuns

Chamar timeout a qualquer erro, concluir falha total após o primeiro candidato, confundir fallback sequencial com Happy Eyeballs ou validar a aplicação apenas com o teste do host.

Tópicos relacionados: Endereços, prefixos e âmbito · Rotas e resolução do próximo salto · Diagnóstico no contexto da aplicação

Leva esta ideia contigo

O diagnóstico segue a fase, o candidato e o contexto. A retoma deve respeitar o orçamento e a aprovação precisa de evidência do percurso representativo.

Criar conta

Referência: Happy Eyeballs Version 2 · DR TCP/IP 2026-09; TCP RFC 9293; IPv6 RFC 8200 with RFC 9673 update; Linux socket and iproute2 guidance