Obrigado por enviar essas capturas.
O problema
Os problemas de taxa de transferência parecem ser causados por uma implementação com bugs da aleatorização do número de seqüência TCP. Eu já vi isso no passado em Cisco ASAs.
Para dar um pouco de fundo, foi observado no passado que algumas implementações do TCP não usavam aleatoriedade suficiente ao escolher um Número de Sequência Inicial (ISN) que tornava mais fácil para os invasores manipularem as conexões TCP fazendo suposições o número da sequência seria.
Para tentar corrigir esse problema, alguns provedores de firewall implementaram um recurso chamado aleatoriedade do número de seqüência TCP, que reescreve o número Sequence (SEQ) para um valor mais aleatório, quando ele vê pacotes TCP fluindo pelo firewall. Infelizmente, algumas implementações desse recurso são um pouco problemáticas e não levam em conta o recurso de Confirmação Seletiva (SACK) dos TCPs.
Você pode ver a randomização do Número de Sequência em ação no seu rastreio. Observe o pacote SYN / ACK do servidor (captura de servidor de pacote # 51), onde você pode ver que o ISN escolhido é 2847541373 . No entanto, observe o mesmo pacote SYN / ACK quando ele é recebido no lado do cliente (captura de cliente do pacote nº 8), o ISN foi alterado para 2098751282 !
Este comportamento é bom até o ponto em que a perda de pacotes é experimentada na rede.
No lado do cliente, observe a primeira Confirmação Duplicada (Dup ACK) no pacote 259. Você pode ver que um bloco SACK foi configurado cobrindo os bytes 2098977399-2098978787. Este pacote informa efetivamente ao servidor, estou aguardando o pacote com a SEQ 2098974623, no entanto, recebi 2098977399-2098978787 para que você não precise enviá-los novamente.
Agora, se você observar o mesmo Dup ACK recebido no lado do servidor (# 369), poderá ver que o número ACK foi convertido corretamente pelo firewall (2098974623 > 2847764714); no entanto, o bloco SACK não tem e ainda mostra 2098977399-2098978787!
Quando um Dup ACK é recebido com um bloco SACK inválido, o Dup ACK é ignorado.
Como resultado, você perde a capacidade de usar Fast Retransmission (retransmitir após 3 ACKs duplicados recebidos) e depende exclusivamente dos tempos limite de retranmission. Isso é muito ruim para o desempenho e reduzirá substancialmente sua taxa de transferência.
Então, o que você pode fazer?
Você pode investigar se a randomização do Número de Seqüência do TCP ainda é necessária para seus propósitos e, caso contrário, considerar o teste com ele desativado. Talvez este problema tenha sido resolvido em um novo firmware?
Você também pode desativar a opção TCP SACK no (s) seu (s) servidor (es) para evitar que clientes usem SACK em primeiro lugar /proc/sys/net/ipv4/tcp_sack no entanto, note que SACK é significado a ser usado para melhorar O desempenho do TCP e o problema real são com a implementação de firewalls (buggy) da randomização do número de sequência. Desativar o SACK significa que os clientes do Dup ACK não serão mais ignorados e a conexão poderá se recuperar da perda muito mais rapidamente. A taxa de transferência deve subir.