Resumo

  • O TIME-WAIT é uma fronteira temporal: depois de fechar ativamente uma conexão, o endpoint precisa preservar o estado por 2xMSL, segundo o RFC 9293, para que pacotes da conexão anterior morram antes de serem confundidos com os da seguinte.
  • Na cadeia descrita pelo RFC 1337, um segmento antigo não aceitável provoca um ACK; o par que já fechou responde com um RST, e aceitar esse reset apaga o TIME-WAIT antes do fim da quarentena.

O memorando demonstrou três consequências possíveis após uma reabertura rápida, mas em uma simulação deliberadamente extrema. O resultado prova que o mecanismo pode existir, não com que frequência ele ocorre hoje.

O fim de uma aplicação não esvazia a rede. Um segmento de dados pode continuar preso atrás de um enlace congestionado; um ACK duplicado pode reaparecer depois de percorrer um caminho mais longo. Esses pacotes não sabem que os sockets foram fechados nem que a mesma combinação de endereços e portas poderá identificar outra conexão em instantes.

O TIME-WAIT mantém essas duas histórias separadas. O lado que fecha ativamente não descarta o bloco de controle assim que termina a troca final. O RFC 9293 torna explícito o custo: o endpoint deve permanecer nesse estado por duas vezes a vida máxima de um segmento, ou 2xMSL. A espera não é uma limpeza adiada. É o intervalo necessário para que duplicatas antigas desapareçam antes que a mesma quádrupla volte a ter significado.

O ponto incômodo do RFC 1337 é que as reações normais do TCP a tráfego obsoleto podiam destruir essa própria quarentena.

Uma resposta correta que fabrica o reset errado

A cadeia começa quando um segmento antigo de dados ou de confirmação chega ao endpoint A, ainda em TIME-WAIT. O segmento não é aceitável, talvez porque seu número de sequência ou timestamp pertença a outra encarnação. A responde com um ACK que contém seus valores atuais de SND.NXT e RCV.NXT.

O endpoint B já descartou todo o estado da conexão. Ao receber um ACK que não corresponde a uma conexão conhecida, B devolve um RST. Se A tratar esse reset como motivo para sair de TIME-WAIT, eliminará exatamente o estado que deveria sobreviver aos pacotes antigos. O segmento obsoleto não mandou A fechar diretamente: fez A falar, a resposta precisa de A levou o par sem estado a emitir o controle destrutivo, e esse controle encerrou a espera. O RFC 1337 chamou a cadeia de TIME-WAIT Assassination.

O assassinato ainda não significa que uma aplicação nova recebeu dados velhos. Ele remove a barreira que impedia isso. Para o dano seguinte se materializar, a mesma identidade de conexão precisa ser reutilizada antes que as duplicatas expirem, os espaços de sequência das duas encarnações precisam se sobrepor o suficiente e um pacote antigo precisa cair em uma faixa que o novo estado considere válida.

O memorando enumera três resultados. H1 é a aceitação incorreta de dados da conexão anterior. H2 deixa os endpoints dessincronizados; com o comportamento especificado na época, eles poderiam confirmar algo que nunca foi enviado e entrar em um ciclo permanente de ACK. H3 mata a conexão nova quando um segmento antigo interfere durante a abertura, mesmo depois de ela aparentar ter sido concluída.

Essas condições adicionais explicam por que o RFC 1337 considera H1, H2 e H3 menos prováveis que o assassinato isolado. Não basta remover TIME-WAIT cedo: é preciso reutilizar a identidade rapidamente, sobrepor os espaços e receber a duplicata certa na janela certa. O documento reproduziu os quatro fenômenos em uma pilha TCP do SunOS 4.1.1, mas usou um ambiente simulado que duplicava segmentos em massa e foi ajustado para produzir as coincidências. É uma prova de existência, não uma estimativa de incidência contemporânea nem uma afirmação sobre um produto atual específico.

Três remédios com alcances diferentes

A primeira proposta do RFC 1337 é a mais direta: ignorar RST enquanto o endpoint está em TIME-WAIT. Com a MSL de dois minutos assumida pelo memorando, o texto afirma que essa escolha evita H1, H2 e H3. A justificativa decorre da função do estado. Se a espera existe para deixar morrer tráfego antigo não autenticado, esse mesmo tráfego não deveria ter autoridade para encurtá-la.

A recomendação, porém, preserva um limite importante. O RFC 1337 é Informativo e pede um teste prolongado em produção para revelar efeitos inesperados da mudança. Ele não demonstra que todas as implementações adotaram a regra nem que ignorar um reset nesse estado é inofensivo em qualquer arquitetura.

A segunda proposta usa timestamps TCP e PAWS. Se o TIME-WAIT persistir até os relógios avançarem, o SYN da conexão nova poderá carregar um timestamp posterior ao dos segmentos antigos, bloqueando os dados do cenário H1. O remédio é apenas parcial. Um ACK antigo que chega durante TIME-WAIT pode provocar um ACK novo com timestamp atual; essa “duplicata antiga renovada” pode atravessar o PAWS na conexão seguinte, de modo que H2 e H3 não desaparecem necessariamente.

A terceira proposta amplia os números de sequência para 64 bits. O espaço maior retardaria muito a reutilização da mesma faixa, mas não impediria um RST de apagar TIME-WAIT. O RFC 1337 trata a ideia como uma grande alteração de protocolo que poderia evitar os perigos posteriores somente em conjunto com outros ajustes de parâmetros, não como correção autônoma.

A especificação atual conserva a tensão

O RFC 9293, padrão-base atual do TCP, mantém o requisito de TIME-WAIT por 2xMSL para o lado que fecha ativamente. Ele permite aceitar diretamente um SYN novo do mesmo par, mas apenas se o novo ISN for maior que o maior número usado na encarnação anterior e se o endpoint voltar a TIME-WAIT quando o SYN se revelar uma duplicata velha. O texto também aponta para um algoritmo baseado em timestamps em servidores com alta taxa de estabelecimento.

O autômato-base ainda contém a saída que torna o problema relevante. Depois dos testes de aceitabilidade, processar um RST em TIME-WAIT leva a CLOSED e elimina o bloco de controle. Em contraste, a retransmissão do FIN remoto é confirmada e reinicia o temporizador de 2xMSL. Dois controles recebidos no mesmo estado podem, por caminhos diferentes, encerrar ou prolongar a fronteira.

Por isso, “reduzir TIME-WAIT” não descreve uma arquitetura completa: falta dizer que evidência substitui o tempo na separação entre encarnações. “Manter mais estado” também não basta, pois não esclarece se esse estado resiste aos sinais que podem apagá-lo. A pergunta central é qual prova tem força suficiente para terminar uma quarentena cuja finalidade é sobreviver a tráfego antigo não autenticado.

As únicas fontes deste pacote são o RFC 1337, publicado como Informativo em maio de 1992, e o RFC 9293, padrão da Internet publicado em agosto de 2022. Eles descrevem o mecanismo, suas condições e as regras de base; não documentam a frequência atual nem o comportamento de um produto identificado.