Resumo

  • O tempo limite de usuário do TCP é um teto local para cada conexão: dados transmitidos podem ficar sem confirmação apenas até esse ponto antes de a ponta abortar. Ele não é o temporizador que decide quando retransmitir.
  • A RFC 5482 criou uma opção de quatro octetos para anunciar o valor corrente. A informação é aconselhamento, não negociação vinculante: o par pode ignorar, aplicar limites locais ou impedir que ela substitua um prazo definido pela aplicação.
  • Um prazo longo pode preservar a conexão durante uma interrupção, mas mantém filas e estado por mais tempo. Um prazo curto libera recursos cedo, porém pode tratar atraso ou perda transitória como falha definitiva.

Dois relógios para um byte sem resposta

A conexão está estabelecida e um byte continua sem ACK. Quando o temporizador de retransmissão vence, o TCP envia o segmento novamente e reinicia esse relógio. O User Timeout responde a outra pergunta: por quanto tempo ainda vale, para a aplicação, conservar toda a conexão enquanto trabalho enviado permanece sem confirmação?

Na RFC 793, o vencimento desse prazo não aciona mais uma tentativa. O TCP esvazia as filas, informa que a conexão foi abortada, elimina o bloco de controle e entra em CLOSED. A RFC 9293 mantém a distinção: RETRANSMISSION TIMEOUT reenvia; USER TIMEOUT encerra o estado.

A aplicação já controlava essa espera em 1981. A interface abstrata permitia fornecer um prazo em OPEN e alterá-lo em SEND. A RFC 1122 refinou a falha de conexão com os limiares R1 e R2. R1 provoca avisos; R2 fecha. A aplicação precisa poder definir R2 por conexão, inclusive entregar a decisão final a uma pessoa. A recomendação de pelo menos cem segundos para dados não é uma regra única para todos os serviços.

Esse controle era unilateral. Um host móvel podia prolongar a espera para sobreviver a uma troca de acesso, enquanto o outro lado abandonava o estado primeiro. Um servidor ocupado podia querer liberar conexões silenciosas rapidamente, sem conseguir comunicar essa restrição pelo TCP.

Quatro octetos que não fecharam um trato

Publicada em 2009, a RFC 5482 definiu UTO como a opção TCP 28, com comprimento 4. Um bit G escolhe segundos ou minutos; os quinze bits restantes carregam o valor sugerido. Zero é reservado. O campo expressa tempo, não uma contagem de retransmissões nem uma estimativa de RTT.

Quando habilitada antes da abertura, UTO pode aparecer em SYN e SYN-ACK. O primeiro pacote sem SYN também deve levá-la. Uma implementação que não conhece a opção precisa ignorá-la silenciosamente. Se o segmento com UTO se perde, o par apenas deixa de atualizar sua política. Não existe um aperto de mão separado que garanta a entrega.

A distribuição de autoridade é explícita. ADV_UTO é o valor anunciado; REMOTE_UTO, a última sugestão recebida; USER_TIMEOUT, a escolha local. ENABLED ativa a extensão e CHANGEABLE define se o conselho remoto pode influenciar o valor aplicado.

Se a aplicação define USER_TIMEOUT, CHANGEABLE deve se tornar falso. Um pacote do outro lado não pode anular uma instrução explícita. Quando a adaptação é permitida, a RFC recomenda escolher o maior valor anunciado e depois submetê-lo a limites inferior e superior locais. Ainda assim, as duas pontas podem adotar prazos diferentes, e qualquer uma pode fechar por conta própria.

Sobrevivência cobra estado

Um prazo maior ajuda durante mobilidade, instabilidade de rotas ou um período sem conectividade. Em troca, o host conserva filas, memória e contexto. Um atacante que completa muitas aberturas e sugere valores longos pode aumentar o custo de conexões descartáveis no servidor.

Por isso a RFC 5482 exige limites. O piso deve ser maior que o RTO corrente; caso contrário, perda ou alta latência podem abortar antes de a retransmissão ter oportunidade razoável de recuperar. O teto pode variar conforme autenticação, número de conexões por par, uso de recursos e situação de ataque. Aceitar uma sugestão longa não retira o direito local de liberar estado.

Keep-alive cumpre outro papel. Se ambos estiverem ativos, seu temporizador deve ser maior que o User Timeout adotado, para que outra política de aborto não encerre primeiro. Um firewall com estado também pode apagar o fluxo segundo seu próprio prazo de ociosidade. UTO não sonda o caminho, não autentica o par e não garante que a conexão sobreviva até o tempo anunciado.

Há ainda o limite físico de quarenta octetos de opções TCP. Outras extensões podem ocupar tudo. A ausência de UTO, isoladamente, não prova recusa.

O que a opção realmente mudou

A RFC 5482 não inventou o direito da aplicação de escolher quanto esperar. Ela tornou uma preferência local audível sem transferir a autoridade. Isso a separa de Window Scale, que fixa a interpretação de um campo após o handshake; de PAWS, que usa timestamps para rejeitar um significado antigo do espaço de sequência; e de SACK, que relata blocos recebidos depois de uma lacuna.

Este pacote de RFCs não mede adoção atual, não cataloga APIs de sistemas operacionais nem define os padrões de aplicações específicas. Ele demonstra uma história mais precisa: o TCP aprendeu a comunicar um limite de espera sem chamá-lo de obrigação mútua.

Fontes