Resumo

  • A sonda de janela zero faz o receptor repetir um estado que pode ter se perdido em um ACK sem dados.
  • O TCP preserva a possibilidade de continuar; o sistema operacional e a aplicação mantêm a decisão sobre quando parar de esperar e liberar recursos.

A conexão pode ficar parada mesmo quando nenhum dos dois lados violou o protocolo. A aplicação receptora deixa de ler por algum tempo, o buffer se enche e o TCP anuncia uma janela de recepção igual a zero. O emissor obedece ao controle de fluxo e suspende o envio normal. Mais tarde, a aplicação volta a consumir dados, libera espaço e o receptor envia um ACK informando uma janela maior. Se justamente esse pacote desaparecer, cada ponta passa a conhecer uma realidade diferente.

Para o receptor, o crédito de recepção já foi devolvido. Para o emissor, a última informação continua sendo zero. Um ACK sem dados não recebe, por si só, a garantia de retransmissão confiável. O receptor pode não ter outro motivo para falar; o emissor não pode mandar os dados que naturalmente provocariam uma resposta. A conexão permanece aberta, mas o conhecimento que permite usá-la ficou preso em apenas uma ponta.

A sonda de janela zero desfaz esse impasse sem inventar capacidade. Mesmo diante de uma janela fechada, o emissor envia ou retransmite periodicamente uma pequena quantidade para provocar uma resposta. O receptor devolve o próximo número de sequência esperado e sua janela atual. Se o espaço já reapareceu, o emissor finalmente aprende isso. Se a janela continua em zero, recebe apenas uma confirmação recente e continua sujeito ao limite anunciado.

A estrutura básica já estava na RFC 793, de 1981. O TCP emissor deveria retransmitir regularmente mesmo com janela zero, enquanto o receptor, ao receber um segmento nessa condição, deveria responder com um ACK que mostrasse seu próximo número esperado e a janela vigente. A finalidade declarada era garantir que a reabertura da janela chegasse de modo confiável ao outro lado. A recomendação de intervalo daquele texto pertence à formulação inicial; a ideia duradoura era obrigar uma informação de controle sujeita a perda a aparecer novamente.

Em 1989, a RFC 1122 tornou a exigência inequívoca: hosts precisam oferecer sondagem de janelas zero. O documento explicou a falha que ela evita. Segmentos ACK sem dados não são transmitidos de maneira confiável pelo TCP; sem uma sonda, perder o ACK que reabre a janela pode deixar a conexão suspensa para sempre. A primeira sonda deveria sair depois de um período de timeout de retransmissão, e os intervalos posteriores deveriam crescer exponencialmente.

Essa cadência equilibra duas necessidades. Perguntar depois de um RTO limita o atraso causado pela perda isolada do aviso de reabertura. Aumentar os intervalos reduz o custo de continuar consultando uma pausa legítima e prolongada. Em nenhum momento a sonda concede ao emissor permissão para ignorar o receptor. Ela não amplia a janela: pergunta de novo qual é o seu valor.

A RFC 1122 também preservou uma condição que parece estranha quando lida fora desse contexto. O TCP receptor pode manter a janela oferecida fechada indefinidamente. Enquanto continuar respondendo às sondas, o emissor precisa admitir que a conexão fique aberta, sujeita à política de timeout da aplicação. O exemplo clássico era um daemon de impressão que parava de consumir dados porque a impressora estava sem papel. Para o transporte, a causa externa e a duração da pausa são desconhecidas; fechar a conexão automaticamente confundiria falta temporária de capacidade com falha definitiva.

Do ponto de vista do emissor, essa situação ficou conhecida como persist condition, ou condição persistente. A RFC 6429 voltou ao tema em 2011 porque a paciência do protocolo tem um custo que o próprio TCP não consegue avaliar. Uma ponta pode anunciar janela zero e continuar reconhecendo todas as sondas. Enquanto isso, dados da aplicação podem permanecer na fila de envio, acompanhados por buffers e estado de conexão. Em escala, essas conexões podem consumir recursos necessários para tráfego legítimo.

A RFC 6429 não classificou toda janela zero como ataque nem substituiu a sondagem por um prazo universal de encerramento. Ela esclareceu a distribuição de responsabilidade. O TCP não deveria fechar uma conexão apenas por ela estar na condição persistente, mas o sistema operacional ou a aplicação ainda pode encerrá-la e recuperar recursos de acordo com sua política normal. Manter o estado do protocolo recuperável não obriga o proprietário da máquina a aceitar custo ilimitado.

A especificação consolidada atual, RFC 9293, conserva essa arquitetura. A sondagem de janela zero continua obrigatória. O receptor ainda precisa responder com sua janela atual e o próximo número de sequência esperado. O emissor deveria iniciar depois de um intervalo RTO e ampliar exponencialmente a distância entre tentativas. A ressalva sobre gestão de recursos também permanece. O compromisso não é esperar para sempre em qualquer circunstância, mas garantir que, enquanto a conexão for mantida, o estado da janela possa ser reaprendido.

O ACK recebido em resposta a uma sonda é, portanto, evidência de transporte com alcance limitado. Ele mostra que o TCP remoto ainda informa seu espaço de sequência e seu crédito de recepção. Não prova que a aplicação está avançando, que aceitará dados em breve ou que conservar a conexão ainda faz sentido para o serviço. A sonda recupera uma atualização perdida; não prevê o futuro.