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

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

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?

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.

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

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.