Qual é o custo de muitos TIME_WAIT no lado do servidor?

Question

Vamos supor que há um cliente que faz um monte de ligações curtas-estar para um servidor.

Se o cliente fecha a conexão, haverá muitos portos no estado TIME_WAIT no lado do cliente. Desde que o cliente fica sem portas locais, torna-se impossível fazer uma nova tentativa de conexão rápida.

Se o servidor fecha a conexão, vou ver muitos TIME_WAITs no lado do servidor. No entanto, isso faz algum mal? O cliente (ou outros clientes) pode continuar a fazer tentativas de conexão, uma vez que nunca se esgota de portas locais, e o número de estado TIME_WAIT vai aumentar no lado do servidor. O que acontece, eventualmente? Será que algo de ruim acontecer? (Desaceleração, acidente, ligações interrompidas, etc.)

Por favor note que a minha pergunta não é "Qual é o propósito de TIME_WAIT?" mas "O que acontece se há tantos estados TIME_WAIT no servidor?" Eu já sei o que acontece quando uma conexão é fechada em TCP / IP e por estado TIME_WAIT é necessária. Eu não estou tentando problema shoot-lo, mas só quero saber qual é o potencial problema com ele.

Para colocar simplesmente, digamos impressões netstat -nat | grep :8080 | grep TIME_WAIT | wc -l 100000. O que aconteceria? A Rede O / S pilha para baixo lenta? erro "Muitos arquivos abertos"? Ou, simplesmente nada para se preocupar?

Answer 1

Cada tomada em TIME_WAIT consome alguma memória no kernel, geralmente um pouco menos de uma tomada ESTABLISHED ainda assim significativo. Um número suficientemente grande pode esgotar a memória do kernel, ou, pelo menos, degradar o desempenho, pois que a memória pode ser usado para outros fins. soquetes TIME_WAIT não possuem descritores de arquivos abertos (supondo que eles tenham sido fechada corretamente), então você não precisa se preocupar com um erro "muitos arquivos abertos".

A tomada também liga-se que determinado src / dst endereço IP ea porta para que ele não pode ser reutilizada para a duração do intervalo TIME_WAIT. (Esta é a finalidade do estado TIME_WAIT.) Amarrar-se a porta não é geralmente um problema a menos que você precisa se reconectar um com o mesmo par de portas. Na maioria das vezes um lado vai usar uma porta efémera, com apenas um lado ancorada a uma porta bem conhecido. No entanto, um número muito grande de soquetes TIME_WAIT pode esgotar o espaço de porta efêmera se você é repetidamente e muitas vezes de ligação entre os mesmos dois endereços IP. Note que este afeta somente esta par de endereços IP particular, e não vai afetar o estabelecimento de ligações com outros hosts.

Answer 2

Os resultados até agora:

Mesmo que o servidor fechou o soquete usando a chamada de sistema, o seu descritor de arquivo não será liberado se ele entra no estado TIME_WAIT. O descritor de arquivo será lançado mais tarde, quando o estado TIME_WAIT é ido (ou seja, após 2 segundos * MSL). Portanto, muitas TIME_WAITs vai possivelmente levar a erro 'muitos arquivos abertos' no processo do servidor.

Eu acredito O / S pilha TCP / IP foi implementada com estrutura de dados adequada (por exemplo, tabela hash), de modo que o número total de TIME_WAITs não deve afetar o desempenho do O / S TCP / IP pilha. Apenas o processo (servidor) que detém os soquetes no estado TIME_WAIT vai sofrer.

Answer 3

Cada conexão é identificado por uma tupla (servidor IP, porta do servidor, IP do cliente, porta de cliente). Fundamentalmente, as conexões TIME_WAIT (se eles estão do lado do servidor ou do lado do cliente) cada ocupar uma dessas tuplas.

Com os TIME_WAITs no lado do cliente, é fácil ver por que você não pode fazer mais conexões - você tem as portas não mais locais. No entanto, o mesmo problema se aplica no lado do servidor - uma vez que tem 64k conexões em estado TIME_WAIT para um único cliente , não pode aceitar mais conexões a partir desse cliente , porque não tem nenhuma maneira de dizer a diferença entre a velha conexão e a nova conexão - ambas as conexões são identificados pela mesma tupla. O servidor deve apenas enviar de volta RSTs a novas tentativas de conexão a partir desse cliente neste caso.

Answer 4

Se você tem um monte de conexões de muitos IPs cliente diferentes para os IPs de servidores que você pode correr em limitações da tabela de rastreamento de conexão.

Verifique:

sysctl net.ipv4.netfilter.ip_conntrack_count
sysctl net.ipv4.netfilter.ip_conntrack_max

Acima de tudo src ip / porto e dest tuplas ip / porta que você só pode ter net.ipv4.netfilter.ip_conntrack_max na tabela de rastreamento. Se este limite for atingido, você verá uma mensagem em seus logs "nf_conntrack: mesa cheia, pacotes caindo." eo servidor não aceitará novas conexões de entrada até que haja espaço na tabela de rastreamento novamente.

Esta limitação pode bater em você muito antes de as portas efêmeras esgotar-se.

Answer 5

Em meu cenário eu corri um script que agenda arquivos repetidamente, meu produto fazer alguns cálculos e envia resposta a isto é cliente cliente está fazendo uma chamada http repetitivo para obter a resposta de cada file.When cerca de 150 arquivos estão programadas portas de soquete em meu servidor vai em TIME_WAIT estado e uma exceção é lançada no cliente que abre uma conexão http ie

 Error : [Errno 10048] Only one usage of each socket address (protocol/network address/port) is normally permitted

O resultado foi que os meus hanged.I aplicação não sei pode ser threadshave ido em estado de espera ou o que aconteceu, mas eu preciso para matar todos os processos ou reiniciar o aplicativo para que ele funcione novamente.

Eu tentei reduzir o tempo de espera para 30 segundos, uma vez que é de 240 segundos, por padrão, mas não funcionou.

impacto Então, basicamente geral foi crítica como fez a minha candidatura não-responsivos

Answer 6

parece que o servidor pode apenas correr para fora de portas para atribuir para conexões de entrada (para a duração da TIMED_WAITs existentes.) - um caso para um ataque DOS