Resumo

  • Janela de recepção zero é uma ordem válida de controle de fluxo: não há capacidade para bytes novos agora. Ela não prova falha do par, do caminho ou da aplicação.
  • A reabertura pode vir apenas num ACK sem dados, que não recebe retransmissão confiável. Uma sonda pequena força um novo relatório, com intervalos posteriores em recuo exponencial.
  • Enquanto o receptor reconhece as sondas, o TCP mantém a conexão. A aplicação ou o sistema operacional ainda pode abortá-la por uma política explícita de recursos.

Dois lados corretos podiam esperar para sempre

A aplicação receptora para de ler, o buffer enche e o TCP anuncia zero. O emissor obedece. Quando o programa finalmente consome dados, sai um ACK com janela positiva. Se esse pacote se perde, o emissor continua vendo zero; o receptor pode acreditar que já comunicou a mudança.

O RFC 1122 lembra que ACK puro não é transmitido de forma confiável. A pausa foi correta, a abertura foi anunciada corretamente e, mesmo assim, a associação congela. A informação perdida não era um byte do fluxo, mas o direito de voltar a enviá-lo.

A janela dizia quanto, não por quê

O RFC 813 separou a janela oferecida pelo receptor da janela utilizável que o emissor calcula após descontar dados ainda não reconhecidos. É controle de capacidade.

Zero não significa processo morto. A imagem histórica é uma impressora sem papel: o aplicativo pode esperar por intervenção humana durante minutos, horas ou dias. Encerrar nesse momento faria o transporte julgar um estado de negócio que não observa.

Janela de recepção também não é janela de congestionamento. Uma limita o que o destino aceita; a outra limita o que o caminho deve suportar. Misturar os dois números converte uma condição local em diagnóstico da rede.

Um octeto excepcional perguntou de novo

O mecanismo aparece no RFC 793 e permanece obrigatório no RFC 9293. Com a janela em zero, o emissor envia regularmente ao menos um octeto novo, se houver, ou retransmite. O receptor responde com a próxima sequência esperada e sua janela atual.

A sonda não abre a janela à força. É uma pergunta limitada. ACK com zero confirma a pausa; ACK positivo repõe a autorização perdida.

A primeira sonda deve esperar um RTO. As seguintes devem usar backoff exponencial. Assim, uma atualização isolada perdida causa pouco atraso, e uma parada longa não produz consulta constante. O protocolo não inventa um máximo universal para toda aplicação.

Zero respondido não era silêncio

O RFC 1122 permite que a janela fique fechada indefinidamente. Enquanto o receptor responde às sondas, o TCP emissor deve permitir que a conexão continue aberta.

Esse ACK prova pouco, mas prova algo: o TCP remoto e um caminho de retorno forneceram um relatório atual. Não prova saúde do programa, retomada breve nem justiça do custo local. Ausência de resposta traz incerteza sobre caminho ou par; zero reconhecido é evidência de presença sem capacidade.

Persistir não transferia a propriedade da fila

O termo “indefinidamente” virou argumento contra qualquer limpeza. O RFC 6429 corrigiu a leitura: o TCP não deve fechar só porque está em persist, mas aplicação e sistema operacional podem ordenar o aborto para recuperar recursos.

Clientes podem pedir respostas grandes, parar de ler, anunciar zero e reconhecer cada sonda. O servidor preserva dados enfileirados e blocos de conexão até faltar memória para usuários legítimos.

Um timeout oculto igual para todos tampouco sabe distinguir impressão válida de retenção hostil. A camada que conhece serviço, cliente, custo e prazo deve decidir. O TCP preserva a verdade compartilhada; a política local decide quanto pagar por ela.

Abrir em migalhas criava outra degradação estável

O RFC 813 chamou de Silly Window Syndrome o padrão em que pequenos avanços de janela geram pequenos segmentos, mais ACK, CPU, perda e retransmissão. Seus números de campo mostram possibilidade histórica, não uma constante universal.

O receptor pode segurar liberações pequenas até anunciar espaço útil. O emissor evita reagir a cada avanço mínimo. O RFC 9293 exige prevenção nos dois lados e apresenta Nagle como mecanismo complementar para pequenas escritas da aplicação.

Persist garante que uma abertura relevante seja redescoberta. A prevenção de SWS impede que cada punhado de bytes vire uma autorização ineficiente. A confiabilidade da mensagem e o tamanho da concessão pertencem ao mesmo contrato.

O que sobreviveu foi a divisão de responsabilidade

RFC 793, RFC 813, RFC 1122, RFC 6429 e RFC 9293 formam uma linha de correção, desempenho, requisitos e autoridade. O receptor controla sua capacidade. O TCP emissor mantém uma consulta esparsa. Aplicação e sistema escolhem memória, prazo e encerramento.

Persistir em zero protege a possibilidade de continuar. Não concede a um par o direito de consumir, sem limite, os recursos do outro.

Fontes e limites

O conjunto fechado é RFC 793, RFC 813, RFC 1122, RFC 6429 e RFC 9293. Ele não estabelece temporizadores de cada sistema atual, prevalência de ataques nem saúde de uma aplicação específica.