Raciocínio Lógico em Problemas de Rede

Caso Clássico 1

Muitos profissionais de software carecem de conhecimento aprofundado sobre a lógica de raciocínio TCP/IP, o que frequentemente leva à identificação equivocada de problemas como problemas misteriosos. Alguns são desencorajados pela complexidade da literatura de redes TCP/IP, enquanto outros são induzidos ao erro por detalhes confusos no Wireshark. Por exemplo, um DBA enfrentando problemas de desempenho pode interpretar erroneamente os dados de captura de pacotes no Wireshark, concluindo erroneamente que as retransmissões TCP são a causa.

Como a retransmissão é suspeitada, é essencial compreender sua natureza. A retransmissão envolve fundamentalmente a retransmissão por timeout. Para confirmar se a retransmissão é de fato a causa, são necessárias informações relacionadas ao tempo, que não são fornecidas na captura de tela acima. Após solicitar uma nova captura de tela ao DBA, as informações de timestamp foram incluídas.

Ao analisar pacotes de rede, as informações de timestamp são cruciais para um raciocínio lógico preciso. Uma diferença de tempo na faixa de microssegundos entre dois pacotes duplicados sugere retransmissão por timeout ou captura de pacote duplicado. Em um ambiente LAN típico com um Tempo de ida e volta (RTT) de cerca de 100 microssegundos, onde TCP retransmissões requerem pelo menos um RTT, uma retransmissão ocorrendo em apenas 1/100 do RTT provavelmente indica captura de pacote duplicado em vez de uma retransmissão real por timeout.

Caso Clássico 2

Outro caso clássico ilustra a importância do raciocínio lógico na análise de problemas de rede.

Um dia, um desenvolvedor de negócios chegou correndo, dizendo que um script agendado usando o middleware de banco de dados MySQL havia falhado nas primeiras horas da manhã sem resposta. Ao ouvir sobre o problema, verifiquei os logs de erro do middleware de banco de dados MySQL, mas não encontrei pistas valiosas. Então, perguntei aos desenvolvedores se poderiam reproduzir o problema, sabendo que, uma vez reproduzível, um problema se torna mais fácil de resolver.

Os desenvolvedores tentaram várias vezes reproduzir o problema, mas não tiveram sucesso. No entanto, fizeram uma nova descoberta: descobriram que a execução das mesmas consultas SQL durante o dia resultava em tempos de resposta diferentes em comparação com as primeiras horas da manhã. Eles suspeitaram que, quando a resposta SQL era lenta, o middleware de banco de dados MySQL estava bloqueando a sessão e não retornando resultados ao cliente.

Com base nessa percepção, a equipe de operações de banco de dados foi solicitada a modificar o SQL do script para simular uma resposta SQL lenta. Como resultado, o middleware de banco de dados MySQL retornou os resultados sem encontrar o problema de travamento observado nas primeiras horas da manhã.

Por um tempo, a causa raiz não pôde ser identificada, e os desenvolvedores descobriram um problema funcional com o middleware de banco de dados MySQL. Portanto, os desenvolvedores e as operações de DBA ficaram mais convencidos de que o middleware de banco de dados MySQL estava atrasando as respostas. Na realidade, esses problemas não estavam relacionados aos tempos de resposta do middleware de banco de dados MySQL.

Com os eventos do primeiro dia, o problema realmente ocorreu. Todos os envolvidos tentaram identificar a causa, fazendo várias suposições, mas a verdadeira razão permaneceu elusiva.

No dia seguinte, os desenvolvedores relataram que o problema de script havia recorrido de manhã cedo, mas eles não conseguiram reproduzi-lo durante o dia. Sentindo-se pressionados, pois o script logo seria usado online, os desenvolvedores reclamaram da situação. Minha única sugestão foi que usassem o script durante o dia para evitar problemas de manhã cedo. Com todas as suspeitas concentradas no middleware do banco de dados MySQL, foi desafiador analisar o problema por outras perspectivas.

Como desenvolvedor responsável pelo middleware do banco de dados MySQL, problemas misteriosos como esse não podem ser facilmente ignorados. Ignorá-los poderia afetar o uso subsequente do middleware do banco de dados MySQL, e também há pressão da liderança para resolver o problema prontamente. Finalmente, decidiu-se implementar uma solução de análise de captura de pacotes de baixo custo: durante a execução do script de manhã cedo, seriam realizadas capturas de pacotes no servidor para analisar o que estava acontecendo naquele momento. O objetivo era determinar se o middleware do banco de dados MySQL não enviou uma resposta ou se enviou uma resposta que o script do cliente não recebeu. Uma vez confirmado que o middleware do banco de dados MySQL enviou uma resposta, o problema não seria atribuído aos desenvolvedores do middleware do banco de dados MySQL.

No terceiro dia, os desenvolvedores relataram que o problema da manhã não se repetiu, e a análise da captura de pacotes confirmou que o problema não ocorreu. Após cuidadosa consideração, parecia improvável que o problema estivesse apenas no middleware do banco de dados MySQL: as ocorrências frequentes de manhã cedo e as ocorrências raras durante o dia eram intrigantes. A única ação a ser tomada era esperar que o problema ocorresse novamente e analisá-lo com base nas capturas de pacotes.

No quarto dia, o problema não surgiu novamente.

No entanto, no quinto dia, o problema finalmente reapareceu, trazendo esperança de resolução.

Os arquivos de captura de pacotes são numerosos. Primeiro, peça aos desenvolvedores para fornecer o carimbo de data/hora em que o problema ocorreu, em seguida, pesquise os extensos dados de captura de pacotes para identificar a consulta SQL que causou o problema. O resultado final é o seguinte:

A partir do conteúdo da captura de pacotes acima (capturado do servidor), parece que a consulta SQL foi enviada às 3 da manhã. O middleware do banco de dados MySQL levou 630 segundos (03:10:30.899249-03:00:00.353157) para retornar a resposta SQL para o cliente, indicando que o middleware do banco de dados MySQL realmente respondeu à consulta SQL. No entanto, apenas 238 microssegundos depois (03:10:30.899487-03:10:30.899249), a camada TCP do servidor recebeu um pacote de reset, que foi suspeitosamente rápido. É importante notar que este pacote de reset não pode ser imediatamente assumido como vindo do cliente.

Primeiramente, é necessário confirmar quem enviou o pacote de reset — se foi enviado pelo cliente ou por um dispositivo intermediário ao longo do caminho. Como a captura de pacotes foi realizada apenas do lado do servidor, informações sobre a situação do pacote do cliente não estão disponíveis. Ao analisar os arquivos de captura de pacotes do lado do servidor e aplicar raciocínio lógico, o objetivo é identificar a causa raiz do problema.

Se a suposição for feita de que o cliente enviou um reset, isso implicaria que a camada TCP do cliente não reconhece mais o estado TCP dessa conexão — passando de um estado estabelecido para um inexistente. Essa mudança no estado TCP notificaria o aplicativo do cliente sobre um problema de conexão, fazendo com que o script do cliente falhasse imediatamente. No entanto, na realidade, o script do cliente ainda está aguardando a resposta. Portanto, a suposição de que o cliente enviou um reset não se sustenta — o cliente não enviou um reset. A conexão do cliente ainda está ativa, mas do lado do servidor, a conexão correspondente foi encerrada pelo reset.

Quem enviou o reset, então? O principal suspeito é o ambiente de nuvem da Amazon. Com base nessa análise de captura de pacotes, as operações de DBA consultaram o serviço de atendimento ao cliente da Amazon e receberam as seguintes informações:

A resposta do serviço ao cliente está alinhada com os resultados da análise, indicando que o ELB da Amazon (Balanceador de Carga Elástico, semelhante ao LVS) encerrou a sessão TCP de forma forçada. De acordo com o feedback deles, se uma resposta exceder o limite de 350 segundos (como observado na captura de pacotes como 630 segundos), o dispositivo ELB da Amazon envia um reset para a parte que responde (neste caso, o servidor). Os scripts do cliente implantados pelos desenvolvedores não receberam o reset e assumiram erroneamente que a conexão com o servidor ainda estava ativa. As recomendações oficiais para tais problemas incluem o uso de mecanismos de keepalive TCP para mitigar esses problemas.

Com a resposta oficial obtida, o problema foi considerado completamente resolvido.

Este caso específico ilustra como os problemas online podem ser altamente complexos, exigindo a captura de informações críticas — neste caso, dados de captura de pacotes — para entender a situação conforme ocorreu. Através do raciocínio lógico e da aplicação do reducionismo ao absurdo, a causa raiz foi identificada.