Resumo

  • A RFC 2391 colocou um conjunto de servidores atrás de um endereço virtual e transformou a escolha de cada nova sessão em parâmetros persistentes de tradução.
  • Rodízio, contagem de sessões, tráfego, pesos, custo de rota e sondas de vida eram aproximações para decidir, não comprovantes de capacidade real ou sucesso da aplicação.
  • Tirar um host morto das próximas escolhas evitava novas perdas, mas não movia as sessões já vinculadas: prevenção e failover eram mecanismos diferentes.

O endereço simples e a decisão escondida

Para o cliente, o serviço continuava sendo um endereço. Para o operador, ele já era um conjunto mutável de máquinas. A RFC 2391 tentou conciliar essas duas perspectivas sem obrigar clientes e servidores a aprender um novo protocolo de distribuição.

O documento combinou a tradução de endereços da RFC 1631 com algoritmos de compartilhamento de carga. Ao ver uma nova sessão, o LSNAT escolhia um membro do conjunto e redirecionava o tráfego. Servidores podiam entrar, sair ou ser substituídos, enquanto o intermediário concentrava a gestão da mudança.

Essa transparência tinha uma consequência semântica. O endereço virtual não identificava mais a máquina que executaria o trabalho. Ele indicava o lugar onde uma política local escolheria a máquina. A lista de candidatos, o algoritmo e a exclusão por falha estavam fora da visão do cliente.

Não era a mesma questão do anycast da RFC 1546. Ali, uma direção de serviço podia ser resolvida pelo roteamento para instâncias diferentes. Aqui, um tradutor guardava a primeira escolha e a reaplicava. O centro da história é o vínculo persistente, não apenas a ambiguidade do endereço.

A primeira seleção virava estado de caminho

A RFC 2391 dividiu o trabalho em vinculação, consulta e tradução, e desvinculação. Na primeira fase, a sessão recebida era associada ao endereço de um servidor. Essa associação estabelecia os parâmetros usados em todos os datagramas posteriores. Na segunda, cada pacote buscava o registro e era reescrito. Na última, o servidor deixava de ser responsável quando a sessão era considerada encerrada.

No sentido de ida, endereço e porta de destino podiam virar os do servidor real. Na volta, origem e porta podiam voltar a parecer as do serviço virtual. Somatórios de verificação precisavam acompanhar a alteração. A continuidade observada pelo cliente era produzida pela repetição coerente da mesma tradução.

Por isso, todo pedido e toda resposta da sessão tinham de passar pelo mesmo LSNAT. Um caminho de volta diferente escaparia da tradução. Um segundo equipamento sem a tabela não saberia qual servidor havia sido escolhido nem como os identificadores haviam sido mapeados.

O limite estava escrito sem eufemismo: uma sessão atribuída a um host não podia mudar para outro até terminar. O seletor distribuía começos. Não transferia estado TCP, autenticação, contexto de aplicação ou operação parcialmente concluída.

Medir o visível não revelava toda a capacidade

O rodízio era simples porque ignorava a carga. Entregava uma chegada a cada membro e supunha, indiretamente, que trabalhos e máquinas fossem parecidos. Uma solicitação custosa e uma leitura trivial ocupavam a mesma posição na sequência.

Escolher quem tinha menos sessões acrescentava informação, mas cada sessão ainda valia uma unidade. Uma conexão ociosa podia durar horas; outra podia consumir CPU, disco e rede em poucos segundos. A contagem exata não significava uma carga exata.

Pacotes ou bytes aproximavam a atividade que o LSNAT conseguia observar. O próprio documento reconheceu que tráfego não é carga de sistema. Um pedido pequeno pode acionar um cálculo caro. Uma transferência grande pode sair de um cache com pouco esforço.

Pesos tornavam as hipóteses explícitas. O operador podia valorar tipos de sessão e capacidades de servidores. A fórmula ficava mais ajustável, mas os números continuavam sendo estimativas. Uma suposição numerada não se transforma em medição.

Também era possível fazer os membros relatarem sua capacidade. Isso aproximava o sinal do recurso, criando novos problemas: frequência, atraso, significado comum e estado vencido. A RFC admitiu que conhecer com precisão a capacidade remota ociosa em tempo real era difícil.

O algoritmo precisava escolher o próximo destino sob informação incompleta. Sua resposta era local: “segundo este modelo, agora escolho este membro”. Não era um certificado de sobra real nem uma promessa de conclusão.

O caminho disponível não reservava o serviço

Em conjuntos distribuídos, o LSNAT podia usar custos de rota, combinando proximidade com sessões ou tráfego. Se uma falha de rede tornasse o servidor inalcançável, o custo podia ser infinito e nenhuma nova carga seria enviada para lá.

A rota descrevia acesso segundo o plano de controle. Não reservava banda, memória, processador ou fila de aplicação. Um caminho curto podia terminar em um serviço quebrado; um caminho conhecido podia mudar logo depois da decisão.

Essa fronteira diferencia o tema da RFC 2386. Aquele trabalho separa mapa de recursos QoS de admissão e entrega. A RFC 2391 acrescenta seu mecanismo próprio: um sinal parcial é usado para criar um vínculo de sessão que, depois, não pode ser deslocado.

O encadeamento correto era: endereço virtual, membros configurados, observação de carga ou rota, regra de seleção, vínculo, tradução nos dois sentidos, resposta do servidor e resultado da aplicação. Um painel que reduz tudo a “disponível” emite recibos antes da hora.

A detecção de morte protegia apenas o próximo cliente

Enviar novas sessões para uma máquina silenciosa criaria um buraco negro. A RFC 2391 sugeriu sondas heurísticas: ping periódico ou observação de datagramas emitidos pelo servidor depois de uma nova atribuição. Sem resposta por alguns segundos, o host podia ser declarado morto e excluído de novas sessões.

O retorno também era um teste. Depois de uma pausa, o sistema podia voltar a atribuir novas sessões e observar o tempo de resposta. “Vivo” era uma conclusão operacional temporária, dependente da sonda e do limiar.

Responder a ping não demonstrava que a aplicação estava pronta. A ausência de resposta tampouco isolava sozinha o defeito entre host, rede, serviço e dependências. A política precisava agir, mas não deveria exagerar o alcance do sinal.

Da combinação de duas afirmações da RFC vem uma conclusão importante. A detecção manda parar de atribuir novas sessões ao host morto. O mecanismo também diz que uma sessão já atribuída não pode trocar de host até o fim. Logo, a exclusão evita o próximo erro, mas não é migração das conversas existentes.

O conjunto poderia continuar saudável enquanto usuários ligados ao membro falho perdiam tudo. Capacidade livre era útil para chegadas futuras, não para um estado que nunca havia sido replicado.

A RFC 3022 mais tarde mostrou dependência semelhante na falha do próprio NAT: mudar a rota para outro equipamento podia quebrar fluxos, a menos que configuração e estado fossem compartilhados. A RFC 3234 distinguiu failover com cópia de estado de restart. Um substituto ligado não equivale a uma continuação preparada.

A sessão terminava quando o intermediário acreditava que terminava

O vínculo precisava ser removido para liberar recursos. TCP oferecia FIN e RST, mas reinicializações e perdas podiam impedir a observação. UDP não trazia uma mensagem universal de encerramento. Uma pausa legítima e uma conversa abandonada podiam parecer iguais.

O tempo de inatividade transformava silêncio em decisão. Curto demais, apagava uma sessão válida. Longo demais, preservava lixo, portas e memória. A RFC 2663 registrou que a ideia de sessão do NAT pode não coincidir com a da aplicação e que, em geral, não se consegue distinguir ociosidade prolongada de desaparecimento.

A RFC 4787 viria a estabelecer limites e recomendações para mapeamentos UDP, ao mesmo tempo que documentava a variação dos temporizadores e das regras de renovação. Melhor interoperabilidade não eliminava a incerteza semântica.

Desvincular não era simples manutenção. A ação decidia quando a identidade antiga deixava de valer e quando um recurso finito podia ser reutilizado. O intermediário interpretava tanto o nascimento quanto a morte da conversa.

LS-NAPT trocou localização por mais tradução

Na configuração básica, o conjunto ficava em um domínio cujo tráfego passava naturalmente pelo LSNAT. A variante LS-NAPT reescrevia os dois lados para forçar clientes e servidores a devolver pacotes ao tradutor. Isso relaxava a topologia e facilitava expandir links de acesso.

O ganho vinha com mais processamento e complexidade. A variante descrita era limitada a TCP e UDP. O espaço de portas de cliente impunha um teto às sessões simultâneas. A restrição física reaparecia como restrição de tabela, porta e capacidade do intermediário.

Era a troca fundamental do NAT. A RFC 1631 mostrou a vantagem de implantar sem alterar os hosts, mas reconheceu a perda do significado ponta a ponta do endereço e o aumento de estado na rede. O LSNAT usou justamente essa característica para tornar a escolha invisível.

A RFC 7098 chamaria de persistência a garantia de manter uma sessão no mesmo servidor até a conclusão. O termo explica bem o vínculo. Também mostra o limite: persistência mantém a escolha; não promete que ela possa ser substituída.

O endereço era só o primeiro comprovante

O endereço virtual demonstrava a entrada. A configuração demonstrava os candidatos. A métrica demonstrava uma observação parcial. A política demonstrava como escolher. O vínculo registrava quem foi escolhido. A tradução mostrava o caminho em funcionamento. A resposta do servidor mostrava alguma execução. Só o resultado da aplicação fechava a intenção do usuário.

Cada camada tinha um controlador. O operador governava conjunto e política. O seletor interpretava sinais. O LSNAT mantinha a associação. O servidor conhecia seus recursos. Os extremos observavam o efeito. Nenhuma dessas partes tinha autoridade para assinar todos os recibos.

As notas de Heng Lu tratam especificações e registros como instrumentos de coordenação, não como criadores da realidade. A ordem passa por decisão local, código em execução e adoção observada. A RFC 2391 é valiosa porque simplificou a superfície do cliente sem fingir que a complexidade desapareceu: ela estava na escolha, na tabela, no caminho e na incerteza.

O servidor de reserva existia. Para a conversa já vinculada, porém, ele não era uma alternativa operacional. Repartir admissões não havia tornado o passado transferível.

Fontes