Resumo

  • O RFC 9693 torna o precondicionamento parte da medição: a fase 1 cria conexões limitadas no DUT e registra no Responder as quatro-tuplas traduzidas; a fase 2 mede o tráfego contra esse estado conhecido.
  • Uma fase 2 sem perda prova um experimento de caixa-preta declarado. Não revela a tabela interna, não reproduz a Internet, não caracteriza TCP automaticamente e não demonstra folga de produção ou continuidade da aplicação.

A volta depende de algo que já aconteceu

No sentido cliente-servidor, o Initiator pode oferecer uma quatro-tupla nova. O DUT cria uma entrada, traduz o pacote e encaminha. No sentido servidor-cliente, o Responder não pode inventar a própria tupla: uma trama fora de conexão existente tende a ser descartada.

O teste mantém duas memórias. A connection tracking table do DUT é opaca; tamanho, conteúdo e política não estão disponíveis ao Tester. A state table do Responder guarda apenas as tuplas traduzidas que chegaram. Tuplas oferecidas, pacotes recebidos na ida, tuplas registradas e conexões validadas na volta são fatos diferentes.

Essa separação impede que “um milhão de sessões” misture intenção, encaminhamento, permanência e retorno em uma só contagem.

Portas aleatórias podem criar bilhões de pedidos de estado

O RFC 4814 recomenda portas pseudoaleatórias e uniformes para não favorecer uma função de hash por acidente. Em um encaminhador sem estado, isso amplia a distribuição; em NAT stateful, cada quatro-tupla desconhecida pode solicitar uma nova conexão.

Com um único par de endereços, as faixas amplas do RFC 4814 geram 3.170.829.312 combinações. Faixas de IP multiplicam o espaço. Um gerador “realista” pode esgotar a tabela antes de medir o desempenho pretendido.

O RFC 9693 mantém a pseudoaleatoriedade, mas restringe as faixas. A origem pode usar dezenas de milhares de portas; o destino, uma faixa menor que reconhece a concentração de serviços populares. As dimensões precisam acompanhar o resultado. “Tráfego aleatório” não permite repetição.

A fase 1 define o universo da fase 2

Na fase 1, somente o Initiator transmite. O DUT traduz e cria conexões. O Responder recebe, extrai as quatro-tuplas e não responde. A operação carrega simultaneamente a tabela invisível do dispositivo e o registro observável do Tester.

Essa fase é obrigatória antes do throughput, latência, perda e variação da fase 2. Sua taxa deve ficar com segurança abaixo da taxa máxima de estabelecimento, que precisa ser medida primeiro.

Há dois estados extremos úteis. Para medir criação, cada trama usa uma tupla diferente e o timeout ultrapassa a fase 1, de modo que todo pacote peça estado novo e nenhum expire. Para medir encaminhamento estável, a fase 1 enumera todo o conjunto e o timeout cobre as duas fases e a pausa, evitando criação ou eliminação durante o cronômetro.

São controles experimentais, não uma cópia do tráfego público. Eles separam o custo de criar estado do custo de atravessar estado pronto.

Receber na ida não valida a entrada

O Tester não lê a tabela interna. Todas as tramas podem chegar ao Responder e, ainda assim, algumas conexões não estarem disponíveis: a taxa de criação foi excessiva, a capacidade terminou ou uma política substituiu entradas.

O Responder valida cada tupla guardada, enviando uma trama de volta em taxa menor, definida por fator de segurança. O recebimento completo no Initiator comprova que aquele conjunto estava presente e que as duas taxas foram adequadas.

Uma perda reversa não tem causa única. R ou r podem estar altos; a tabela pode ter esgotado; o DUT pode recusar estado novo, trocar pelo menos recente ou eliminar um lote. A observação limita a hipótese, mas não inspeciona a máquina.

Capacidade aparece primeiro como intervalo

O procedimento começa com contagem segura C0 e taxa validada R0. Uma busca exponencial dobra conexões até colapso ou queda severa da taxa. Depois, busca binária reduz o intervalo até o erro E declarado.

A política muda quais conexões sobrevivem. Recusar novas preserva as primeiras; LRU preserva as últimas; coleta em lote pode produzir menos validações do que a capacidade física. Um N′ exato nem sempre é o tamanho real.

Tear-down tem recibo próprio. Carregam-se N conexões, mede-se uma remoção fora de banda específica da implementação e divide-se N pelo tempo. Limpar a tabela inteira e remover item a item podem custar diferente.

Ordem, relógio e CPU pertencem ao resultado

O RFC recomenda escrita round-robin na tabela do Responder para manter entradas frescas. Leitura pseudoaleatória segue o RFC 4814; round-robin custa menos. Ordem crescente ou decrescente pode ser experimento adicional, pois hash, cache e substituição respondem à sequência.

Timeout, duração e intervalo, núcleos ativos, hashsize, nf_conntrack_max, hardware, NIC, sistema, kernel e versão precisam ser publicados. As medições devem se repetir; mediana, percentis 1 e 99, número de repetições e erro da busca dão contexto ao valor.

UDP marca o limite da afirmação

UDP permite taxa constante sem contrariar congestion e flow control de TCP nem adicionar handshake. Mas implementações podem usar timeouts e caminhos distintos para TCP. O RFC 9693 alerta que UDP não caracteriza necessariamente o tráfego da Internet e indica o RFC 9411 para HTTP e HTTPS.

Logo, zero perda prova uma combinação de DUT, versão, configuração, população de tuplas, ordem, timeout, direção, taxa e CPU. Não prova conteúdo oculto, distribuição real, comportamento TCP, reserva operacional ou transação concluída.

A especificação oferece gramática comum; o código em execução oferece observação. A decisão exige preservar os recibos entre ambos.

Fontes