%20o%20FreeBSD%20'net.inet.tcp.always_keepalive'%20viola%20o%20RFC1122%3F.png)
Enquanto trabalhava em um aplicativo de servidor que roda no FreeBSD e usa TCP, notei que os testes de manutenção de atividade TCP são enviados mesmo que meu aplicativo desative explicitamente SO_KEEPALIVE em soquetes TCP.
De acordo comRFC1122 Seção 4.2.3.6(TCP Keep-Alives):
"Se os keep-alives estiverem incluídos, o aplicativo DEVE ser capaz de ativá-los ou desativá-los para cada conexão TCP, e eles DEVEM ser desativados por padrão."
Descobri que o parâmetro ajustávelnet.inet.tcp.always_keepalivehavia sido habilitado (definido como 1) e que desativá-lo impediria o envio dos testes de manutenção de atividade.
Qual é o raciocínio por trás da inclusão deste comportamento no FreeBSD? Pelo que sei, o Linux e o Windows não têm essa opção, mas o FreeBSD e o Mac OS X têm, portanto violam o RFC.
Para ser mais específico, em que circunstâncias faria sentido ignorar os desejos da aplicação?
Esta é uma solução simples no meu caso, pois posso desabilitar a opção, mas gostaria de entender por que ela está lá.
Essa questãomostra que o Linux se comporta de acordo com a RFC.
Responder1
A justificativa para ativar o keep-alive por padrão foi fornecida aqui:https://svnweb.freebsd.org/base?view=revision&revision=47752
Adicione o identificador para controlar os keepalives globais do TCP e ative-os como padrão.
Apesar do nome, ele não mantém as sessões TCP ativas, ele as mata se a outra extremidade estiver ausente. Isso acontece muito com clientes que usam NAT, atribuição de IP dinâmico ou que têm um limite superior de 2 ^ 32 * 10 ^ -3 segundos em seu tempo de atividade.
Não há aumento detectável no tráfego de rede por causa disso: dois pacotes TCP mínimos a cada duas horas para uma conexão TCP ativa.
Muitos servidores já habilitam os próprios keepalives.
A RFC de requisitos de host tem 10 anos e não sabe sobre a perda de clientes da Internet atual.
De qualquer forma é melhor desligar o keep-alive se solicitado pela aplicação, por exemplo (em C):
int val = 0;
setsockopt(s, SOL_SOCKET, SO_KEEPALIVE, &val, sizeof(val));
mas não é fácil consertar isso.
Responder2
Acho que o botão ajustável deveria existir, mas talvez fosse melhor mantê-lo desligado por padrão.
Meu raciocínio é o seguinte: um desenvolvedor de aplicativos pode tomar decisões erradas e, em última análise, um administrador de sistema deve ter controle sobre esse tipo de política de rede, não o desenvolvedor do aplicativo.