Plusieurs des réponses ici utilisent ping et traceroute pour leurs explications. Ces outils ont leur place, mais ils ne sont pas fiables pour mesurer les performances du réseau.
En particulier, certains routeurs Juniper (au moins certains) envoient le traitement des événements ICMP au plan de commande du routeur. C’est BEAUCOUP plus lent que le plan de transfert, en particulier dans un routeur de réseau fédérateur.
Dans d'autres circonstances, la réponse ICMP peut être beaucoup plus lente que les performances de transfert réelles d'un routeur. Par exemple, imaginons un routeur entièrement logiciel (sans matériel de transfert spécialisé) représentant 99% de la capacité de la CPU, mais le trafic est néanmoins maintenu dans de bonnes conditions. Voulez-vous qu'il passe de nombreux cycles à traiter les réponses de traceroute ou à transférer le trafic? Le traitement de la réponse est donc une priorité super faible.
En conséquence, les commandes ping / traceroute vous donnent une limite supérieure raisonnable - les choses vont au moins aussi vite - mais elles ne vous disent pas vraiment à quelle vitesse le trafic réel va.
En tout cas -
Voici un exemple de traceroute de l’Université du Michigan (centre des États-Unis) à Stanford (côte ouest des États-Unis). (Il se trouve que vous passez par Washington, DC (côte est des États-Unis), qui se trouve à 500 milles dans la "mauvaise" direction.)
% traceroute -w 2 www.stanford.edu
traceroute to www-v6.stanford.edu (171.67.215.200), 64 hops max, 52 byte packets
1 * * *
2 * * *
3 v-vfw-cc-clusta-l3-outside.r-seb.umnet.umich.edu (141.211.81.130) 3.808 ms 4.225 ms 2.223 ms
4 l3-bseb-rseb.r-bin-seb.umnet.umich.edu (192.12.80.131) 1.372 ms 1.281 ms 1.485 ms
5 l3-barb-bseb-1.r-bin-arbl.umnet.umich.edu (192.12.80.8) 1.784 ms 0.874 ms 0.900 ms
6 v-bin-arbl-i2-wsu5.wsu5.mich.net (192.12.80.69) 2.443 ms 2.412 ms 2.957 ms
7 v0x1004.rtr.wash.net.internet2.edu (192.122.183.10) 107.269 ms 61.849 ms 47.859 ms
8 ae-8.10.rtr.atla.net.internet2.edu (64.57.28.6) 28.267 ms 28.756 ms 28.938 ms
9 xe-1-0-0.0.rtr.hous.net.internet2.edu (64.57.28.112) 52.075 ms 52.156 ms 88.596 ms
10 * * ge-6-1-0.0.rtr.losa.net.internet2.edu (64.57.28.96) 496.838 ms
11 hpr-lax-hpr--i2-newnet.cenic.net (137.164.26.133) 76.537 ms 78.948 ms 75.010 ms
12 svl-hpr2--lax-hpr2-10g.cenic.net (137.164.25.38) 82.151 ms 82.304 ms 82.208 ms
13 hpr-stanford--svl-hpr2-10ge.cenic.net (137.164.27.62) 82.504 ms 82.295 ms 82.884 ms
14 boundarya-rtr.stanford.edu (171.66.0.34) 82.859 ms 82.888 ms 82.930 ms
15 * * *
16 * * *
17 www-v6.stanford.edu (171.67.215.200) 83.136 ms 83.288 ms 83.089 ms
Notez en particulier la différence de temps entre les résultats de traceroute du routeur de lavage et du routeur Atla (sauts 7 et 8). le chemin du réseau va d'abord laver puis atla. le lavage prend 50-100 ms pour répondre, atla prend environ 28 ms. Clairement, atla est plus loin, mais ses résultats en matière de traçage suggèrent qu’il est plus proche.
Voir http://www.internet2.edu/performance/ pour de nombreuses informations sur la mesure du réseau. (disclaimer, je travaillais pour internet2). Voir aussi: https://fasterdata.es.net/
Pour ajouter une pertinence particulière à la question initiale ... Comme vous pouvez le constater, j’avais un temps de transfert aller-retour de 83 ms pour stanford. Nous savons donc que le réseau peut au moins aller aussi vite.
Notez que le chemin de réseau de recherche et d’éducation que j’ai emprunté sur ce traceroute sera probablement plus rapide qu’un chemin d’internet de base. En règle générale, les réseaux de R & E surapprovisionnent leurs connexions, ce qui rend peu probable la mise en mémoire tampon de chaque routeur. Notez également le long chemin physique, plus long que les côtes, bien qu'il soit clairement représentatif du trafic réel.
michigan-> washington, dc-> atlanta-> houston-> los angeles-> stanford
