O que significa uma sequência de retransmissões com PSH, significam as sinalizações ACK (e uma retransmissão espúria)?

Question

Estou no servidor 192.168.0.2 e quero fazer uma chamada HTTP para 192.168.0.1 (os dois servidores são RPis e executam o Linux (raspbian)).

curl -XGET http://192.168.0.1:8081/api

A API em 192.168.0.1 (que estou chamando) é minha (um script Python baseado em bottle ) e funciona na maior parte do tempo. a parte de escuta HTTP, às vezes, misteriosamente trava, o que resulta com a chamada curl acima suspensa e, em seguida, o tempo limite.

Corri tcpdump no 192.168.0.1 (o servidor de recebimento, aquele que hospeda a API) quando a API não era responsiva e a análise wireshark mostra algumas retransmissões logo após a chamada ser iniciada:

Qualégeralmenteacausadetalcomportamento?(sehouverumacausa"normal").

Nota 1: Modificarei, se necessário, a API para que registre mais dados para a parte do servidor web, mas devido à natureza não reprodutível do travamento, duvido que seja culpa dela (as outras partes (threads) funcionam muito bem e não há nenhum acidente de qualquer discussão).

Nota 2: reiniciando o servidor (provavelmente reiniciando o script em si (o que eu não faço como prefiro reiniciar a máquina)) corrige o problema.

    

Answer 1

What does a sequence of retransmissions with PSH,ACK flags mean (and a spurious retransmission back)?

What is usually the cause of such behaviour? (if there is a "usual" cause).

PSH ACK Rastreamento Wireshark

(Veja também ServerFault - PHA ACK durante meu    Conexão )

ACK means that the machine sending the packet with ACK is acknowledging data that it had received from the other machine. In TCP, once the connection is established, all packets sent by either side will contain an ACK, even if it's just re-acknowledging data that it's already acknowledged.

PSH is an indication by the sender that, if the receiving machine's TCP implementation has not yet provided the data it's received to the code that's reading the data (program, or library used by a program), it should do so at that point. To quote RFC 793, the official specification for TCP:

The data that flows on a connection may be thought of as a stream of octets. The sending user indicates in each SEND call whether the data in that call (and any preceeding calls) should be immediately pushed through to the receiving user by the setting of the PUSH flag.

A sending TCP is allowed to collect data from the sending user and to send that data in segments at its own convenience, until the push function is signaled, then it must send all unsent data. When a receiving TCP sees the PUSH flag, it must not wait for more data from the sending TCP before passing the data to the receiving process.

Retransmissões espúrias

If you’re seeing spurious retransmissions it means that the sender thought packets were lost and sent them again, even though the receiver sent an acknowledge packet for it.

Causas possíveis

• Um erro de configuração entre as máquinas do servidor e do cliente
• Um erro de configuração entre qualquer remetente e destinatário em qualquer lugar ao longo do caminho de salto dos pacotes TCP
• Regras de firewall ou pacotes de bloqueio de pacotes de pacotes

Solução adicional de aditonal

• Verifique os registros do servidor quando isso ocorrer também
• Execute o rastreamento TCP com o Wireshark no servidor para ver como esses pacotes se parecem quando o problema ocorre