Como essas configurações padrão do TCP TCP foram decididas?

Question

Eu passei um bom tempo rastreando um problema na produção recentemente, onde um servidor de banco de dados desaparecia causando um atraso de até 2 horas (espera longa por uma chamada de poll() na biblioteca cliente da libpq) para um cliente conectado. Analisando o problema, percebi que esses parâmetros do kernel devem ser ajustados para que as conexões TCP interrompidas sejam percebidas em tempo hábil:

net.ipv4.tcp_keepalive_time = 7200 net.ipv4.tcp_keepalive_probes = 9 net.ipv4.tcp_keepalive_intvl = 75 net.ipv4.tcp_retries2 = 15

Os quatro valores acima são de uma máquina Ubuntu 12.04, e parece que estes padrões são inalterados do atual Padrões do kernel do Linux .

Essas configurações parecem ser strongmente tendenciosas no sentido de manter uma conexão existente aberta e de serem extremamente mesquinhas com testes keepalive. AIUI, o padrão tcp_keepalive_time de 2 horas significa quando estamos aguardando uma resposta para um host remoto, vamos esperar pacientemente por 2 horas antes de iniciar um probe keepalive para verificar se a nossa conexão ainda é válida. E então, se o host remoto não responder a um probe keepalive, tentaremos novamente esses testes 9 vezes ( tcp_keepalive_probes ), espaçados de 75 segundos ( tcp_keepalive_intvl ), então são 11 minutos extras antes de decidirmos se a conexão é realmente morto.

Isso corresponde ao que eu vi no campo: por exemplo, se eu iniciar uma sessão psql conectada a uma instância remota do PostgreSQL, com alguma consulta aguardando uma resposta, por exemplo,

SELECT pg_sleep(30);

e depois o servidor remoto morre horrivelmente (por exemplo, o tráfego cai para aquela máquina), vejo minha sessão psql esperando por até 2 horas e 11 minutos antes de descobrir que sua conexão está inativa. Como você pode imaginar, essas configurações padrão causam sérios problemas para o código em que conversamos com um banco de dados durante, digamos, um evento de failover do banco de dados. Virar estes botões ajudou bastante! E vejo que estou não só recomendando que esses padrões sejam ajustados.

Então, minhas perguntas são:

• Há quanto tempo os padrões são assim?
• Qual foi a justificativa original para tornar essas configurações TCP o padrão?
• Alguma distribuição do Linux altera esses valores padrão?

E qualquer outra história ou perspectiva sobre a lógica dessas configurações seria apreciada.

    

Answer 1

A RFC 1122 especifica na seção 4.2.3.6 que o período de manutenção não deve ser padronizado para menos de duas horas.