Quelles sont les causes des enregistrements ACK en double?
Nous examinons les captures Wireshark de quelques machines clientes qui affichent plusieurs enregistrements ACK en double, ce qui déclenche ensuite des paquets de retransmission et hors séquence.
Celles-ci sont illustrées dans la capture d'écran suivante. .26 est client et .252 est serveur.
Quelles sont les causes des 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 sous-utilisée de 1 Gbit/s WAN).
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 changer 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 un RTT de 56 ms et une perte de paquets cohérente de 0/100 même à partir des machines à problème.
Merci,
Sam
Remarque: je suppose que cette capture a été effectuée sur la machine cliente.
Un bref résumé sur TCP la séquence: 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 un retransmission rapide . Lorsqu'un expéditeur TCP reçoit 3 accusés de réception en double pour la même donnée (c'est-à-dire 4 ACK pour le même segment, qui n'est pas la dernière donnée envoyée), il peut raisonnablement supposer que le segment immédiatement après le segment ACKed 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. 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ù se produit la perte.
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?
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 lentes TCP ne sont pas toujours dues à des problèmes de réseau de transit; parfois elles résultent de limitations du processeur ou du disque du serveur ... et parfois à cause d'un problème sur un client PC. 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 le disque I/O.
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 il; qui est toujours la ligne de fond pour un problème de réseau potentiel comme celui-ci .
Je ferais un échantillonnage ping 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 mtr ou ping traceur gratuit pour cela. Si vous perdez régulièrement des paquets à un saut et tous les sauts 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 certains sauts comme des paquets perdus ... c'est pourquoi vous souhaitez rechercher une tendance à partir de ce saut et des suivants.
Note 1 Si vous réorganisez le trafic, cela apparaîtra assez rapidement dans le champ info expert fourni par wirehark
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 de comportement d'accusé de réception sélectif (aka SACK) .
Exemple:
le client envoie des parties de données (..., 0,1,2,3,4,5,6, ...)
le serveur a acquitté (0), puis a reçu (2,4,3), puis (5), puis (6) et n'a 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 TCP en-tête. Wireshark marque les range-acks (SACKs) comme [TCP Dup ACK ...] parce que tous ces accusés de réception de plage ont la même dernière valeur de pièce acquittée dans TCP en-tête (Ack = 872619 dans votre cas).
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.