O que causa registros ACK duplicados?

Estamos analisando as capturas do Wireshark de algumas máquinas clientes que mostram vários registros ACK duplicados, que acionam pacotes de retransmissão e fora de sequência.

Eles são mostrados na captura de tela a seguir. .26 é cliente e .252 é servidor.

O que causa os registros ACK duplicados?

Mais informações se ajudar:

Estamos investigando problemas de taxa de transferência de rede em um site específico do cliente. O problema percebido da perspectiva da interface do usuário é que os dados estão sendo transmitidos lentamente, apesar de uma conexão WAN de 1gbps subutilizada.

Quase todas as máquinas clientes têm o mesmo problema, testadas em mais de 20 máquinas. Encontramos duas máquinas que não têm o problema. Estamos identificando o que é diferente em sua configuração. Percebemos que nas duas máquinas que não apresentam o problema, apenas vimos no máximo um registro ACK duplicado. As máquinas que apresentam o problema geralmente têm três registros ACK duplicados. Uma diferença notável é que todas as máquinas que funcionam bem pertencem a membros da equipe de operações de rede e todas as outras máquinas são para funcionários "regulares". As máquinas deveriam ser padrão, mas os administradores de rede poderiam ter feito alterações em seus sistemas locais, que é outro aspecto que estamos pesquisando.

Tentamos alterar a configuração TcpMaxDupAcks no servidor, mas o valor que realmente precisamos é 5 e o intervalo válido é de apenas 1-3.

O servidor é o Windows Server 2003. Os clientes são todos Windows XP gerenciado pela empresa. Todos os clientes, incluindo os dois que trabalham, têm o antivírus da Symantec instalado.

Este é o único site cliente entre centenas que exibiu esse problema.

pathping mostra 56ms RTT e perda consistente de 0/100 pacotes, mesmo nas máquinas com problemas.

Obrigado,

Sam

Nota: Estou assumindo que essa captura foi feita na máquina cliente.

Um breve resumo sobre o seqüenciamento de TCP: O TCP fornece fluxos de bytes de maneira confiável entre dois aplicativos. "Confiável" neste caso significa que, entre outras coisas, o TCP garante nunca fornecer dados fora de ordem a um aplicativo de escuta.

A entrega confiável e em ordem é implementada através do uso de números de sequência. Cada pacote em cada fluxo recebe um número de sequência de 32 bits (lembre-se de que o TCP é efetivamente dois fluxos de dados independentes, A-> B e B-> A). Se A enviar um ACK para B, o valor no campo ACK é o próximo número de sequência que espera ver em B.

Pelo exposto, parece que pelo menos um segmento TCP sendo enviado do servidor para o cliente foi perdido. As três ACKs duplicadas em sequência são uma tentativa do cliente de acionar uma retransmissão rápida . Quando um remetente TCP recebe 3 confirmações duplicadas para o mesmo dado (ou seja, 4 ACKs para o mesmo segmento, que não é o dado enviado mais recentemente), ele pode razoavelmente assumir que o segmento imediatamente após o segmento que está sendo ACK foi perdido na rede e resulta em uma retransmissão imediata.

Nesse caso, a retransmissão é concluída e é identificada pelo Wireshark como fora de serviço.

Conforme mencionado por joeqwerty , a perda de pacotes é geralmente causada por congestionamento. Também pode ser resultado de CRC ou outros erros em um link, devido a uma placa de interface ruim, cabo solto etc. Eu examinaria as estatísticas de todos os links ao longo do caminho para ver se algum deles é altamente utilizado e / ou estão enfrentando um grande número de erros.

Se você não conseguir ver nenhum candidato óbvio, execute capturas simultâneas de pacotes em vários pontos ao longo do caminho para tentar isolar onde a perda está ocorrendo.

Que tipo de conexão WAN está em uso aqui? É uma linha dedicada? Link VPN MPLS? VPN IPsec pela Internet pública? Algo mais?

Enquanto você estiver isolando onde está o problema, pense em um despejo de pacotes como apenas um dos sintomas ... Como analogia, se alguém entrar no consultório médico com dores no peito, o médico não passará três horas investigando a natureza de a dor. Ele gasta cerca de dois minutos nisso e, em seguida, sabe que 95% das causas são azia ou angina ... Da mesma forma, se você vê ACKs duplicados, não se preocupe imediatamente com as ervas daninhas do traço. .

Depois que a conexão é estabelecida, o desempenho lento do TCP nem sempre é devido a problemas na rede de trânsito; às vezes, é o resultado de limitações da CPU ou do disco do servidor ... e, ocasionalmente, devido a algum problema no PC cliente. Eu tenho perseguido minha cauda por semanas pesquisando as ervas daninhas dos traços do wireshark apenas para desistir e encontrar o problema relativamente rapidamente com o mtr , ou olhando para outras métricas de host, como CPU e E / S de disco.

Sua primeira tarefa é provar se esse é um problema de rede ou um nível de host. Foco no envio de tráfego real através de sua rede e provar se você é filas / soltura / re-ordenação ^{Nota 1} -lo; esse sempre é o resultado final de um possível problema de rede como esse .

Eu faria uma pingamostragem por um longo período de tempo (normalmente uma hora para mim) entre o cliente e o servidor enquanto o problema de taxa de transferência está acontecendo; você pode usar o mtr ou o ping plotter freeware para isso. Se você está constantemente perdendo pacotes em algum salto e depois todos os saltos perdem tanto ou mais , então você tem um potencial suspeito de rede. Lembre-se de que a limitação de taxa de ICMP do dispositivo pode fazer com que alguns saltos pareçam perder pacotes ... é por isso que você deseja procurar uma tendência a partir desse salto e dos seguintes.

^{Nota 1} Se você estiver solicitando novamente o tráfego, ele será exibido rapidamente no campo de informações do especialista fornecido pelo wireshark

Vendo muitos [segmento TCP da PDU remontada] sem ACKs - eu diria que essas ACKs provavelmente são mostradas como [TCP Dup ACK ...] devido ao comportamento do reconhecimento seletivo (também conhecido como SACK) .

Exemplo:

• cliente envia partes de dados (..., 0,1,2,3,4,5,6, ...)

• servidor acked (0), então recebeu (2,4,3), então (5), então (6) e nunca conseguiu (1)

No cenário acima - o servidor pode legitimamente optar por aceitar o intervalo (2-4) primeiro, depois o intervalo (2-5) e depois o intervalo (2-6). Ao formar o pacote "(AB) range ack" - o servidor precisa especificar a última parte aceita (0) no cabeçalho TCP. O Wireshark marca os range-acks (SACKs) como [TCP Dup ACK ...] porque todos esses range-acks têm o mesmo valor de peça com último último registro no cabeçalho TCP (Ack = 872619 no seu caso).

ACKs duplicados em combinação com desempenho lento da rede me parecem um problema de congestionamento de rede. Veja o volume e a taxa de tráfego de transmissão na rede. Verifique as transmissões da camada física e da camada de rede, bem como as multicasts.