Linux - Reutilização da porta de origem TCP (e atraso)

3

Temos um aplicativo que faz muitas chamadas para um servidor / serviço da web remoto. O aplicativo cliente é o JBoss / Java no Linux (Red Hat 5), o servidor remoto é o Windows 2008. Há um Cisco ACE no caminho, mas não há nenhum NAT acontecendo.

Estamos percebendo que, quando o Linux / JBoss reutiliza uma porta de origem para fazer a chamada HTTP, podemos obter "Conexão recusada". É quando o cliente reutiliza a porta de origem dentro de alguns minutos.

O que eu vejo quando rodando o tcpdump / wireshark em ambos os lados, é algo assim:

Solicitação nº 1: porta de origem 6666, porta de destino 80

Cliente - > Syn Servidor - > Syn ACK Cliente - > ACK Cliente - > PEGUE / Servidor - > Retorna dados Cliente - > ACK Servidor - > FIN ACK Cliente - > FIN ACK SERVIDOR - > ACK

Solicitação nº 2: a mesma porta de origem e destino é um sucesso.

Solicitação nº 3: a mesma porta de origem e destino é um sucesso.

Solicitação nº 4: a mesma porta de origem e destino, mas desta vez uma falha ("Conexão recusada") e é assim:

Cliente - > SYN Cliente - > SYN (retransmissão) Cliente - > RST, ACK

O servidor vê os dois SYNs, mas nunca envia um ACK ou o RST (ele vê o RST do cliente).

Depois de fazer algumas pesquisas, me deparei com um possível problema com o TCP Timestamps. Nós nos certificamos de que o ACE passaria por isso e eu posso verificar se o Windows está vendo isso. Eu também vejo a conexão em um estado TIME_WAIT no lado do servidor / Windows (mas eu vejo isso mesmo após o primeiro sucesso GET e # 2 e # 3 e todos esses foram bem sucedidos). A porta não está aberta ou em um TIME_WAIT no lado do cliente.

Um lugar em que estive olhando foi diminuir a entrada de registro TcpTimedWaitDelay no lado do Windows para 30 segundos. Eu não fiz isso ou testei isso, mas achei que deveria funcionar se o nosso problema estivesse presente.

Eu aumentei as portas no lado cliente / Linux para 15000 - 60000 (do padrão de 30000 para 60000), mas sem sucesso (apenas esperando que o aumento nas portas disponíveis se traduzisse em um tempo mais demorado devido à aleatoriedade em usar uma porta de origem)

Eu acho estranho que o servidor / Windows esteja vendo o SYN passar sem responder, fazendo-me pensar que o SYN é da sessão anterior ou algo assim.

Não tenho certeza se gostaria disso, mas gostaria de saber se existe uma maneira de dizer ao Linux para NÃO reutilizar uma porta de origem se ela tivesse sido usada recentemente? Como algum tipo de atraso nessa lógica (se houver)?

Não é como se estivéssemos ficando sem portas disponíveis ou algo assim, mas às vezes, por ser aleatório, uma porta de origem é reutilizada em alguns minutos e é quando vemos problemas.

Vocês têm alguma outra opinião sobre isso?

Obrigado!

UPDATE

Eu configurei o TcpTimedWaitDelay para 30 segundos no servidor Windows. Contanto que uma chamada com a porta de origem sendo reutilizada chegue depois dos 30 segundos, não há problemas.

Eu acredito que o ACE ainda é o culpado em alguns aspectos e pode ser algum tipo de proteção contra ataques SYN (o ACE é um dispositivo de segurança) como se eu ignorasse o ACE Eu não tenho problemas.

Mas ter 2MSL configurado para 30 segundos parece ser uma correção boa o suficiente por enquanto.

    
por matt 23.09.2013 / 20:04

1 resposta

2

Não sei o suficiente sobre o ciclo de soquete do Windows para responder a isso, mas acredito que o servidor feche as conexões e os soquetes estejam em TIME_WAIT state, onde eles não poderão ser usados novamente até que expirem.

A maneira "certa" de resolver esse problema é adicionar mais tuplas - aumentar as portas de saída no cliente (o que você fez), adicionar portas de escuta no servidor, adicionar aliases de IP nas interfaces e fazer com que os aplicativos usem esses IPs / portas adicionais.

Uma maneira "menos correta" é diminuir o tempo limite de TW, o que eu acho que você está fazendo com TcpTimedWaitDelay .

Uma maneira "não muito certa, mas ainda bastante popular" é permitir a reciclagem de soquete, o Linux tem opções tw_reuse e tw_recycle , talvez o Windows tenha um equivalente.

As duas últimas opções quebram o TCP RFC. Talvez o ACE tenha um problema em fazer isso?

    
por 03.07.2014 / 13:05