Resumo

  • As RFCs 9621–9623 permitem que o aplicativo declare limites rígidos e preferências flexíveis; a implementação combina isso com política do sistema, histórico em cache e candidatos disponíveis naquele contexto.
  • Ready confirma que uma pilha elegível foi estabelecida. Não revela a árvore de candidatos, a preferência sacrificada, o dado histórico que alterou a ordem nem o resultado recebido pelo usuário.

O problema não era o celular ter funcionado. O problema era uma organização ter tratado “preferir Wi-Fi” como “proibir dados tarifados”. Na linguagem da RFC 9622, essas duas intenções têm efeitos diferentes.

Require mantém somente candidatos que oferecem uma propriedade; se nenhum existir, a conexão falha. Prohibit exclui todos os candidatos com a propriedade proibida. Prefer e Avoid mudam a ordem, mas deixam a implementação prosseguir quando o ideal não está disponível. No Preference entrega ainda mais espaço à política local.

A implementação precisa respeitar todos os requisitos e proibições. Ela não promete que toda preferência vencerá. A própria RFC admite resultados distintos quando mudam sistema, caminho, protocolo ou contexto.

Essa semântica é o ponto de partida de um modelo maior. A RFC 9621 define uma arquitetura em que o aplicativo recebe uma Connection abstrata e descreve o serviço de transporte desejado. A RFC 9623 orienta a implementação a reunir caminhos, pilhas de protocolo e representações do destino, classificá-los e disputar o estabelecimento.

O ganho é poder trocar e evoluir mecanismos sem reescrever cada aplicação. A consequência é que a decisão sai do código visível do produto e entra numa camada que precisa de outro tipo de prova.

O rótulo da interface não fecha a conta

Wi-Fi não prova rede gratuita. Celular não prova preço alto. Uma rede corporativa sem fio pode ter gargalo e vigilância; uma conexão móvel pode fazer parte de um plano já contratado. A RFC 9622 alerta que o tipo de interface não deve substituir propriedades como acesso medido ou não medido.

Quando custo é apenas uma preferência, continuidade pode prevalecer. Quando custo é uma fronteira contratual, ele precisa ser requisito, proibição ou verificação posterior. A escolha tem efeito econômico: endurecer a regra reduz exposição financeira, mas também elimina alternativas durante uma falha.

O mesmo vale para privacidade, proxy, ordenação de mensagens e segurança. Uma palavra de intensidade decide quem tem autoridade para ceder diante da indisponibilidade.

Três políticas chegam à mesma conexão

O aplicativo não decide sozinho. A RFC 9623 distingue preferências da aplicação, System Policy dinâmica e política padrão da implementação. O administrador pode bloquear uma interface para um processo. O sistema pode favorecer uma rede segundo condições atuais. A implementação usa padrões quando o aplicativo não especifica uma propriedade.

O candidato escolhido deve atender às restrições de todas essas fontes. Se a política bloquear a ação, um motivo como PolicyProhibited pode ser retornado. Porém, a RFC 9621 não define uma forma portátil de ler ou alterar System Policy, pois sua configuração é específica da plataforma.

Assim, a intenção pode ser portátil sem que a justificativa também seja. Um Ready bem-sucedido não traz, necessariamente, versão da política, candidatos avaliados ou pesos. Dois dispositivos com o mesmo código podem escolher pilhas diferentes e continuar corretos.

Não é preciso centralizar a política para corrigir isso. É suficiente separar o contrato comum — requisitos, proibições e falhas — do recibo local da decisão.

A árvore decide antes da corrida

Segundo a RFC 9623, a ramificação deve ocorrer primeiro por caminho de rede, depois por opções de protocolo e, por fim, por destinos derivados. Essa precedência evita combinações inválidas, mas também muda como preferências interagem.

No exemplo da RFC, o aplicativo prefere Wi-Fi e uma capacidade que leva a preferir SCTP. Se o histórico indica que SCTP não está disponível no Wi-Fi, o ramo Wi-Fi pode conter TCP, enquanto LTE contém SCTP e TCP. Como o caminho é priorizado antes do protocolo, Wi-Fi/TCP pode ser tentado antes de LTE/SCTP.

Não houve soma neutra de pontos. Houve uma árvore. Registrar somente “Wi-Fi venceu” apaga por que SCTP ficou fora daquele ramo, que candidato foi podado e qual preferência teve precedência.

A árvore também muda conforme a rede. Interfaces distintas podem resolver um nome de maneiras diferentes. Um proxy altera destino e porta. Um protocolo pode existir em um caminho e faltar em outro. A lista de candidatos precisa ser registrada com tempo e contexto.

A alternativa mais rápida ainda precisa ser legítima

A RFC 9623 descreve corridas simultâneas, escalonadas e por falha. Iniciar tudo ao mesmo tempo pode reduzir atraso, mas consome recursos e deixa estados sem uso; por isso não deve ser o padrão. O modo escalonado inicia alternativas após intervalos. O modo por falha espera a opção preferida fracassar.

Se um proxy tem função de controle, disputar agressivamente contra o caminho direto pode contorná-lo apenas porque o segundo respondeu alguns milissegundos antes. Nesse caso, falha controlada ou uma restrição rígida é coerente com a autoridade da política.

A RFC 8305 oferece o modelo conhecido de Happy Eyeballs para famílias de endereços. TAPS amplia a disputa a interfaces, protocolos e destinos. “Primeiro a chegar” só é seguro dentro de um conjunto corretamente admitido.

A RFC 8922 integra requisitos de segurança ao serviço de transporte. A RFC 9623 alerta que um atacante pode bloquear a primeira tentativa e induzir a segunda. Se a segunda for menos segura, a corrida cria incentivo ao rebaixamento. Candidatos concorrentes devem conservar requisitos rígidos e equivalência de segurança aceita.

O cache vota com fatos antigos

O sistema pode guardar DNS, estado de sessão TLS, cookies TCP Fast Open, RTT, latência de estabelecimento e taxa de sucesso. A RFC 9040 dá o contexto para compartilhamento de informações de controle TCP. Esses dados ordenam ou eliminam candidatos futuros.

A vantagem é não redescobrir tudo a cada conexão. O risco é transformar uma observação vencida numa preferência automática. Um caminho reparado pode continuar punido por falhas antigas; um vencedor frequente recebe mais amostras e reforça sua própria posição.

Há também um limite de privacidade. Contextos de conexão separados impedem que tickets, caches ou multiplexação revelem que atividades distintas pertencem à mesma origem. Um recibo responsável guarda namespace, tipo de observação, idade e regra de expiração, não o segredo bruto.

O alcance de Ready

Para a RFC 9623, o estabelecimento termina quando ao menos uma pilha consegue enviar e receber dados da aplicação. A RFC 9622 expõe a transição como Ready. Isso prova que uma pilha local elegível foi estabelecida e deve respeitar os limites rígidos.

Não prova que cada preferência venceu, que o destino processou uma mensagem, que a cobrança esperada foi evitada ou que a pessoa recebeu o serviço. Esses recibos pertencem a etapas posteriores.

A RFC 9623 cita Network.framework da Apple, NEAT, NEATPy e PyTAPS como implementações alinhadas em algum grau. A documentação Network da Apple mostra uma API real que combina protocolos e restrições de caminho. A referência não certifica conformidade total nem observabilidade igual em todas elas.

Fontes