'TCP Dup ACK' et 'TCP Fast Retransmission' excessifs causant des problèmes sur le réseau. Qu'est-ce qui cause ça?
Je reçois un excès TCP Dup ACK et TCP Retransmission rapide sur notre réseau lorsque je transfère des fichiers via la liaison MetroEthernet. Les deux sites sont connectés par un mur sonicwall routeur, donc les sites sont à seulement un saut.
ici est une capture d'écran de Wireshark, et ici est la capture entière. Dans cette capture, le client est 192.168.2.153 et le serveur est 192.168.1.101 Voici un traceroute de mon système vers le serveur (les temps de ping sont généralement stables sous 10 ms):
user@pc567:~$ ifconfig eth0
eth0 Link encap:Ethernet HWaddr 00:e0:b8:c8:0c:7e
inet addr:192.168.2.153 Bcast:192.168.2.255 Mask:255.255.255.0
inet6 addr: fe80::2e0:b8ff:fec8:c7e/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:244994 errors:0 dropped:0 overruns:0 frame:0
TX packets:149148 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:319571991 (319.5 MB) TX bytes:12322180 (12.3 MB)
Interrupt:16
user@pc567:~$ traceroute -n 192.168.1.101
traceroute to 192.168.1.101 (192.168.1.101), 30 Hops max, 60 byte packets
1 192.168.2.254 0.747 ms 0.706 ms 0.806 ms
2 192.168.1.101 8.995 ms 9.217 ms 9.477 ms
user@pc567:~$
Toute aide sur la cause de cela serait utile! Je peux poster plus de détails nécessaires.
MISE À JOUR: Depuis que cela a commencé, j'ai remplacé le sonicwall par un routeur Cisco 1800. La capture de paquets avec elle installée a eu les mêmes résultats. Puisqu'il s'agit d'un circuit Ethernet métropolitain, aucun routeur n'est requis. J'ai donc également essayé de me connecter aux ordinateurs portables directement dans l'équipement des fournisseurs de services sur les deux sites et de les placer sur le même sous-réseau. La capture de paquets a la même apparence en procédant de cette façon. Cela m'amène à croire qu'il y a un problème avec le circuit Ethernet métropolitain, même s'ils continuent à dire que tout va bien et que tout fonctionne bien.
Je me rends compte que cette réponse est simplifiée et pas aussi explicite que je le souhaiterais, donc si vous avez des questions sur une étape, n'hésitez pas!
En faisant défiler un peu après l'ouverture de ce fichier dans Wireshark, nous voyons des cadres de couleurs différentes. Ça a l'air vraiment mauvais, non? Eh bien, ce n'est pas si mal. Attendez, nous y arriverons.
En vérifiant le paquet SYN (image 37), nous voyons SACK et la mise à l'échelle de la fenêtre dans les options TCP. Bien. Même chose dans les vues SYN/ACK (image 38), SACK et Windows. Génial. Je ne vois rien de bizarre concernant SACK.
Une estimation de la RTT déchargée est le temps entre le paquet SYN et le premier ACK (trame 39). C'est environ 9,3 ms, ce qui correspond à vos résultats. Notez que le temps entre SYN/ACK et ACK (images 38 et 39) est beaucoup plus court qu'entre SYN et SYN/ACK (37 et 38). Cela signifie que ce fichier de capture est pris au niveau du récepteur, et pour voir pourquoi ce n'est pas idéal, nous devrons retourner à l'école.
Entre l'expéditeur et le récepteur, une partie du chemin réseau est la plus petite, ce qui limite la bande passante. L'estimation RTT que nous venons d'obtenir de la prise de contact nous donne une estimation de la longueur de ce chemin de réseau. Une mesure du nombre de paquets que nous pouvons contenir dans ce canal est le Capacité du canal ou produit de délai de bande passante - PC [bits] = R [bits/s] * RTT [s], où R est le plus petite bande passante. La capacité du tuyau est alors une mesure de volume.
Imaginez un tuyau d'arrosage. Son volume mesuré est défini par sa longueur et sa largeur de la même manière non? Pour en tirer le maximum, il doit être complètement rempli d'eau, sinon il y aura des entrefers limitant le débit d'eau. Si nous parvenons à le remplir complètement, il pourrait déborder. Nous pouvons utiliser un seau pour ne pas mouiller le sol et si le seau déborde, cela n'affecte pas le débit d'eau.
Il s'avère 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 plus petit octet en vol (la quantité d'eau que nous avons dans le tuyau + le seau) entre l'expéditeur et le récepteur qui utilise pleinement la plus petite bande passante (ne provoque pas entrefers). Donc, si les octets en vol> PC, alors nous sommes bons!
En regardant la TCP Statistiques -> TCP StreamGraph -> Graphique de séquence temporelle ( tcptrace) nous pouvons voir les octets sur l'axe Y et le temps sur l'axe X. La dérivée de cette courbe est octets/seconde, ou débit. Notez comment la "ligne" noire est plat, ce qui signifie que le débit est stable! Il est interrompu par des lignes bleues plusieurs fois (ce sont les plages SACK dans les ACK en double), mais comme on peut le voir, cela n'affecte pas le débit.
Voyez comment la ligne continue grise en bas à droite (zoomer un peu, c'est les ACK) est vraiment proche des segments noirs TCP? Le temps entre les TCP segment 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é ce point de capture. Cela signifie à son tour que nous ne pouvons pas l'utiliser pour estimer les octets en vol, et c'est pourquoi une capture de paquets côté expéditeur est bien meilleure.
Les paquets ici 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 en double. Par conséquent, nous pouvons utiliser le nombre de ACK en double pour estimer les octets en vol au moment de la perte de paquet. Ici, nous voyons environ 9, 16 et 23 segments. Chaque segment a 1448 octets de données, ce qui nous donne un octet en vol entre 13k et 33k. Le débit ici était d'environ 3 Mbit/s (à partir de graphique IO ) et avec le RTT, nous avons mesuré avant d'obtenir une capacité de tuyau inférieure à 3e6 [bits/s] * 10e-3 [s]/8 octets = 3750 octets, ou moins de 3 segments.
Parce que les octets 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 mauvaises mauvaises mauvaises) ou des pertes survenues à cause d'une file d'attente/bucket déborde, mais ils se produisent lorsque les octets en vol> PC donc le débit n'est pas affecté.
Votre réponse semble indiquer qu'ils étaient en effet aléatoires, mais pas autant pour provoquer un faible débit.
Je viens de publier ce que j'ai découvert. Le fournisseur MetroEthernet est sorti un samedi à notre bureau principal. Ils y ont déconnecté le réseau et ont également eu quelqu'un dans une succursale à proximité. Ils ont connecté l'équipement de test du 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 à notre bureau principal. Ils ont dit que les cadres tombaient comme des fous, ce qui était à l'origine des retransmissions. Ils ont résolu le problème avec le fil de cuivre dans leur bureau central (ils ont dit qu'ils devaient séparer chaque fil, un à la fois. Cela ressemble à BS pour moi), mais après avoir fait cela dans leur bureau central, le problème a été résolu.
En regardant la capture que vous avez fournie (merci de le faire!) Je peux voir un modèle de retransmission assez classique vers le début. Vous pouvez le voir autour du paquet 50. Il y a un paquet manquant entre 51 et 52. Ce qui se passe est le suivant:
- -> Packet 50 Data
- <- Paquet 51 Paquet ACK 50.
- -> Packet 52 Data
- <- Paquet 53 Paquet ACK 50.
- -> Packet 54 Data
- <- Paquet 55 Paquet ACK 50.
Un paquet de données a été abandonné, et le récepteur l'indique en continuant à ACK le paquet jusqu'à ce qu'il a vu jusqu'à présent. Ce qui est intéressant ici, c'est que les deux parties avaient TCP SACK Permitted Option = True défini quand ils ont négocié la connexion, donc le paquet 55 devrait avoir un en-tête SACK et ce n'est pas le cas. Les remerciements sélectifs permettent à un récepteur d'indiquer "J'ai tout vu jusqu'à 51, mais aussi 53-55", ce qui réduit le nombre de retransmissions nécessaires pour remettre les choses à pleine vitesse.
Ce qui se passe car il ne peut pas utiliser SACK, c'est qu'il revient à la méthode standard TCP retransmettre de répéter "j'ai vu jusqu'à 50" jusqu'à ce que l'autre côté le comprenne et retransmet tout 50 et plus tard.
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 sur la bonne voie.
Tout d'abord, il semble probable que les en-têtes SACK soient supprimés par les murs soniques, ce qui empêche les retransmissions de récupérer aussi vite qu'elles ont négocié. Personnellement, je suis d'avis que le décapage SACK est inutile, mais d'autres peuvent être en désaccord.
D'après ce que je peux dire sur cette capture, vous voyez une perte de paquets occasionnelle, ce qui fait que les connexions TCP passent par les protocoles de retransmission normaux. Les pare-feu se mettent en travers en tant que méthode de retransmission les deux parties négociées ne sont pas autorisées.