Na verdade, só preciso de ajuda para entender a imagem a seguir, mas darei o contexto para contextualizar.
Temos um aplicativo configurado para usar proxy na porta 8080 e requer acesso à Internet. Em horários aleatórios ao longo do dia, o aplicativo não consegue se conectar e simplesmente morre. Estamos tentando descobrir a causa. Excluímos as regras de FW e URL de proxy (ele sempre atinge o mesmo URL quando funciona e falha de qualquer maneira). Acho que o problema está relacionado à rede e a um problema de desempenho no próprio proxy. Para chegar ao fundo da questão, tenho feito capturas de rede quando isso acontece.
Se você observar a imagem a seguir, verá que é um trecho com os detalhes do IP removidos. A primeira linha com origem "42" é a máquina cliente fazendo uma solicitação TLS através do proxy (IP 35) na porta 8080. NOTA: Geralmente funciona e solicita a mesma URL/IP, mas esta é uma das vezes em que falhou. A janela inferior contém os detalhes da primeira linha verde.
A parte destacada "Próximo número de sequência" corresponde ao ACK do último pacote retornado de 35 (da segunda à última linha). Isso é essencialmente uma resposta ao cliente informando que ele recebeu todos os dados que foram enviados a ele (isso significa que o dispositivo está ativo ao confirmar o recebimento dos dados (ou seja, sem FW ou problemas de rede)). Observe que ele não envia nenhum dado de volta. Imediatamente depois disso, o cliente emite um TCP RST. Aqui está minha interpretação, mas gostaria que alguém verificasse, pois minhas habilidades em TCP estão um pouco enferrujadas.
O cliente está enviando algum tipo de solicitação ao proxy, mas por algum motivo o proxy não está respondendo (na camada de aplicação). Como o proxy responde com TCP ACKs, isso significa que na camada de rede está tudo bem. Isso implicaria que, quando os dados são passados pela pilha de rede para o próprio proxy, é o proxy que está interrompendo a conexão. Ainda não sei por que isso acontece, mas estou procurando esclarecimentos para poder falar com a equipe de proxy e dizer que precisam investigar isso (eles não acham que seja o proxy).
Outra evidência para apoiar meu caso é que as 4 primeiras linhas que você vê na imagem antes do RST são repetidas muitas vezes. Novamente, isso implica que o cliente está reenviando qualquer solicitação que tenha, mas nunca obtém uma resposta; e então eventualmente desiste e emite uma redefinição.
Aparentemente, há um balanceador de carga localizado na frente do proxy, e o proxy consiste, na verdade, em várias máquinas. Tenho a sensação de que há um problema com um deles no back-end e o LB não está removendo o nó do pool e, portanto, envia os dados potencialmente para um buraco negro.
Estou procurando uma segunda opinião. Este resumo acima parece preciso com base na captura?
Responder1
Imediatamente depois disso, o cliente emite um TCP RST
Não imediatamente. O RST é enviado pelo cliente 30 segundos após o último ACK ter sido enviado pelo servidor.
... as 4 primeiras linhas que você vê na imagem antes do RST são repetidas muitas vezes
Estas não são as mesmas linhas. Eles têm um valor diferente para ACK.
Minha interpretação aqui é que o cliente está enviando uma solicitação com uma carga útil maior (daí o ACK múltiplo do servidor para confirmar isso) e então espera que o proxy envie a resposta de volta. Após 30 segundos sem resposta o cliente desiste e fecha a conexão com o RST.
Não está claro por que o proxy não envia uma resposta. Pode ser um problema do proxy. Mas também pode ser um problema do servidor upstream e o servidor apenas propaga o problema para o cliente.
Observe que a interpretação pode estar errada. Não há muito contexto e captura de pacotes fornecidos, por isso é mais uma suposição fundamentada.