Comment déboguer pourquoi WAN TCP / IP throughput est inférieur à ce qui était attendu?

J'essaie de comprendre pourquoi le débit tcp / ip entre deux hôtes que je contrôle est beaucoup plus bas que prévu.

L'hôte A: la connectivité Internet fournie par Comcast (Résidentiel) dans Boston Metro – peut constamment get un téléchargement de 100Mbps à partir de différents sites bien connus (par exemple, download Google Chrome)

Hôte B: connectivité Internet fournie par Cogent; peut toujours atteindre près de 100 Mbps à destination et en provenance de différents sites.

login de test: l'hôte A télécharge un grand file de B, via rsync / ssh sur un port non standard (22442) (c.-à-d. rsync --progress -e 'ssh -p 22442' ... – le débit est seulement d'environ 2.5 Mbps (292564 Bps)

D'autres clients (p. Ex. Une instance EC2 à gratter) peuvent atteindre près de 30 fois le débit lors de la tentative du même téléchargement de B

J'ai réussi à capturer des statistics de la connection entre A et B avec tcptrace (ci-joint ci-dessous) mais je ne suis pas sûr si quelque chose semble faux.

J'imagine qu'il y a quelque chose à ma fin qui a besoin de peaufiner, mais j'ai également un léger soupçon à propos de la diffusion du trafic Comcast – alors avant de commencer à me déplacer, je pensais que je chercherais des conseils. Quelles sont les bonnes étapes à suivre pour essayer? Merci d'avance.

 tcptrace -r -l -o1 dump.out 1 arg remaining, starting with 'dump.out' Ostermann's tcptrace -- version 6.6.7 -- Thu Nov 4, 2004 5763 packets seen, 5763 TCP packets traced elapsed wallclock time: 0:00:00.019828, 290649 pkts/sec analyzed trace file elapsed time: 0:00:18.655110 TCP connection info: 1 TCP connection traced: TCP connection 1: host a: XXX.XXXX.XXX:41608 host b: XXX.XXXX.XXX:22442 complete conn: RESET (SYNs: 2) (FINs: 1) first packet: Sun May 26 14:48:52.923281 2013 last packet: Sun May 26 14:49:11.578391 2013 elapsed time: 0:00:18.655110 total packets: 5763 filename: dump.out a->b: b->a: total packets: 1946 total packets: 3817 resets sent: 15 resets sent: 0 ack pkts sent: 1930 ack pkts sent: 3817 pure acks sent: 1874 pure acks sent: 35 sack pkts sent: 228 sack pkts sent: 0 dsack pkts sent: 0 dsack pkts sent: 0 max sack blks/ack: 3 max sack blks/ack: 0 unique bytes sent: 4100 unique bytes sent: 5457821 actual data pkts: 55 actual data pkts: 3781 actual data bytes: 4100 actual data bytes: 5457821 rexmt data pkts: 0 rexmt data pkts: 0 rexmt data bytes: 0 rexmt data bytes: 0 zwnd probe pkts: 0 zwnd probe pkts: 0 zwnd probe bytes: 0 zwnd probe bytes: 0 outoforder pkts: 0 outoforder pkts: 23 pushed data pkts: 55 pushed data pkts: 41 SYN/FIN pkts sent: 1/1 SYN/FIN pkts sent: 1/0 req 1323 ws/ts: Y/Y req 1323 ws/ts: Y/Y adv wind scale: 7 adv wind scale: 7 req sack: Y req sack: Y sacks sent: 228 sacks sent: 0 urgent data pkts: 0 pkts urgent data pkts: 0 pkts urgent data bytes: 0 bytes urgent data bytes: 0 bytes mss requested: 1460 bytes mss requested: 1460 bytes max segm size: 712 bytes max segm size: 1448 bytes min segm size: 16 bytes min segm size: 21 bytes avg segm size: 74 bytes avg segm size: 1443 bytes max win adv: 301184 bytes max win adv: 21632 bytes min win adv: 5888 bytes min win adv: 14592 bytes zero win adv: 0 times zero win adv: 0 times avg win adv: 269168 bytes avg win adv: 21615 bytes initial window: 20 bytes initial window: 21 bytes initial window: 1 pkts initial window: 1 pkts ttl stream length: 4101 bytes ttl stream length: NA missed data: 1 bytes missed data: NA truncated data: 0 bytes truncated data: 0 bytes truncated packets: 0 pkts truncated packets: 0 pkts data xmit time: 18.128 secs data xmit time: 18.527 secs idletime max: 5206.5 ms idletime max: 5285.9 ms throughput: 220 Bps throughput: 292564 Bps RTT samples: 57 RTT samples: 1661 RTT min: 59.0 ms RTT min: 0.0 ms RTT max: 106.1 ms RTT max: 40.1 ms RTT avg: 77.2 ms RTT avg: 1.4 ms RTT stdev: 17.2 ms RTT stdev: 7.1 ms RTT from 3WHS: 60.0 ms RTT from 3WHS: 0.0 ms RTT full_sz smpls: 2 RTT full_sz smpls: 1 RTT full_sz min: 60.0 ms RTT full_sz min: 0.0 ms RTT full_sz max: 70.1 ms RTT full_sz max: 0.0 ms RTT full_sz avg: 65.1 ms RTT full_sz avg: 0.0 ms RTT full_sz stdev: 0.0 ms RTT full_sz stdev: 0.0 ms post-loss acks: 0 post-loss acks: 16 segs cum acked: 0 segs cum acked: 2090 duplicate acks: 0 duplicate acks: 201 sortingple dupacks: 0 sortingple dupacks: 8 max # retrans: 0 max # retrans: 0 min retr time: 0.0 ms min retr time: 0.0 ms max retr time: 0.0 ms max retr time: 0.0 ms avg retr time: 0.0 ms avg retr time: 0.0 ms sdv retr time: 0.0 ms sdv retr time: 0.0 ms 

Quelques mises à jour, j'ai essayé quelques autres choses.

  • Tout d'abord, j'ai essayé de "redirect" le stream en tunnelant le transfert à travers un troisième hôte – j'ai atteint un débit très respectable pendant environ 30 minutes, puis le débit a diminué d'un facteur de 20-ish pour correspondre plus ou less au stream d'origine.

  • Deuxièmement, j'ai couru mtr de B-> A avec des packages de taille 1400b et j'ai vu ce qui suit:


     XXX (0.0.0.0) lun. 27 mai 19:20:37 2013
     Touches: mode d'affichage d'aide Redémarrez les statistics Ordre des champs quit
                                                                                  Packs Pings
      Perte d'accueil% Snt Dernière Moy Best Wrst StDev
      1. XXX.XX 0,0% 173 0,1 0,1 0,1 0,2 0,0
      2. XX.XX-XXatlas.cogentco.com 0,0% 173 0,9 0,9 0,8 4,2 0,3
      3. XX.XX-XXatlas.cogentco.com 0,0% 173 0,7 12,7 0,7 211,8 38,3
      4. te7-3.ccr01.ord07.atlas.cogentco.com 0.0% 173 1.1 12.8 0.7 196.8 39.9
      5. te0-4-0-7.mpd21.ord01.atlas.cogentco.com 0.0% 173 1.0 1.0 0.9 1.5 0.1
      6. be2006.ccr21.ord03.atlas.cogentco.com 0.0% 173 1.3 1.3 1.2 1.9 0.1
      7. be-202-pe04.350ecermak.il.ibone.comcast.net 0.0% 172 39.7 41.6 36.3 156.7 15.4
      8. he-3-2-0-0-cr01.350ecermak.il.ibone.comcast.net 2.3% 172 46.9 45.0 36.8 51.4 3.6
         he-3-1-0-0-cr01.350ecermak.il.ibone.comcast.net
         he-3-0-0-0-cr01.350ecermak.il.ibone.comcast.net
         he-3-12-0-0-cr01.350ecermak.il.ibone.comcast.net
      9. he-3-6-0-0-ar01.woburn.ma.boston.comcast.net 1.2% 172 68.7 67.9 64.8 72.4 1.6
     10. XXXXboston.comcast.net 1,7% 172 67,6 66,8 64,2 70,4 1,0
     11. XXXXboston.comcast.net 1.2% 172 67.5 66.4 64.0 69.2 1.0
     12. XXXXcomcast.net 1,2% 172 75,7 75,2 72,0 85,8 1,9


Étant donné les résultats de ma première expérience et le fait que tant de pertes de packages se produisent entre deux routeurs contrôlés par Comcast dans une installation Tier III (350 Cermak) – je commence à me pencher davantage vers l'explication "Comcast Boogeyman".

One Solution collect form web for “Comment déboguer pourquoi WAN TCP / IP throughput est inférieur à ce qui était attendu?”

Je suggérerais quelques points:

  • Vérifiez la perte de packages avec ping. Essayez au less 100 pings avec différentes tailles de packages, y compris un package plus grand d'environ 1400 octets.

  • Le time de trajet (RTT) de ~ 70 ms pourrait être assez élevé en fonction de la distance. Peut-être certainement regarder une traceroute allant dans chaque sens. Dans la sortie que vous avez collé, il semble que votre trafic depuis a -> b souffre de latence mais pas l'inverse, ce qui pourrait suggérer qu'il y a un problème avec le path d'un -> b, mais que le path de return de b -> a est bien.

  • Regardez les techniques dans cet ancien document pour parsingr le débit TCP.

Le document est un peu dépassé (Ethereal est maintenant Wireshark), mais les techniques sont encore solides.

5 secondes de time d'inactivité par rapport à 18 secondes d'horloge murale pourrait suggérer que la connection soit inactif lorsqu'un tampon de window TCP (soit envoyer ou recevoir) est complet, ce qui consortingbuerait à un faible débit. Cependant, la latence très asymésortingque est la première chose qui se distingue, alors je me concentrerai sur cette première. Bonne chance et merci de m'avoir présenté à tcptrace; Je n'avais pas vu ça auparavant.

  • Paramétrage de la stack client / server NFS
  • Qu'est ce qui pourrait arrêter DHCP d'un ordinateur connecté à un commutateur spécifique?
  • Quand utiliser des adresses IP routables vs non routables
  • Comment puis-je alterner entre plusieurs configurations TCPIP pour ma carte réseau? PowerShell?
  • Pourquoi la désactivation du service TCP / IP NetBIOS Helper me verrouille-t-elle hors de GPO?
  • est-il possible d'utiliser l'adaptateur de boucle en boucle ms pour configurer local vlan
  • Comment rendre le port ssh standard un port furtif?
  • Y a-t-il une différence entre prisoner.iana.org, blackhole-1.iana.org et blackhole-2.iana.org?
  • Qu'est-ce que je suis mal compris sur le calcul de MTU?
  • Accepter une connection sur un socket sur Windows 7 prend plus d'une seconde
  • L'exécution de lsof -i montre beaucoup de connections dans CLOSE_WAIT? Dois-je m'inquiéter
  • Les astuces du serveur de linux et windows, tels que ubuntu, centos, apache, nginx, debian et des sujets de rĂ©seau.