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

Note : Je suppose que cette capture a été faite sur la machine cliente.

Un bref résumé sur le séquençage TCP : TCP délivre de manière fiable des flux d'octets entre deux applications. Dans ce cas, "fiable" signifie, entre autres, que TCP garantit de ne jamais livrer de données hors d'usage à une application qui écoute.

La livraison dans l'ordre et fiable est mise en œuvre par 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 du champ ACK est le prochain numéro de séquence que A s'attend à recevoir de B.

D'après ce qui précède, il semble qu'au moins un segment TCP envoyé par le serveur au client ait été perdu. Les trois ACKs dupliqués en séquence sont une tentative par le client de déclencher un 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 l'élément de données le plus récemment envoyé), il peut raisonnablement supposer que le segment immédiatement après le segment faisant l'objet d'un ACK a été perdu dans le réseau, ce qui entraîne une retransmission immédiate.

Dans ce cas, la retransmission passe, et est identifiée par Wireshark comme étant hors de l'ordre.

Comme mentionné par joeqwerty la perte de paquets est le plus souvent causée par la congestion. Elle peut aussi être le résultat d'erreurs CRC ou autres sur un lien, dues à une mauvaise carte d'interface, un câble lâche, etc. Je regarderais les statistiques de chaque lien le long du chemin pour voir si l'un d'entre eux est fortement utilisé et/ou connaît un grand nombre d'erreurs.

Si vous ne voyez aucun candidat évident, effectuez des captures de paquets simultanées en plusieurs points du trajet pour essayer d'isoler l'endroit où la perte se produit.

Quel type de connexion WAN est utilisé ici ? S'agit-il d'une ligne dédiée ? Une liaison VPN MPLS ? Un VPN IPsec sur l'Internet public ? Quelque chose d'autre ?

Pendant que vous cherchez à isoler l'origine du problème, considérez le dump de paquets comme l'un des symptômes... Par analogie, si quelqu'un entre dans le bureau du médecin avec des douleurs thoraciques, le médecin ne va pas passer trois heures à enquêter sur la nature de la douleur. Il y consacre environ deux minutes et sait ensuite que 95 % des causes sont soit des brûlures d'estomac, soit une angine... De la même manière, si vous voyez des ACKs en double, ne cherchez pas tout de suite les mauvaises herbes de la trace.

Après l'établissement de la connexion, la lenteur des performances TCP n'est pas toujours due à des problèmes de réseau de transit ; parfois, elle résulte de limitations du processeur ou du disque du serveur... et parfois d'un problème sur un PC client. Il m'est arrivé de passer des semaines à fouiller dans les traces de wireshark pour finalement abandonner et trouver le problème relativement rapidement avec mtr ou en examinant d'autres paramètres de l'hôte, tels que l'unité centrale et les entrées/sorties de disque.

Votre première tâche est de 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 d'un trafic réel à travers votre réseau et prouvez que vous mettez en file d'attente / perdez / réorganisez Note 1 il ; c'est toujours le point essentiel pour un problème de réseau potentiel comme celui-ci. .

Je ferais un ping pendant une période prolongée (typiquement une heure pour moi) entre le client et le serveur pendant que le problème de débit se produit ; vous pouvez utiliser la fonction mtr o traceur de ping freeware pour ça. Si vous perdez constamment des paquets à un certain saut, et que tous les houblons perdent ensuite autant ou plus alors vous avez un suspect potentiel dans le réseau. Gardez à l'esprit que la limitation du débit ICMP d'un périphérique peut donner l'impression que certains sauts perdent des paquets... c'est pourquoi vous devez rechercher une tendance à partir de ce saut et des suivants.

Note 1 Si vous réordonnez le trafic, cela apparaîtra assez rapidement dans la base de données de l'UE. infos pratiques champ que fournit wireshark

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

Exemple :

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

• le serveur a accédé à (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'acquitter d'abord la plage (2-4), puis la plage (2-5), puis la plage (2-6). En formant le paquet "(A-B) range ack" - le serveur doit spécifier la partie last-acked (0) dans l'en-tête TCP. Wireshark marque les range-acks (SACKs) en tant que [TCP Dup ACK ...] car tous ces range-acks ont la même valeur de la partie last-acked dans l'en-tête TCP (Ack=872619 dans votre cas).

La duplication des ACK combinée à la lenteur du réseau me semble être un problème de congestion du réseau. Examinez le volume et le taux du trafic de diffusion sur le réseau. Veillez à examiner les diffusions de la couche physique et de la couche réseau ainsi que les multidiffusions.