Enfrentando problemas devido à Reutilização de Porta TCP e Retransmissão para tráfego HTTP.
Minha implantação é a seguinte:
Eutenhoumproxydesquidinstaladoemumamáquinaunixqueestáenviandosolicitaçõeshttpdemanipulaçãodeumafonteconfiável.OSquidentãoencaminhaparaumfiltrodeURLquetemumalistadelistasbrancasenegras.EstemecanismodefiltragemdeURLquepermitirá/bloquearURLdeacordocomaregra.
Doclienteeuexecuteiumscriptquefazowget500parawww.naukri.comemumloopcontinuamente.EsteURLeubloqueeinomecanismodefiltragemdeURLs.
Apósalgunspedidos~120wgetfoipenduradonomeioporexatamente1min.Duranteesteestadoenforcado,eupegueiotcpdumpnoservidoredescobriqueeleestámostrando"números de porta TCP reutilizados" e inicio o envio do pacote de sincronização com a mesma porta que foi usada anteriormente e mostrando "TCP Retransmisson". Também FIN, ACK e RST recebidos pela solicitação anterior.
Anexando a captura de tela tcp dump para referência:
Por favor, deixe-me saber por que está usando a mesma porta para a nova solicitação e retransmitindo o pacote novamente? Existe uma maneira de evitar a reutilização de portas?
why it is using same port for the new request and re-transmitting the packet again?
Ele reutiliza a mesma porta porque é mais eficiente fazer isso.
retransmitir? O que retransmite? Pode haver retransmissões de pacotes, mas esses devem ser completamente separados do problema de reutilização da porta.
Acabei de acertar um problema semelhante. (Com lockd não httpd).
O problema aqui é que seu servidor remoto é aquele que fechou a conexão, com um pacote FIN.
Quando isso acontece, ele coloca a conexão em um estado TIME_WAIT - que, supostamente, deve ignorar quaisquer pacotes adicionais, caso haja fragmentos adicionais ainda em rota / passando por rotas de rede diferentes.
Portanto, ele está ignorando os pacotes de adição enviados pelo seu aplicativo, até que TIME_WAIT expire no servidor.
Seu cliente não recebe um ACK para esses pacotes, então ele retransmite. (Que também são ignorados, até que TIME_WAIT expire.
Por que ele enviou um pacote FIN? Difícil de dizer. Isso é para o servidor. Mas se você parecia um ataque de negação de serviço, pode ser por isso.
Mas você deve realmente interceptar o estado CLOSE_WAIT em seu cliente e não reutilizar seu soquete se isso acontecer.
Reutilizar as portas TCP não é uma coisa ruim em si. Como o syccbean apontou, é mais eficiente e pode ser tão evidente no seu exemplo, porque você está rapidamente abrindo muitos novos soquetes. Eu vejo na captura de tela da sua captura que foram 2 segundos desde que você iniciou o processo e você mencionou ficar preso após ~ 120 conexões, o que é um bom número de novas conexões em 2 segundos.
As retransmissões que você está vendo provavelmente se devem a alguém na rede que está removendo outros pacotes SYN de você. 60 novas conexões por segundo do mesmo host são consideradas prejudiciais por praticamente todas as redes e administradores de segurança existentes, e qualquer configuração padrão em um firewall ou mesmo em um proxy começará silenciosamente a diminuir o tráfego.
Se você está tentando simular a carga do usuário, temo que não esteja fazendo certo. 60 novas conexões por segundo de vários hosts diferentes é mais do que OK, mas não é realista se elas vierem de um único host. Na verdade, o navegador de um usuário limitará as conexões a um único host a um número entre 6 e 12 simultâneos (dependendo do navegador e da versão). Alguns navegadores consideram o proxy como um único host, mas outros também têm limites diferentes para o proxy (até 15 simultâneos também).
Você pode ignorar limites no Squid ajustando a configuração, mas, novamente, é um teste irrealista.
Tags networking squid tcp