Benefícios reais do tcp TIME-WAIT e implicações no ambiente de produção

Question

ALGUMAS TEORIAS

Eu tenho feito algumas leituras em tcp TIME-WAIT ( aqui e há ) e o que eu li é que é um valor definido como 2 x MSL (duração máxima do segmento) que mantém uma conexão na "tabela de conexão" por um tempo para garantir isso, "antes de você poder criar uma conexão com a mesma tupla, todas as pacotes pertencentes a encarnações anteriores daquela tupla estarão mortos ".

Como os segmentos recebidos (com exceção do SYN em circunstâncias específicas) enquanto uma conexão está em TIME-WAIT ou não existe mais seria descartada, por que não fechar a conexão imediatamente?

Q1: É porque há menos processamento envolvido em lidar com segmentos de conexões antigas e menos processamento para criar uma nova conexão na mesma tupla quando em 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 eu vejo o TIME-WAIT sendo útil seria se um cliente enviasse um SYN para uma conexão antes de enviar segmentos restantes para uma conexão antiga na mesma tupla Nesse caso, o receptor reabriria a conexão, mas então obteria segmentos ruins e teria que terminá-la.

Q2: Esta análise está correta?
Q3: Existem outros benefícios em usar o TIME-WAIT?

ALGUMAS PRÁTICAS

Eu tenho olhado os gráficos munin em um servidor de produção que eu administro. Aqui está um:

Como você pode ver, há mais conexões em TIME-WAIT do que ESTABLISHED , cerca de duas vezes na maior parte do tempo, em algumas ocasiões quatro vezes mais.

Q4: Isso tem um impacto no desempenho?
Q5: Em caso afirmativo, é sensato / recomendado reduzir o valor de TIME-WAIT (e para qual)?
Q6: Essa proporção de TIME-WAIT / ESTABLISHED é normal? Isso pode estar relacionado a tentativas de conexão maliciosa?

    

Answer 1

Em suma, não se preocupe com TIME_WAIT . A sobrecarga é quase nenhuma e geralmente não apresenta problemas.

Em um servidor ocupado, a exaustão de porta é possível e, nesse caso, há a opção sysctl de net.ipv4.tcp_tw_reuse = 1 , que permite ao kernel reutilizar portas antigas que ainda estão em TIME_WAIT conforme necessário.

TIME_WAIT é parte da especificação TCP e está lá para capturar pacotes que ainda podem estar em trânsito (lembre-se, nem todas as conexões são confiáveis, e é isso que o TCP pretendia resolver). O valor de 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 estiver controlando o soquete e tiver certeza de que não está esperando pelos dados (por exemplo, você é o remetente final ou não se importa com uma resposta), feche o soquete após definir o SO_NOLINGER option, que terminará a conexão com um RST e descartará imediatamente o soquete.

Então, suas perguntas:

Q1, Q2, Q3: está lá para coletar os pacotes atrasados, "apenas no caso", porque os links podem não ser confiáveis. É parte da especificação, evita a perda de pacotes e o ajuste não tem nenhum benefício real.

Q4: não

Q5: Não se preocupe, e você tem a opção de forçar a reutilização desses soquetes, se necessário.

Q5: TIME_WAIT e ESTABLISHED não estão correlacionados, a não ser quanto mais conexões de curta duração você tiver, maior será essa proporção. Pode ser causado por algo mal-intencionado, mas não é mais um indicador do que "atividade de rede excessiva".

    

Answer 2

Algumas respostas da minha experiência limitada envolvendo TIME_WAIT:

1/2/3) Veja esta pergunta SO e esta página para uma boa explicação de TIME_WAIT. É menos um problema de desempenho e mais uma qualidade de serviço para garantir que todos os pacotes TCP em uma conexão sejam recebidos corretamente.

4/5) Um problema de desempenho relacionado a 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 com esse problema, tente reduzir o valor de TIME_WAIT, mas isso pode se enquadrar na categoria "Eu sei o que estou fazendo". Veja esta questão SO para uma mais alguns detalhes.

6) O valor padrão de TIME_WAIT "deveria" ser em torno de 240s (ou duas vezes o pacote MSL de 120s). Assim, a relação de conexões estabelecidas / espera dependerá da sua taxa de conexão de entrada e por quanto tempo elas permanecerão abertas. Por exemplo, eu verifiquei em alguns dos meus servidores ocupados e a taxa variou de 1,3 a 400, os quais eu consideraria normal com base no servidor e no tráfego que recebe.