Un excès de "ACK en double TCP" et de "Retransmission rapide TCP" entraîne des problèmes sur le réseau. Qu'est-ce qui provoque cela?

Je réalise que cette réponse est simplifiée et pas aussi explicite que je le voudrais, donc si vous avez des questions sur une étape, n'hésitez pas à demander!

En descendant un peu après avoir ouvert ce fichier dans Wireshark, nous voyons quelques trames de différentes couleurs. Cela semble vraiment mauvais, n'est-ce pas? Eh bien, ce n'est pas si mal. Attendez, on va y arriver.

En vérifiant le paquet SYN (trame 37) nous voyons SACK et le scaling de la fenêtre dans les options TCP. Bien. Même chose dans le SYN/ACK (trame 38), SACK et le scaling de la fenêtre. Génial. Rien d'étrange concernant SACK.

Une estimation du RTT non chargé est le temps entre le paquet SYN et le premier ACK (trame 39). C'est d'environ 9,3 ms, ce qui correspond à vos résultats. Notez que le temps entre SYN/ACK et ACK (trames 38 et 39) est bien moins élevé que entre SYN et SYN/ACK (37 et 38). Cela signifie que ce fichier de capture est pris au niveau du récepteur, et pour comprendre pourquoi ce n'est pas idéal, nous devrons retourner à l'école.

Entre l'émetteur et le récepteur, il y a une partie du chemin du réseau qui est la plus petite, ce qui limite la bande passante. L'estimation du RTT que nous venons d'obtenir de l'handshake nous donne une idée de la longueur de ce chemin du réseau. Une mesure du nombre de paquets que nous pouvons placer dans ce tuyau est le Capacité du Tuyau ou le Produit Bande Passante-Délai - PC [bits] = R [bits/s] * RTT [s], où R est la bande passante la plus petite. La Capacité du Tuyau est alors une mesure du volume.

Imaginez un tuyau d'arrosage. Son volume est mesuré et défini par sa longueur et sa largeur de la même manière, n'est-ce pas? Pour en tirer le maximum d'eau, il faut qu'il soit complètement rempli d'eau, sinon il y aura des espaces d'air limitant le débit d'eau. Si nous réussissons à le remplir complètement, il pourrait déborder. Nous pouvons utiliser un seau pour éviter de mouiller le sol, et si le seau déborde, cela n'affecte pas le débit d'eau.

Il se trouve que c'est exactement la même chose dans le chemin du réseau. Nous devons remplir le tuyau... En d'autres termes, la Capacité du Tuyau est le nombre de bytes en vol (combien d'eau nous avons dans le tuyau + seau) entre l'émetteur et le récepteur qui utilise pleinement la bande passante la plus basse (ne crée pas d'espaces d'air). Donc si les bytes en vol > PC alors c'est bon!

En regardant la trace TCP Statistiques -> Graphique de Flux TCP -> Graphique de Séquence Temporelle (tcptrace) nous pouvons voir les bytes sur l'axe Y, et le temps sur l'axe X. La dérivée de cette courbe est des bytes/seconde, ou débit. Remarquez comment la ligne noire est plate, ce qui signifie que le débit est stable! Elle est interrompue par des lignes bleues quelques fois cependant (ce sont les plages SACK dans les ACKs dupliqués), mais comme on peut le voir, cela n'affecte pas le débit.

Voyez comment la ligne grise solide en bas à droite (zoom un peu, ce sont les ACKs) est très proche des segments TCP noirs? Le temps entre le segment TCP et l'ACK est le RTT, ici c'est presque 0! Cela signifie qu'il n'y a pas beaucoup de segments en vol passés ce point de capture. Cela signifie à son tour que nous ne pouvons pas l'utiliser pour estimer les bytes en vol, et c'est pourquoi une capture de paquet du côté émetteur est bien meilleure.

Les paquets sont naturellement perdus avant le point de capture. Chaque segment de données qui était en vol au moment de la perte déclenche un ACK dupliqué. Par conséquent, nous pouvons utiliser le nombre d'ACKs dupliqués pour estimer les bytes en vol au moment de la perte du paquet. Ici nous voyons environ 9, 16 et 23 segments. Chaque segment a 1448 bytes de données, donc cela nous donne un nombre de bytes en vol entre 13k et 33k. Le débit ici était d'environ 3 Mbit/s (du Graphique d'I/O) et avec le RTT que nous avons mesuré précédemment, nous obtenons une Capacité du Tuyau inférieure à 3e6 [bits/s] * 10e-3 [s] / 8 bytes = 3750 bytes, ou moins de 3 segments.

Parce que les bytes en vol au moment de ces pertes ne sont pas vraiment les mêmes (difficile à dire ici avec si peu d'échantillons) je ne peux pas vraiment dire si ce sont des pertes aléatoires (qui sont très mauvaises) ou des pertes qui se produisent car une file/seau déborde, mais elles se produisent lorsque les bytes en vol > PC donc le débit n'est pas affecté.

Votre réponse semble indiquer qu'elles étaient effectivement aléatoires, mais pas suffisamment pour entraîner un faible débit.

Je viens de publier ce que j'ai découvert. Le fournisseur de MetroEthernet est venu un samedi à notre siège social. Ils ont déconnecté le réseau là-bas, et avaient également quelqu'un dans une succursale à proximité. Ils ont connecté l'équipement de test réseau aux deux extrémités et ont rapidement pu déterminer qu'il y avait en fait un problème. Plusieurs heures plus tard, ils ont pu isoler le problème. C'était un problème avec les lignes de cuivre du bureau central des fournisseurs, vers notre siège social. Ils ont dit que les trames tombaient comme des mouches, ce qui causait les retransmissions. Ils ont résolu le problème avec le fil de cuivre à leur bureau central (ils ont dit qu'ils devaient démonter chaque fil, un par un. Ça me semble bizarre), mais après avoir fait cela à leur bureau central, le problème était résolu.

En regardant la capture que vous avez fournie (merci de l'avoir faite!) Je peux voir un schéma de retransmission assez classique au début. Vous pouvez le voir vers le paquet 50. Il manque un paquet entre 51 et 52. Voici ce qui se passe :

1. --> Paquet 50 Data
2. <-- Paquet 51 ACK paquet 50.
3. --> Paquet 52 Data
4. <-- Paquet 53 ACK paquet 50.
5. --> Paquet 54 Data
6. <-- Paquet 55 ACK paquet 50.

Un paquet de données a été perdu, et le récepteur l'indique en continuant d'ACK le paquet jusqu'à ce qu'il ait vu jusqu'à présent. Ce qui est intéressant ici, c'est que les deux côtés avaient Option permise de SACK TCP = True lorsque ils ont négocié la connexion, donc le paquet 55 devrait avoir une en-tête SACK, ce qui n'est pas le cas. Les acquittements sélectifs permettent à un récepteur d'indiquer "J'ai vu tout jusqu'à 51, mais aussi 53-55" ce qui réduit le nombre de retransmissions nécessaires pour retrouver pleinement la vitesse.

Ce qui se passe puisqu'il ne peut pas utiliser SACK, c'est qu'il revient à la méthode standard de retransmission TCP en répétant "j'ai vu jusqu'à 50" jusqu'à ce que l'autre côté comprenne et retransmette tout à partir de 50 et après.

Il y a une retransmission dans le paquet 66, qui est immédiatement suivie d'un ACK jusqu'au paquet 56. Après la deuxième retransmission (paquet 72) la connexion est de nouveau en ordre.

Tout d'abord, il semble probable que les en-têtes SACK soient supprimées par les pare-feu sonicwall, ce qui empêche les retransmissions de récupérer aussi rapidement qu'elles l'ont négocié. Personnellement, je suis d'avis que la suppression de SACK est inutile, mais d'autres peuvent être en désaccord.

D'après ce que je peux voir sur cette capture, vous rencontrez une perte occasionnelle de paquets, ce qui entraîne des protocoles normaux de retransmission TCP. Les pare-feu entravent la méthode de retransmission que les deux côtés ont négociée car elle n'est pas autorisée.