Quelles sont les causes des enregistrements ACK en double?


19

Nous examinons les captures Wireshark de quelques machines clientes qui affichent plusieurs enregistrements ACK en double qui déclenchent ensuite des retransmissions et des paquets hors séquence.

Celles-ci sont illustrées dans la capture d'écran suivante. .26 est client et .252 est serveur.

entrez la description de l'image ici

Qu'est-ce qui cause les enregistrements ACK en double?

Plus d'informations si cela aide:

Nous étudions les problèmes de débit réseau sur un site client particulier. Le problème perçu du point de vue de l'interface utilisateur est que les données sont transmises lentement malgré une connexion WAN 1 Gbit / s sous-utilisée.

Presque toutes les machines clientes ont le même problème, testées sur plus de 20 machines. Nous avons trouvé deux machines qui n'ont pas le problème. Nous sommes en train d'identifier ce qui est différent dans leur configuration. Nous avons remarqué que sur les deux machines qui ne rencontrent pas de problème, nous n'avons vu au maximum qu'un enregistrement ACK en double. Les machines qui ont le problème ont généralement trois enregistrements ACK en double. Une différence notable est que les machines qui fonctionnent bien appartiennent toutes aux membres de l'équipe d'exploitation du réseau et toutes les autres machines sont destinées aux employés "réguliers". Les machines sont censées être standard, mais les administrateurs réseau auraient pu apporter des modifications à leurs systèmes locaux, ce qui est un autre aspect que nous recherchons.

Nous avons essayé de modifier le paramètre TcpMaxDupAcks sur le serveur, mais la valeur dont nous avons vraiment besoin est 5 et la plage valide n'est que de 1 à 3.

Le serveur est Windows Server 2003. Les clients sont tous gérés par Windows XP. Tous les clients, y compris les deux qui fonctionnent, ont installé l'antivirus Symantec.

Il s'agit du seul site client sur des centaines à avoir présenté ce problème.

pathping affiche 56 ms RTT et une perte de paquets cohérente de 0/100 même à partir des machines à problème.

Merci,

Sam


Quel type de matériel de commutation de routage se trouve entre les deux points de terminaison?
SpacemanSpiff

@SpacemanSpiff, il y a un routeur Cisco ASR 1006.
Sam

Le personnel informatique et les clients sont-ils sur le même équipement de commutation? Pouvez-vous emmener une de leurs machines dans la zone informatique et voir le problème disparaître?
SpacemanSpiff

Réponses:


25

Remarque: je suppose que cette capture a été effectuée sur la machine cliente.

Un bref résumé sur le séquençage TCP: TCP fournit de manière fiable des flux d'octets entre deux applications. «Fiable» dans ce cas signifie que, entre autres, TCP garantit de ne jamais fournir de données hors service à une application en écoute.

Dans l'ordre, une livraison fiable est mise en œuvre grâce à l'utilisation de numéros de séquence. Chaque paquet de chaque flux se voit attribuer un numéro de séquence de 32 bits (rappelez-vous que TCP est en fait deux flux de données indépendants, A-> B et B-> A). Si A envoie un ACK à B, la valeur dans le champ ACK est le prochain numéro de séquence que A attend de B.

D'après ce qui précède, il semble qu'au moins un segment TCP envoyé du serveur au client a été perdu. Les trois ACK en double en séquence sont une tentative du client de déclencher une retransmission rapide . Lorsqu'un expéditeur TCP reçoit 3 accusés de réception en double pour le même élément de données (c'est-à-dire 4 ACK pour le même segment, qui n'est pas le dernier élément de données envoyé), il peut raisonnablement supposer que le segment immédiatement après le segment ACKé a été perdu dans le réseau, et entraîne une retransmission immédiate.

Dans ce cas, la retransmission passe et est identifiée par Wireshark comme étant hors service.

Comme mentionné par joeqwerty , la perte de paquets est le plus souvent causée par la congestion. Cela peut également être le résultat d'un CRC ou d'autres erreurs sur un lien, en raison d'une mauvaise carte d'interface, d'un câble lâche, etc. Je regarderais les statistiques de chaque lien le long du chemin pour voir si certains sont très utilisés et / ou rencontrent un grand nombre d'erreurs.

Si vous ne voyez aucun candidat évident, effectuez des captures de paquets simultanées à plusieurs points le long du chemin pour essayer d'isoler où la perte se produit.

Quel type de connexion WAN est utilisé ici? Est-ce une ligne dédiée? Lien VPN MPLS? VPN IPsec sur Internet public? Autre chose?


Merci pour vos commentaires. Vous avez raison, la capture de paquets vient du client. Si je comprends ce que vous dites, les ACK en double ne sont pas le client qui fait quelque chose de mal, mais sont en fait un déclencheur du client qu'il n'a pas reçu un enregistrement différent (celui après les ACK). Est-ce exact? Quelles sont les choses que je peux examiner sur le PC client qui pourraient provoquer cela? Si ce n'est pas un problème de PC client, pourquoi apparaîtra-t-il systématiquement sur certains clients et pas sur d'autres?
Sam

Le WAN est "deux circuits point à point" entre trois sites sur la côte est et le centre-ouest des États-Unis.
Sam

C'est correct; les DUPACK sont un symptôme de perte de paquets. Quant à savoir pourquoi le problème se produirait sur certains clients et pas sur d'autres, vous devez déterminer ce qui est commun aux clients concernés. Sont-ils tous dans le même bureau? Vous passez par une infrastructure réseau commune? (Un interrupteur ou un lien?). Une chose qui vaut la peine est d'utiliser mtr(ou pathpingsur Windows) sur chacune des machines concernées et de voir s'il y a des sauts communs le long du chemin vers le serveur qui semblent subir une perte de paquets. Avez-vous un système de surveillance réseau que vous pouvez utiliser pour consulter les données de port de commutateur?
Murali Suriar

4

Pendant que vous isolez le problème, pensez à un vidage de paquets comme l'un des symptômes ... Par analogie, si quelqu'un entre dans le cabinet du médecin avec des douleurs thoraciques, le doc ne passera pas trois heures à enquêter sur la nature de la douleur. Il y passe environ deux minutes et sait alors que 95% des causes sont soit des brûlures d'estomac ou de l'angine de poitrine ... De la même manière, si vous voyez des ACK en double, ne trouez pas tout de suite les mauvaises herbes de la trace .

Une fois la connexion établie, les performances TCP lentes ne sont pas toujours dues à des problèmes de réseau de transit; Parfois, cela résulte de limitations du processeur ou du disque du serveur ... et parfois à cause d'un problème sur un PC client. J'ai chassé ma queue pendant des semaines à creuser dans les mauvaises herbes des traces de wirehark uniquement pour abandonner et trouver le problème relativement rapidement avec mtr , ou en regardant d'autres mesures de l'hôte telles que le processeur et les E / S de disque.

Votre première tâche consiste à prouver s'il s'agit d'un problème de réseau ou d'un problème au niveau de l'hôte. Concentrez-vous sur l'envoi de trafic réel via votre réseau et prouvez si vous faites la queue / perdez / réorganisez Note 1 ; c'est toujours le résultat d'un problème de réseau potentiel comme celui-ci .

Je ferais un pingéchantillonnage pendant une longue période (généralement une heure pour moi) entre le client et le serveur pendant que le problème de débit se produit; vous pouvez utiliser le freeware mtr ou ping plotter pour cela. Si vous perdez constamment des paquets à un saut, et que tous les sauts en perdent ensuite autant ou plus , alors vous avez un suspect potentiel de réseau. Gardez à l'esprit que la limitation de débit ICMP du périphérique peut faire apparaître des sauts qui perdent des paquets ... c'est pourquoi vous souhaitez rechercher une tendance à partir de ce saut et des suivantes.


Remarque 1 Si vous réorganisez le trafic, cela s'affichera assez rapidement dans le champ d' informations expert fourni par wirehark.


Convenez que blâmer le réseau par défaut n'est pas une bonne approche. L'instrumentation tout au long de la pile est toujours une bonne pratique. Cependant, dans ce cas, les segments DUPACK, les segments hors service et retransmis semblent indiquer une sorte de perte de réseau entre les deux points d'extrémité.
Murali Suriar

@Murali Suriar, allons-y avec votre affirmation (qui a de bonnes chances d'avoir raison) ... et ensuite? Vous devez isoler la raison de la perte de paquets. Nous, les informaticiens, sommes mystérieusement tombés amoureux wiresharkau point que nous aimons regarder le microscope beaucoup trop longtemps. Le point que je veux faire est de jeter un coup d'œil rapide sur le pcap, après quoi vous feriez mieux de dépenser des cycles pour instrumenter la perte de paquets, les cycles CPU et les E / S de disque que de plonger profondément dans les annales de TCP. Il y a un temps pour le faire, mais ce n'est normalement pas à ce stade de l'analyse.
Mike Pennington

@Mike a accepté, c'est pourquoi j'ai suggéré de rechercher des erreurs / informations d'utilisation pour les appareils le long du chemin dans un premier temps. Je ne suis pas un grand fan des diagnostics basés sur ICMP autres que pour l'accessibilité. Comme vous le dites, la limitation du débit et les listes de contrôle d'accès / pare-feu incorrectement configurées peuvent le rendre peu fiable; bien que dans un réseau d'entreprise (à quoi cela ressemble), MTR peut souvent vous orienter dans la bonne direction. L'autre problème avec MTR est qu'il pointe souvent vers un seul problème; il est tout à fait possible qu'il y ait plusieurs défauts le long du chemin, que vous ne pourrez pas trouver avant d'avoir corrigé le premier.
Murali Suriar

Nous ne sommes pas en désaccord, ICMP avec le pas TTL n'est pas une panacée et il peut y avoir plusieurs défauts. Cependant, pour tous ses défauts concernant les pare-feu et les équilibreurs de charge, ICMP est le meilleur diagnostic à distance que nous ayons, sauf si vous pouvez exécuter des sessions TCP / UDP instrumentées au niveau de l'hôte sur les ports d'application spécifiques en question ... même alors, vous ne pouvez que dire , cette prise retransmet beaucoup ... mais pourquoi? 70% du temps, je me retire mtrou c'est faux, et je résous les problèmes de la même manière depuis 15 ans. Une fois que je me suis concentré sur un appareil spécifique, nous pouvons regarder les compteurs de gouttes
Mike Pennington

1
@Sam: Juste un point concernant le dépannage des problèmes de réseau: chaque réseau a des "problèmes". La clé consiste à déterminer si ces problèmes provoquent des problèmes de performances et / ou de connectivité. Vous trouverez des ACK en double, des retransmissions TCP, des diffusions, des protocoles errants, etc. sur chaque réseau. Vous devez vous concentrer sur le volume des ACK en double et les hôtes les plus impliqués dans l'envoi des ACK en double pour déterminer si c'est vraiment un symptôme d'un problème plus important ou simplement le fonctionnement naturel du réseau. Si je vois 5 ACK en double sur 1 000 paquets, je ne vais pas y réfléchir.
joeqwerty

3

En voyant beaucoup de [segment TCP de PDU réassemblé] sans ACK - je dirais que ces ACK sont probablement affichés comme [TCP Dup ACK ...] en raison du comportement de l'accusé de réception sélectif (aka SACK) .

Exemple:

  • le client envoie des parties de données (..., 0,1,2,3,4,5,6, ...)

  • serveur acquitté (0), puis reçu (2,4,3), puis (5), puis (6) et jamais obtenu (1)

Dans le scénario ci-dessus - le serveur peut légitimement choisir d'ack (2-4) la plage d'abord, puis la plage (2-5), puis la plage (2-6). Lors de la formation du paquet "(AB) range ack" - le serveur doit spécifier la dernière partie acquittée (0) dans l'en-tête TCP. Wireshark marque la gamme-acks (SACKs) comme [TCP Dup ACK ...] car tous ces range-acks ont la même valeur de pièce en dernier-accusé dans l'en-tête TCP (Ack = 872619 dans votre cas).


1

Duplication des ACK en combinaison avec des performances réseau lentes me semble un problème de congestion du réseau. Regardez le volume et le taux de trafic diffusé sur le réseau. Assurez-vous de regarder les diffusions de la couche physique et de la couche réseau ainsi que les multidiffusions.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.