Considerando odescrição de TCP_USER_TIMEOUT:
Quando o valor é maior que 0, ele especifica o tempo máximo em milissegundos que os dados transmitidos podem permanecer sem reconhecimento antes que o TCP feche à força a conexão correspondente e retorne ETIMEDOUT ao aplicativo.
Valores muito curtos de USER TIMEOUT podem afetar as transmissões TCP em caminhos de alto atraso. Se o tempo limite do usuário ocorrer antes da chegada de uma confirmação de um segmento pendente, possivelmente devido à perda de pacotes, a conexão será fechada. Muitas implementações de TCP assumem como padrão valores de USER TIMEOUT de alguns minutos. Embora a opção UTO permita sugestões de tempos limite curtos, os aplicativos que os anunciam devem considerar esses efeitos.
Eu esperaria que um TCP_USER_TIMEOUT de 2 ms tivesse consequências catastróficas: em uma rede onde o RTT é inferior a 2 ms, cada pacote TCP enviado atingiria o tempo limite de espera por um ACK e a conexão seria fechada. No entanto, no meu ambiente não estou experimentando isso. As conexões podem ser estabelecidas e os dados são enviados e recebidos sem problemas. Percebo, entretanto, que se eu puxar o cabo ou desligar a interface de recepção, o TCP_USER_TIMEOUT detectará efetivamente uma perda de conexão e a conexão será encerrada em tempo hábil. Então, TCP_USER_TIMEOUT está funcionando, mas não do jeito que eu esperava.
O que estou entendendo mal sobre TCP_USER_TIMEOUT? Por que valores inferiores a RTT não causam a queda da conexão?
Caso seja útil, meu cliente é uma caixa Scientific Linux 6.1 com o kernel 2.6.32.
Responder1
A implementação do UTO no Linux era imprecisa e foi recentemente corrigida por este patchset:(Caso você não seja o autor deste patchset): https://lkml.org/lkml/2018/7/18/1090
No entanto, mesmo após o disparo do UTO, o host interrompe a retransmissão e vai para o estado TCP_CLOSE, mas não redefine a conexão. É responsabilidade do aplicativo enviar o RST.