Em resumo, eu tive um caso em que todos os threads do Apache estavam travados porque todos estavam esperando por um TCP ACK dos clientes depois de ter enviado a página HTTP, e por causa disso, os threads do Apache estavam esperando 300s (valor de Timeout de conf) antes de ir para o próximo pedido. E então aconteceu a mesma coisa.
As coisas aconteceram como estão: houve um pico repentino de tráfego, apache & o carregamento de servidores db aumenta conforme o esperado e, em algum momento, todos os segmentos do apache entram nesse estado e o apache & A carga do banco de dados vai para 0. E ficou assim por horas. Após o reinício do apache, as páginas são processadas normalmente novamente, a carga sobe e, novamente, isso acontece e a carga vai para 0.
Agora, se isso foi um ataque ou uma conseqüência de algum software / hardware ruim ainda não foi conhecido.
Para os detalhes: Quando tudo estiver desativado, você verá a página de status do servidor dos apaches, e todos os encadeamentos serão marcados como "W" (funcionando), e você verá o timer SS (horário em que a solicitação está sendo processada) subindo até 300s e, em seguida, vai ao lado da próxima solicitação HTTP e começa novamente em 300s.
Na parte de soquete via netstat, vemos todos os soquetes desses threads do Apache pendurados em CLOSE_WAIT com um alto valor Send-Q (pacotes enviados não reconhecidos).
Usando strace, nós realmente vemos o Apache fazendo uma pesquisa () de 300s no socket, esperando que os pacotes sejam reconhecidos.
Agora, seja um ataque ou alguma configuração de rede ruim que perdeu os pacotes, minha pergunta é: como evitar isso? Parece ser um tipo de ataque particularmente desagradável.
Estou ciente do ataque slow loris, quando você faz um pedido HTTP muito lentamente, e isso pode ser mitigado se você tiver um CDN, um proxy reverso, ...
Mas para este caso em particular, não estou vendo algo que possa impedir isso?
Como você evitaria que isso acontecesse?
Obrigado!