O que causa registros ACK duplicados?

Question

Estamos revisando as capturas do Wireshark de algumas máquinas clientes que estão exibindo vários registros ACK duplicados que, por sua vez, disparam pacotes de retransmissão e fora de sequência.

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

OquecausaosregistrosACKduplicados?

Maisinformações,seajudar:

Estamosinvestigandoaspreocupaçõesdetaxadetransferênciaderedeemumsitedeclienteespecífico.Oproblemapercebidodeumaperspectivadeinterfacedousuárioéqueosdadosestãosendotransmitidoslentamente,apesardeumaconexãoWANde1Gbpssubutilizada.

Quasetodasasmáquinasclientestêmomesmoproblema,testadasemmaisde20máquinas.Nósencontramosduasmáquinasquenãotêmoproblema.Estamosnoprocessodeidentificaroqueédiferenteemsuaconfiguração.Nósnotamosquenasduasmáquinasquenãotêmoproblema,nóssóvimosnomáximoumregistroACKduplicado.AsmáquinasquetêmoproblemageralmentetêmtrêsregistrosACKduplicados.Umadiferençanotáveléquetodasasmáquinasquefuncionambempertencemamembrosdaequipedeoperaçõesderedeetodasasoutrasmáquinassãoparafuncionários"regulares". As máquinas devem ser padrão, mas os administradores de rede podem 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 é de 5 e o intervalo válido é de apenas 1-3.

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

Este é o único site de centenas de clientes que exibiu esse problema.

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

Obrigado,

Sam

    

Answer 1

Observação: suponho que essa captura tenha sido feita na máquina do cliente.

Um breve resumo sobre o sequenciamento TCP: O TCP fornece fluxos de bytes confiáveis entre dois aplicativos. "Confiável" neste caso significa que, entre outras coisas, o TCP garante nunca entregar dados fora de ordem para 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 é atribuído um número de seqüência de 32 bits (lembre-se que o TCP é efetivamente dois fluxos independentes de dados, A- > B e B- > A). Se A envia um ACK para B, o valor no campo ACK é o próximo número de sequência esperado para B.

Do acima, parece que pelo menos um segmento TCP sendo enviado do servidor para o cliente foi perdido. Os três ACKs duplicados 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 fragmento de dados (ou seja, 4 ACKs para o mesmo segmento, que não são os dados enviados mais recentemente), pode presumir que o segmento imediatamente após o segmento ser confirmado foi perdido na rede e resulta em uma retransmissão imediata.

Nesse caso, a retransmissão passa e é identificada pelo Wireshark como fora de ordem.

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

Se você não conseguir ver nenhum candidato óbvio, realize 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 MPLS VPN? IPsec VPN pela internet pública? Algo mais?

    

Answer 2

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

Após o estabelecimento da conexão, o desempenho lento do TCP nem sempre é devido a problemas de rede de trânsito; às vezes vem como resultado de limitações de CPU ou disco do servidor ... e ocasionalmente por causa de algum problema em um PC cliente. Eu tenho perseguido o meu rabo por semanas cavando as ervas daninhas de traços wireshark apenas para desistir e encontrar o problema de forma relativamente rápida com mtr , ou olhando para outras métricas do host, como CPU e E / S de disco.

Sua primeira tarefa é provar se isso é um problema de rede ou um problema no nível do host. Concentre-se em enviar tráfego real através de sua rede e prove se você está enfileirando / perdendo / reordenando ^{Nota 1} ; que sempre é o resultado final para um possível problema de rede como este .

Eu faria uma amostragem ping 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 mtr ou freeware do plotador de ping para isso. Se você está perdendo pacotes de forma consistente em algum salto e todos os saltos depois perderem muito ou mais , então você tem um potencial suspeito de rede. Lembre-se de que o limite de taxa de ICMP do dispositivo pode fazer com que alguns saltos apareçam que eles perdem pacotes ... é por isso que você deseja procurar uma tendência a partir desse salto e dos seguintes.

^{Nota 1} Se você estiver reordenando o tráfego, ele aparecerá rapidamente no informação especializada campo que a wireshark fornece

    

Answer 3

Ao ver muitos [segmento TCP de PDU remontada] sem ACKs - eu diria que esses ACKs provavelmente são mostrados como [TCP Dup ACK ...] para Comportamento de Confirmação Seletiva (também conhecido como SACK) .

Exemplo:

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

• server acked (0), então recebeu (2,4,3), depois (5), depois (6) e nunca obteve (1)

No cenário acima - o servidor pode legitimamente escolher ack (2-4) range first, then (2-5) range, então (2-6) range. Ao formar o pacote de pacotes "(A-B) ack", o servidor precisa especificar a parte com a última gravação (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 da parte anterior no cabeçalho TCP (Ack = 872619 no seu caso).

    

Answer 4

ACKs duplicados em combinação com desempenho de rede lento soam como um problema de congestionamento de rede para mim. Veja o volume e a taxa do tráfego de broadcast na rede. Certifique-se de analisar as transmissões da camada física e da camada de rede, bem como os multicasts.