(Por que) o FreeBSD 'net.inet.tcp.always_keepalive' viola o RFC1122?

Question

Enquanto trabalhava em um aplicativo de servidor que roda no FreeBSD e usa o TCP, notei que os probes TCP keepalive são enviado mesmo que meu aplicativo desative explicitamente SO_KEEPALIVE em soquetes TCP.

De acordo com RFC1122 Seção 4.2.3.6 (TCP Keep-Alives):

"If keep-alives are included, the application MUST be able to turn them on or off for each TCP connection, and they MUST default to off."

Descobri que o parâmetro sintonizável net.inet.tcp.always_keepalive estava habilitado (definido como 1), e que desabilitá-lo impediria que as detecções keepalive fossem enviadas.

Qual é o raciocínio por trás da inclusão deste comportamento no FreeBSD? Pelo que eu sei, o Linux e o Windows não têm essa opção, mas o FreeBSD e o Mac OS X fazem isso, então eles violam o RFC.

Para ser mais específico, sob que circunstâncias faria sentido ignorar os desejos da aplicação?

Esta é uma correção direta no meu caso, pois posso desativar a opção, mas gostaria de entender por que ela está lá.

Esta questão mostra que o Linux se comporta de acordo com o RFC.

    

Answer 1

A justificativa para ativar o keep-alive por padrão foi fornecida aqui: link

Add handle to control global TCP keepalives and turn them on as default.

Despite their name it doesn't keep TCP sessions alive, it kills them if the other end has gone AWOL. This happens a lot with clients which use NAT, dynamic IP assignment or which has a 2^32 * 10^-3 seconds upper bound on their uptime.

There is no detectable increase in network trafic because of this: two minimal TCP packets every two hours for a live TCP connection.

Many servers already enable keepalives themselves.

The host requirements RFC is 10 years old, and doesn't know about the loosing clients of todays InterNet.

De qualquer forma, é melhor desativar o keep-alive se solicitado pelo aplicativo, por exemplo (em C):

int val = 0;
setsockopt(s, SOL_SOCKET, SO_KEEPALIVE, &val, sizeof(val));

mas não é fácil corrigir isso.

    

Answer 2

Acho que o botão ajustável deve existir, mas talvez seja melhor mantê-lo desligado por padrão.

Meu raciocínio é o seguinte: um desenvolvedor de aplicativos pode ter esse tipo de decisão errado e, por fim, um administrador de sistema deve ter controle sobre esse tipo de política de rede, não o desenvolvedor do aplicativo.