O que causa registros ACK duplicados?

19

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.

insira a descrição da imagem aqui

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

Sam
fonte
Que tipo de hardware de comutação de roteamento é entre os dois pontos de extremidade?
SpacemanSpiff
@ SpacemanSpiff, há um roteador Cisco ASR 1006.
Sam
A equipe de TI e os clientes estão no mesmo equipamento de comutação? Você pode levar uma de suas máquinas para a área de TI e ver o problema desaparecer?
SpacemanSpiff

Respostas:

25

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?

Murali Suriar
fonte
Obrigado por seus comentários. Você está certo, a captura de pacotes é do cliente. Se eu entendo o que você está dizendo, as ACKs duplicadas não são o cliente que está fazendo algo errado, mas na verdade são um gatilho do cliente que não recebeu um registro diferente (aquele após as ACKs). Isso está correto? Quais são as coisas que posso analisar no PC cliente que causariam isso? Se não é um problema no PC do cliente, por que ele aparece consistentemente em alguns clientes e não em outros?
Sam
A WAN é "dois circuitos ponto a ponto" entre três locais na costa leste e no meio oeste dos Estados Unidos.
Sam
Está correto; os DUPACKs são um sintoma de perda de pacotes. Quanto ao motivo pelo qual o problema ocorreria em alguns clientes e não em outros, você precisa descobrir o que é comum aos clientes afetados. Eles estão todos no mesmo escritório? Passando por uma infraestrutura de rede comum? (Um switch ou um link?). Uma coisa que vale a pena fazer é usar mtr(ou pathpingno Windows) em cada uma das máquinas afetadas e verificar se existem saltos comuns no caminho para o servidor que parecem estar com perda de pacotes. Você tem um sistema de monitoramento de rede que pode usar para examinar os dados da porta do switch?
Murali Suriar #
4

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

Mike Pennington
fonte
Concordo que culpar a rede por padrão não é uma boa abordagem. Instrumentar toda a pilha é sempre uma boa prática. No entanto, neste caso, os DUPACKs, segmentos fora de ordem e retransmitidos parecem ser indicativos de algum tipo de perda de rede entre os dois pontos de extremidade.
Murali Suriar
@Murali Suriar, vamos com sua afirmação (que tem uma chance decente de estar certa) ... então o que vem depois? Você precisa isolar o motivo da perda de pacotes. Nós, pessoas de TI, nos apaixonamos misteriosamente wiresharka tal ponto que gostamos de olhar o microscópio por muito tempo. O que estou pcapdizendo é dar uma rápida olhada no : depois disso, é melhor você gastar ciclos instrumentando perda de pacotes, ciclos de CPU e E / S de disco do que se aprofundar nos anais do TCP. Há um tempo para fazer isso, mas normalmente não está nesse estágio de análise.
Mike Pennington
@ Mike concordou, e foi por isso que sugeri procurar informações sobre erros / utilização de dispositivos ao longo do caminho como um primeiro passo. Eu não sou um grande fã de diagnósticos baseados em ICMP além da acessibilidade. Como você diz, ACLs / firewalls limitadores de taxa e configurados incorretamente podem torná-lo não confiável; embora em uma rede corporativa (com o que isso pareça), a MTR geralmente pode apontar na direção certa. O outro problema com a MTR é que geralmente apenas aponta para um problema; é perfeitamente possível que haja várias falhas ao longo do caminho, que você não conseguirá encontrar até corrigir o primeiro.
Murali Suriar
Não estamos discordando, o ICMP com pisar em TTL não é uma panacéia e pode haver várias falhas. No entanto, apesar de todas as suas falhas em lidar com firewalls e balanceadores de carga, o ICMP é o melhor diagnóstico remoto que temos, a menos que você possa executar sessões TCP / UDP instrumentadas em nível de host nas portas de aplicativos específicas em questão ... mesmo assim, você só pode dizer , esse soquete está retransmitindo muito ... mas por quê? Em 70% das vezes, estou desistindo mtrou está mal e resolvi problemas da mesma maneira nos últimos 15 anos. Uma vez que eu me concentrei em um dispositivo específico, então podemos olhar para os contadores de gota
Mike Pennington
1
@ Sam: Apenas um ponto em relação à solução de problemas de rede: toda rede tem "problemas". A chave é determinar se esses problemas estão causando problemas de desempenho e / ou conectividade. Você encontrará ACKs duplicados, retransmissões TCP, transmissões, protocolos errantes etc. em todas as redes. Você deve se concentrar no volume de ACKs duplicados e nos hosts mais envolvidos no envio de ACKs duplicados para determinar se esse é realmente um sintoma de um problema maior ou apenas da operação natural da rede. Se eu vir 5 ACKs duplicados em 1.000 pacotes, não vou pensar duas vezes.
Joeqwerty
3

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).

dubrov
fonte
1

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.

joeqwerty
fonte