Conexões TCP: handshake, temporizadores de retransmissão e keep-alives

O que é

A RFC 9293 descreve o handshake de três vias: o cliente envia SYN, o servidor responde com SYN-ACK e passa para o estado SYN-RECEIVED, e o ACK do cliente conclui a conexão. Todo segmento que carrega dados é confirmado; se a confirmação não chegar antes de o timeout de retransmissão (RTO) expirar, o segmento é enviado de novo. A RFC 6298 define como o RTO é calculado a partir dos tempos de ida e volta medidos, com valor inicial de 1 segundo antes de qualquer medição, e como ele é dobrado ("backoff") a cada expiração. A RFC permite, mas não exige, keep-alives: sondas enviadas em uma conexão ociosa, com intervalo padrão que não pode ser inferior a duas horas.

Por que importa

Os temporizadores explicam a maioria dos relatos do tipo "por que isso ficou travado por tanto tempo". Segundo tcp(7), o Linux retransmite um SYN inicial tcp_syn_retries vezes (padrão 6, cerca de 127 segundos) antes de o connect falhar, e retransmite dados em uma conexão estabelecida tcp_retries2 vezes (padrão 15, cerca de 13 a 30 minutos) antes de desistir. Keep-alives só são enviados quando o socket tem SO_KEEPALIVE ativado; os padrões são tcp_keepalive_time de 7200 segundos, seguido de 9 sondas com 75 segundos de intervalo. Assim, um servidor cujo par desapareceu sem enviar FIN ou RST mantém a conexão, junto com a memória e o descritor de arquivo associados, por muito tempo.

Como aplicar

• Defina timeouts na aplicação para connect, leitura e escrita; não conte com o TCP para detectar rapidamente pares inativos.
• Habilite keep-alive em conexões de longa duração (pools de banco de dados, message brokers, túneis) e reduza o tempo de ociosidade por socket (TCP_KEEPIDLE, TCP_KEEPINTVL, TCP_KEEPCNT em tcp(7)), em vez de alterar o valor para todo o sistema.
• Use TCP_USER_TIMEOUT quando a biblioteca o expuser: ele limita por quanto tempo dados não confirmados podem ficar pendentes antes de a conexão ser fechada.
• Ao diagnosticar, observe ss -tin para ver contadores de retransmissão e valores de RTO, e o estado da conexão (SYN-SENT indica que nenhum SYN-ACK voltou).

Armadilhas

Um handshake concluído comprova a alcançabilidade apenas no momento da conexão; se um NAT ou firewall descartar o estado mais tarde, o resultado é silêncio, não um erro. O backoff da retransmissão é exponencial, então algumas perdas consecutivas se transformam em dezenas de segundos de travamento. As sondas de keep-alive são segmentos ACK e sua entrega não é garantida, e é por isso que a RFC proíbe tratar uma única sonda sem resposta como sinal de conexão morta.