Resumo

  • O tempo de retransmissão diz quando tentar de novo; USER TIMEOUT diz quando abortar a conexão.
  • A RFC 5482 sinaliza uma preferência do par, enquanto limites locais e CHANGEABLE preservam a decisão final.

A tentativa e o abandono têm relógios diferentes

Quando não chega uma confirmação útil, o temporizador de retransmissão pode expirar. TCP então envia novamente o segmento no início da fila e reinicia esse temporizador. Isso não informa por quanto tempo a aplicação aceita manter a conexão.

USER TIMEOUT trata da outra decisão: por quanto tempo os dados transmitidos podem continuar sem entrega bem-sucedida? A RFC 793 já descrevia esse limite fornecido localmente ao TCP. A RFC 9293 separa os eventos de forma explícita. O vencimento do retransmission timeout envia novamente o primeiro segmento e reinicializa o temporizador. O evento USER TIMEOUT esvazia as filas, comunica o aborto, remove o TCB e entra em CLOSED.

Assim, uma nova retransmissão pode continuar tecnicamente possível no momento em que a política de persistência já expirou. RTO ajusta o ritmo das tentativas conforme o tempo de ida e volta e a ambiguidade das perdas. USER TIMEOUT define quanto tempo ainda vale a pena manter estado, memória e incerteza para a aplicação.

Ele também não é um timeout de requisição da aplicação. A aplicação pode desistir de uma operação e conservar a conexão, ou pode exigir que a conexão desapareça quando os dados pendentes não puderem ser entregues.

Uma sugestão em segundos ou minutos

O timeout original era local. Um endpoint não sabia por quanto tempo o outro pretendia conservar uma conexão afetada por uma interrupção. A RFC 5482 criou a opção TCP User Timeout para tornar essa expectativa visível.

A opção tem Kind 28 e Length 4. Um bit de granularidade escolhe segundos ou minutos; os outros 15 bits carregam o intervalo sugerido. O formato representa de um segundo a mais de nove horas, ou de um minuto a mais de vinte e dois dias.

O valor aconselha o par, mas não ordena um aborto remoto. O estado abstrato inclui USER_TIMEOUT, ADV_UTO, ENABLED e CHANGEABLE. ENABLED vem desabilitado por padrão e controla o envio e o processamento da opção. CHANGEABLE determina se uma sugestão recebida pode alterar o timeout local.

Se a aplicação fixou um valor e CHANGEABLE está falso, o valor recebido não pode substituí-lo. TCP ainda deve informar a aplicação sobre a sugestão do par. A informação atravessa a conexão; a autoridade não.

Limites fazem parte da proteção

As implementações precisam impor limites mínimo e máximo. Um valor muito curto pode interromper uma conexão apenas lenta ou afetada por uma falha temporária. Um valor muito longo mantém buffers e estado e aumenta o risco de esgotamento de recursos. Autenticação e limites por par são possíveis medidas de mitigação.

A ausência de UTO não prova que não exista USER TIMEOUT. Uma implementação sem suporte pode ignorar a opção silenciosamente, e o espaço de opções TCP pode estar ocupado. Um firewall também pode descartar seu estado antes dos endpoints. Um pacote capturado mostra uma sugestão naquele ponto de observação, não sua adoção nem a duração do estado intermediário.

Quando keepalive e UTO estão ativos, o temporizador de keepalive deve ser maior que o USER_TIMEOUT adotado. Keepalive verifica a vivacidade de uma conexão ociosa; USER TIMEOUT limita a persistência de dados não entregues.

A mudança histórica foi cuidadosa: a RFC 5482 expôs uma política local como sugestão limitada, sem transformar o par no dono da decisão de abortar.

Fontes