Segmentos TCP de uma solicitação HTTP na ordem errada

Question

Meu servidor de serviços da web às vezes não recebe solicitações HTTP corretas e retorna "500 - Erro interno do servidor". Usando tcpdump e Wireshark no servidor, descobri que as solicitações HTTP são divididas em 2 pacotes TCP e que, às vezes, o servidor tenta processar a solicitação antes que o segundo pacote chegue.

Esta captura de wireshark foi realizada no lado do servidor.

Então, o que eu vejo é isso:

• O primeiro fragmento da solicitação HTTP é recebido em 54.659
• É recebido novamente em 71.168
• O segundo (e último) fragmento da solicitação é recebido em 99.869 (ou seja, 45 segundos após o primeiro)
• Quatro milissegundos antes, em 99.865 , o tipo de servidor esgotou o tempo limite e tentou processar uma solicitação incompleta (que fornece um Erro 500)

Eu não sei onde procurar agora. Eu diria que é um problema de rede, mas eu tenho vários fluxos de TCP onde o servidor tenta processar a solicitação vários milissegundos antes de ser completamente recebido. Por outro lado, os pacotes TCP que levam mais de 45 segundos para chegar significam que a rede está muito ruim.

Você tem alguma indicação sobre como investigar mais?

    

Answer 1

I don't know where to look now

Em nenhum lugar. Sério.

Acontece.

hat is 45 seconds after the first one

Isso é HUGH. A sério. A latência da Internet na Europa para os EUA é de cerca de 150ms. Você é 30 vezes mais - é uma gota sem reenviar. Infelizmente, a menos que você controle AMBOS OS LADOS (!), Você não pode controlar o comportamento do cliente. Coisas assim acontecem.

Se essa é a sua LAN - ela é seriamente ruim. Isso é internet, é assim mesmo. A questão principal é o quão ruim é - se é "algumas conexões de milhares" poderia ser um problema sério de rede do outro lado. Se isso acontecer às vezes para quase todos, fica mais perto do seu lado (conexão, data center etc.). Ontem, por exemplo, nós tivemos uma situação como essa aqui - algum idiota do DDOS é um dos meus links. Um congestionamento sério poderia levar a que os pacotes fossem quase impossíveis de passar. Mas se isso não é você - não há nada que você possa fazer.

É como se alguém chegasse tarde demais a uma reunião e lhe dissesse que ele tinha um engarrafamento sério. a menos que o Jam esteja na sua rua você não pode saber. A Internet pode ser às vezes em lugares bastante ruins.

    

Answer 2

A retransmissão pode ser a pista. O cliente não recebeu o ACK que o servidor enviou para esse pacote. Os servidores também obtiveram dois SYNs da mesma porta de origem logo no início do despejo.

Os endereços IP são locais, por isso acho que isso não está acontecendo na Internet. Você tem acesso ao cliente?

Tente fazer o mesmo rastreamento de pacote no cliente e no servidor simultaneamente. Espero que você veja grandes discrepâncias entre o que é enviado e o que é recebido.

Em seguida, rastreie os cabos. Você tem latência e perda de pacotes tão grandes que eu estaria procurando por um espaço de ar que os elétrons estejam pulando quando a tensão subir o suficiente ou com um cabo Cat-5 com conexões enferrujadas e água pingando.

Substitua peças de rede (dispositivos, portas e cabos) até que o problema desapareça.

    

Answer 3

Já tentou especificar a capacidade de armazenamento em cache de suas respostas para impedir o armazenamento em cache por dispositivos intermediários?

Cache-Control: no-cache

ou

Cache-Control: private

link