Pourquoi traceroute prend-il beaucoup plus de temps que ping?

16

Comment expliquer ça?

C:\Documents and Settings\Administrator>tracert google.com

Tracing route to google.com [64.233.189.104]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  192.168.0.1
  2     7 ms    <1 ms    <1 ms  reserve.cableplus.com.cn [218.242.223.209]
  3   108 ms   135 ms   163 ms  211.154.70.10
  4     *        *        *     Request timed out.
  5     2 ms     *        1 ms  211.154.64.114
  6     1 ms     1 ms     1 ms  211.154.72.185
  7     1 ms     1 ms     1 ms  202.96.222.77
  8     2 ms     1 ms     2 ms  61.152.81.145
  9     1 ms     2 ms     1 ms  61.152.86.54
 10     1 ms     1 ms     1 ms  202.97.33.238
 11     2 ms     2 ms     2 ms  202.97.33.54
 12     2 ms     1 ms     2 ms  202.97.33.5
 13    33 ms    33 ms    33 ms  202.97.61.50
 14    34 ms    34 ms    34 ms  202.97.62.214
 15    34 ms   186 ms    37 ms  209.85.241.56
 16    35 ms    35 ms    44 ms  66.249.94.34
 17    34 ms    34 ms    34 ms  hkg01s01-in-f104.1e100.net [64.233.189.104]

Trace complete.

Le temps moyen devrait donc être: 1 + 7 + 108 + 2 + 1 + 1 + 2 + 1 + 1 + 2 + 2 + 33 + 34 + 34 + 35 + 34 + 34 + 35 + 34, ce qui est beaucoup plus grand que ping

C:\Documents and Settings\Administrator>ping google.com

Pinging google.com [64.233.189.104] with 32 bytes of data:

Reply from 64.233.189.104: bytes=32 time=34ms TTL=241
Reply from 64.233.189.104: bytes=32 time=34ms TTL=241
Reply from 64.233.189.104: bytes=32 time=34ms TTL=241
Reply from 64.233.189.104: bytes=32 time=34ms TTL=241

Ping statistics for 64.233.189.104:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 34ms, Maximum = 34ms, Average = 34ms
ping networking splattne
la source
3
Tant de mauvaises réponses sur cette question. Vous me rappelez tous, en quelque sorte, youtube.com/watch?v=SXmv8quf_xM
Tom O'Connor

Réponses:

16

Vous ne pouvez pas simplement additionner tous ces chiffres. C'est le temps de ping pour chacun des sauts sur le chemin de Google. Donc, nativement, chaque étape du chemin s'éloigne de plus en plus et vous voyez des temps de ping variables. Si vous regardez l'heure du dernier ping dans tracert (34 ms) et l'heure que vous avez reçue lorsque vous avez émis le ping (34 ms), ce sont les mêmes. Le programme tracert n'est pas plus lent que ping.

Je suggère de lire comment fonctionne un traceroute:
http://en.wikipedia.org/wiki/Traceroute

einstiien
la source
Ça ne l'est pas farther and farther away.
Je ne comprends pas ce que tu veux dire. Chaque adresse IP répertoriée sur le traceroute est l'adresse du prochain routeur en ligne entre vous et google. Dans la topologie de réseau "logique", ceux-ci s'éloignent au fur et à mesure que vous progressez dans la liste. De plus, la plupart du temps, ils s'éloignent physiquement de votre position géographique. Bien que ce ne soit pas toujours vrai, car les itinéraires semblent parfois contourner la carte "inutilement". Mais mon point est que la distance physique et les sauts multiples augmentent le temps de ping.
einstiien
Essayez d'envoyer une requête ping à chaque nœud de l'itinéraire. Vous devriez trouver le même total (à peu près).
Chris Nava
1
Peut-être que PHP est sur le mauvais site de stackoverflow, et signifie que plus loin se réfère à la distance physique alors que plus est plus approprié pour la distance du réseau? english.stackexchange.com
dunxd
12

Vous pouvez voir le ping comme un lecteur de New York à San Francisco. Cela prend, disons 200 heures (je suis de la Suisse et je ne connais pas les distances aux USA)

Mais le chauffeur doit revenir à New York pour vous dire qu'il était à San Francisco. Vous regardez la montre et vous calculez maintenant qu'il a pris 400 heures pour la distance. Voilà ce que fait Ping. Ce que fait Traceroute, c'est: Dites à votre chauffeur qu'il devrait conduire de New York à San Franciso et chaque fois qu'il vient sur un carrefour, il devrait revenir et vous en dire le nom. Il est donc en route et les premiers carrefours sont à New York. Il est donc assez rapide pour vous ramener et vous dire le nom du carrefour. Mais quand il ira plus loin, il mettra plus de temps à vous revenir. etc...

Donc, si vous comptez toutes les heures de conduite qu'il était sur son chemin, il devrait prendre beaucoup plus de temps pour signaler tous les carrefours que s'il devait simplement conduire jusqu'à San Francisco. J'espère que cela clarifie certaines choses pour vous ...

Bona
la source
2
Une meilleure analogie serait que vous envoyiez 30 conducteurs, en disant à chacun de se diriger vers New York, mais chacun doit faire demi-tour et revenir au premier carrefour, au deuxième carrefour, au troisième carrefour, etc., tous le chemin jusqu'à trente carrefours (en espérant qu'il y en ait moins de 30 entre SF et NY).
Jed Daniels
0

En fait, c'est essentiellement dû au fait que PING a envoyé une demande ICMP sur le réseau au DNS et à une autre appliance du réseau.

Cependant, Traceroute envoie beaucoup de paquets avec un TTL vraiment court.

Par exemple, lorsque vous essayez de rejoindre www.google.com depuis votre siège, traceroute a envoyé un paquet à www.google.com avec un TTL réglé à 1, et attendez une réponse de la première appliance du réseau de rencontre.

Ensuite, Traceroute affiche l'IP de la première appliance du réseau sur votre écran, et après cela fera la même chose mais cette fois avec un TTL réglé sur 2, etc.

À la fin, Traceroute a attendu environ la moitié du temps car, à chaque envoi, il attend une réponse de l'appliance d'un réseau.

Dr I
la source
0

Traceroute vous indique toujours la moyenne de la destination, pas une accumulation de temps, c'est-à-dire, dans votre cas, c'est 34ms avec pinget traceroute.

Si traceroute devait faire ce que vous proposez, sa sortie serait tout à fait illisible.

Si vous êtes uniquement intéressé par le temps de réponse de la destination, cela pingsuffit, traceroutec'est quand vous devez déboguer quelque chose sur l'itinéraire vers la destination. De plus, tous les sauts entre vous et la destination sont des routeurs, et la plupart du temps, les routeurs ont une priorité sur ce qu'il faut faire, c'est-à-dire les premiers paquets de route, puis répondre à ping ou traceroute (c'est-à-dire, le premier cas, répondre à un icmp echo reply, et dans le second cas, un icmp time exceeded) et répondent souvent plus lentement (quand ils répondent)

tapis
la source
0

Pour la postérité, car aucune des bonnes réponses n'est très claire ...

-

Chaque fois indiqué dans le traceroute est le TEMPS TOTAL de VOTRE MACHINE (ou la machine faisant le traceroute ...) à CE NŒUD PARTICULIER.

En d'autres termes, le temps affiché sur le 2ème nœud n'est pas le temps pris entre les nœuds 1 et 2, mais plutôt le temps total pris entre la source, le premier nœud et le deuxième nœud tous réunis.

Donc, en moyenne, les temps affichés sur chaque nœud devraient correspondre approximativement aux temps que vous obtiendriez si vous deviez envoyer un ping à ce nœud particulier "directement" (ce n'est pas plus direct qu'un traceroute en réalité ... il suivra généralement le même chemin sur Internet).

Gardez simplement à l'esprit qu'il existe une «pointe de décalage». La façon la plus précise de trouver la source de tout retard est d'exécuter un traceroute lors de la répétition à l'aide d'un fichier de commandes (si vous êtes sous Windows) et de trouver le nœud le plus proche (numéroté le plus bas) qui a des nombres élevés à un moment donné.

-

Pour le fichier de commandes, ouvrez le bloc-notes et tapez ces 3 lignes:

:start
tracert -d www.google.com
goto start

Ensuite, enregistrez-le sous "Trace.bat" mais assurez-vous de changer le type de fichier dans la boîte de dialogue d'enregistrement en "tous les fichiers" avant de l'enregistrer ou il sera toujours enregistré en tant que fichier texte.

Une fois ouvert, cela exécutera constamment traceroutes (vers google). Vous pouvez l'arrêter en appuyant sur ctrl + c pendant que la fenêtre est sélectionnée.

-

Vous pouvez, bien sûr, changer l'endroit où il exécute le traceroute en remplaçant "www.google.com" par l'adresse de votre choix.

Vous pouvez également supprimer l'option "-d" si vous souhaitez voir les noms d'hôte résolus, mais cela rendra le traceroute plus long en raison de l'obtention desdits noms d'hôte à partir d'un serveur DNS pour chaque nœud (cela ne modifie toutefois pas les résultats réels eux-mêmes cependant ).

Enfin, si vous trouvez un nœud avec des temps élevés et que vous souhaitez simplement exécuter des traceroutes vers ce nœud particulier au cas où un autre nœud avant qu'il ne rencontre des problèmes, vous pouvez soit remplacer "www.google.com" par l'adresse IP ou le nom d'hôte de ce nœud, OU vous pouvez utiliser l'option -h pour spécifier le nombre de nœuds à rechercher, c'est-à-dire ...

:start
tracert -d -h 5 www.google.com
goto start
Laike Endaril
la source
Une note importante est qu'un nœud répond avec ICMP, mais le but principal d'un routeur est de router des paquets, et la création de réponses ICMP est loin dans la liste de ce qu'il fait. Un routeur acheminera, et il se mettra à envoyer des messages ICMP quand il en aura le temps. C'est pourquoi le temps intermédiaire pourrait être plus long que le chemin complet; le routeur intermédiaire pourrait être beaucoup plus occupé que le nœud final.
Ron Maupin
Oui, la priorité QOS d'ICMP est généralement inférieure, mais souvent lorsque vous exécutez une traceroute, c'est parce qu'un problème existe déjà (vous avez des pointes de décalage ou un mauvais ping sur un jeu), et ce nœud particulier que vous avez mentionné ( l'occupé) est le goulot d'étranglement que vous recherchez.
Laike Endaril
Je ne parle pas de la priorité QoS, je veux dire le périphérique lui-même créant une réponse ICMP. Le nœud peut en fait être trop occupé à acheminer les paquets pour pouvoir envoyer un message ICMP avant que le nœud d'origine n'expire. Un routeur acheminera les paquets avant de décider d'envoyer un message ICMP. Cela n'a rien à voir avec la QoS.
Ron Maupin
QoS est un terme défini de façon très vague et je considère qu'il inclut toutes les activités qui utilisent le même ensemble de ressources, plutôt que d'exclure les activités qui nécessitent une attention supplémentaire (construction d'un paquet de réponse). Quoi qu'il en soit, cela ne change pas le fait que ledit routeur est sous une charge trop lourde et est susceptible de causer des problèmes, donc les temps élevés d'une traceroute sont toujours un bon indicateur de l'endroit où se trouvent vos problèmes ... avec le exception possible d'une grande quantité de trafic qui a une priorité plus élevée que votre ICMP mais une priorité inférieure à votre trafic normal.
Laike Endaril
-1

Parce que tracert utilise des paquets UDP, comme ping utilise des paquets ICMP. Sous Linux, nous avons la traceroute -Ipossibilité de faire le traceroute ICMP.

Dans votre test, le temps de connexion à Google est le même pour traceroute et ping: 34 ms. Tous les routeurs au milieu ont leur propre temps pour répondre mais cela n'a pas d'impact sur le temps de transfert final.

http://en.wikipedia.org/wiki/Traceroute expliquer tout sur Traceroute

Dom
la source
3
En fait, sous Windows, tracertutilise ICMP par défaut, contrairement à Linux traceroute.
phoebus
tracert utilise la période ICMP. ICMP est le protocole IP 1, UDP est 17.
dbasnett
@dbasnett A l'origine, traceroute envoyait des paquets sortants en UDP, et les paquets de retour sont bien sûr des messages ICMP TTL dépassés. Windows et maintenant d'autres programmes traceroute utilisent des paquets de demande d'écho ICMP pour les messages sortants. En règle générale, lorsque les gens se réfèrent à UDP traceroute ou ICMP traceroute, ce sont ces paquets sortants auxquels ils se réfèrent, car les DEUX mécanismes reposent sur ICMP TTL dépassé les messages revenant à l'expéditeur à partir de sauts le long de la route.
Jed Daniels
-1

Vous pouvez booster votre traceroute en désactivant la recherche DNS inversée, qui échoue souvent: tracert -d www.google.com

Mathieu Chateau
la source
Cela ne rend pas les temps d'aller-retour plus rapides. Cela rend cependant plus rapide le retour des résultats sur votre écran, car il ne fait pas les recherches DNS.
Jed Daniels