ALGUMA TEORIA
Eu tenho lido algumas coisas sobre tcp TIME-WAIT(aquielá) e o que li é que é um valor definido como 2 x MSL(vida útil máxima do segmento) que mantém uma conexão na "tabela de conexões" por um tempo para garantir isso,"antes de você ter permissão para criar uma conexão com a mesma tupla, todos os pacotes pertencentes a encarnações anteriores dessa tupla estarão mortos".
Como os segmentos recebidos (além do SYN em circunstâncias específicas) enquanto uma conexão estiver ativa TIME-WAITou não existir mais seriam descartados, por que não encerrar a conexão imediatamente?
Q1: É porque há menos processamento envolvido no tratamento de segmentos de conexões antigas e menos processamento para criar uma nova conexão na mesma tupla quando estiver dentro TIME-WAIT(ou seja, há benefícios de desempenho)?
Se a explicação acima não for válida, a única razão pela qual vejo que isso TIME-WAITé útil seria se um cliente enviasse um SYNpara uma conexão antes de enviar os segmentos restantes para uma conexão antiga na mesma tupla, caso em que o receptor reabriria o conexão, mas obteria segmentos ruins e teria que encerrá-la.
Q2: Esta análise está correta?
P3: Existem outros benefícios em usar o TIME-WAIT?
ALGUMA PRÁTICA
Estive observando os gráficos do Munin em um servidor de produção que administro. Aqui está um:
Como você pode ver, há mais conexões em TIME-WAITdo que ESTABLISHED, na maioria das vezes, cerca de duas vezes mais, e em algumas ocasiões, quatro vezes mais.
Q4: Isso tem impacto no desempenho?
Q5: Em caso afirmativo, é sensato/recomendado reduzir o TIME-WAITvalor (e o que fazer)?
Q6: Esta proporção de TIME-WAIT/ ESTABLISHEDconexões é normal? Isso poderia estar relacionado a tentativas de conexão maliciosas?
Responder1
Resumindo, não se preocupe TIME_WAIT. A sobrecarga é quase nula e geralmente não apresenta problemas.
Em um servidor ocupado, o esgotamento de portas é possível e, nesse caso, existe a opção sysctl de net.ipv4.tcp_tw_reuse = 1, que permite ao kernel reutilizar portas antigas que ainda estão ativas TIME_WAITconforme necessário.
TIME_WAIT faz parte da especificação TCP e existe para capturar pacotes que ainda possam estar em trânsito (lembre-se, nem todas as conexões são confiáveis, e é isso que o TCP pretendia resolver). O valor do tempo limite pode ser muito alto para a maioria dos usos modernos, mas normalmente não interfere em nada além da saída do netstat.
Se você mesmo está no controle do soquete e tem certeza de que não está esperando por dados (por exemplo, você é o remetente final ou não se importa com uma resposta), você pode fechar o soquete após definir a SO_NOLINGERopção, que encerrará a conexão com um RSTe descartará imediatamente o soquete.
Então, suas perguntas:
Q1,Q2,Q3: Serve para coletar pacotes atrasados, "por precaução", porque os links podem não ser confiáveis. Faz parte das especificações, evita a perda de pacotes e ajustá-la não traz nenhum benefício real.
Q4: Não
Q5: Não se preocupe com isso, e você tem a opção de forçar a reutilização desses soquetes, se necessário.
Q5: TIME_WAITe ESTABLISHEDnão estão correlacionados, exceto quanto mais conexões de curta duração você tiver, maior será essa proporção. Pode ser causado por algo malicioso, mas não é um indicador mais do que "atividade excessiva de rede".
Responder2
Algumas respostas da minha experiência limitada envolvendo TIME_WAIT:
1/2/3) Veja istoEntão perguntaeesta páginapara uma boa explicação de TIME_WAIT. É menos uma questão de desempenho e mais uma questão de qualidade de serviço garantir que todos os pacotes TCP em uma conexão sejam recebidos corretamente.
4/5) Um problema de desempenho relacionado ao TIME_WAIT é que em um servidor muito ocupado você pode eventualmente ficar sem conexões disponíveis se tiver muitas no estado TIME_WAIT. Se você estiver enfrentando esse problema, você pode tentar reduzir o valor TIME_WAIT, mas isso pode cair na categoria de ajuste "Eu sei o que estou fazendo". Veresta pergunta SOpara mais alguns detalhes.
6) O valor padrão de TIME_WAIT "deveria" ser em torno de 240s (ou duas vezes o MSL do pacote de 120s). Assim, a proporção de conexões estabelecidas/em espera dependerá da taxa de conexão de entrada e de quanto tempo elas permanecem abertas. Por exemplo, verifiquei alguns dos meus servidores ocupados e a proporção variou de 1,3 a 400, o que eu consideraria normal com base no servidor e no tráfego que ele recebe.