Sequência de terminação TCP estranha

Question

Enquanto resolvendo outra coisa, notei que um padrão estranho de TCP é encerrado.

Pacotes: link

O que está acontecendo é que os últimos pacotes da sequência de fechamento estão sendo retransmitidos por algum motivo estranho. O padrão está no link cloudshark, mas para a posteridade, aqui está um resumo:

1. Origem - > Syn
2. Dest - > Ack
3. Origem - > SynAck
4. Dados
5. Dados
6. Origem - > Fin / Ack
7. Dest - > Psh / Ack (6)
8. Dest - > Fin / Ack
9. Origem - > Ack (7)
10. Origem - > Ack (8)
11. [Neste ponto, a conexão deve ser fechada em ambos os lados. Mas não é.]
12. [+ 200ms] Dest - > Fin / Ack
13. Origem - > Ack (8 e 12)

Algo no sistema de destino está esperando 200ms antes de reemitir o pacote Fin / Ack. Isso é bastante consistente em várias transações. Mais condenável, esse padrão se replica nos dois lados da transação: ele aparece em capturas em ambos os hosts. Não é tão simples quanto o pacote Fin / Ack ser descartado em algum lugar e ser retransmitido. Ou talvez esteja sendo descartado, mas em um nível acima em que tcpdump opera.

O atraso de 200 ms me faz pensar que o TCP Delayed Ack está envolvido aqui, mas estou com dificuldades para descobrir o porquê.

É acima do tcpdump mesmo uma coisa?

Este é um padrão de conexão normal para sistemas RHEL6?

    

Answer 1

Observe que o pacote PSH / ACK no quadro 2 de sua captura está carregando 37 bytes de dados. Não é uma resposta à solicitação FIN de 10.232.16.133. A resposta segue no quadro # 3, o ACK para isso está no quadro # 5.

O que parece estar acontecendo agora é que este último ACK não chega ao destino, então o FIN / ACK enviado no quadro 3 é retransmitido no quadro # 6. O atraso de ~ 200 ms que você está vendo aqui não é o ack atrasado, mas o mais provável é o tempo limite de retransmissão. Você deve ser capaz de verificar isso olhando para a captura de pacotes do outro lado da conexão, onde você nunca deve ver o último ACK chegando.

Se você vir esse comportamento consistentemente em todas as conexões (e possivelmente em ambas as direções), uma explicação cruzando minha mente é que algum filtro de pacotes de manutenção de estado no caminho está engolindo o último ACK.