Почему traceroute занимает намного больше времени, чем пинг?

Как это объяснить?

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.

Таким образом, среднее время должно быть: 1 + 7 + 108 + 2 + 1 + 1 + 2 + 1 + 1 + 2 + 2 + 33 + 34 + 34 + 35 + 34 + 34 + 35 + 34, что намного больше, чем 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

Вы не можете просто сложить все эти числа. Это время проверки связи с каждым из переходов на пути к Google. Так что, естественно, каждая нога пути становится все дальше и дальше, и вы видите разное время пинга. Если вы посмотрите на время последнего пинга в tracert (34 мс) и время, которое вы получили, когда вы выполнили пинг (34 мс), они совпадают. Программа tracert не медленнее, чем ping.

Я хотел бы предложить прочитать о том, как работает traceroute:
http://en.wikipedia.org/wiki/Traceroute

Вы можете увидеть пинг, как поездка из Нью-Йорка в Сан-Франциско. Это займет, скажем, 200 часов (я из Швейцарии и не знаком с расстояниями в США)

Но водитель должен вернуться в Нью-Йорк, чтобы сказать вам, что он был в Сан-Франциско. Вы смотрите на часы, и теперь вы рассчитываете, что он взял 400 часов на расстояние. Вот что делает Пинг. Traceroute делает следующее: скажите своему водителю, что ему следует ехать из Нью-Йорка в Сан-Франциско, и каждый раз, когда он приезжает на перекресток, он должен возвращаться и сообщать вам его название. Итак, он уже в пути, и первые несколько перекрестков находятся в Нью-Йорке. Так что он довольно быстро едет к вам и называет название перекрестка. Но когда он доберется до него, ему потребуется больше времени, чтобы вернуться к вам. и так далее...

Поэтому, если учесть все часы вождения, которые он проделал, ему понадобилось бы гораздо больше времени, чтобы сообщить обо всех перекрестках, чем если бы ему просто пришлось ехать в Сан-Франциско. Надеюсь, это прояснит некоторые вещи для вас ...

Фактически это в основном связано с тем, что PING отправил ICMP-запрос по сети в DNS и другое сетевое устройство.

Тем не менее, Traceroute отправляет много пакетов с очень коротким TTL.

Например, когда вы пытаетесь присоединиться к www.google.com со своего места, traceroute отправил пакет на www.google.com с TTL, установленным в 1, и дождался ответа от устройства сети первой встречи.

Затем Traceroute отобразит IP-адрес устройства первой сети на экране, и после этого произойдет то же самое, но на этот раз с TTL, установленным в 2 и т. Д.

В конце концов, Traceroute ждал примерно половину времени, потому что при каждой отправке он ожидает ответа от сетевого устройства.

Traceroute всегда сообщает вам среднее значение по месту назначения, а не количество раз, т. Е. В вашем случае это 34ms с pingи traceroute.

Если бы traceroute делал то, что вы предлагаете, его вывод был бы совершенно нечитаемым.

Если вас интересует только время отклика пункта назначения, этого pingвполне достаточно, tracerouteесли вам нужно что-то отладить на маршруте к пункту назначения. Более того, все переходы между вами и пунктом назначения являются маршрутизаторами, и большую часть времени маршрутизаторы имеют приоритет в том, что делать, то есть сначала маршрутизируют пакеты, а затем отвечают на ping или traceroute (то есть в первом случае, отвечая на «а» icmp echo reply, а во втором случае «на» icmp time exceeded) и часто отвечаю медленнее (когда они отвечают вообще)

Для потомков, так как ни один из правильных ответов не очень ясен ...

-

Каждый раз, показанный в трассировке, ВСЕГО ВРЕМЕНИ ОТ ВАШЕЙ МАШИНЫ (или машины, выполняющей трассировку ...) до ЭТОГО ОСОБЕННОГО УЗЛА.

Другими словами, время, показанное на 2-м узле, - это не время, затрачиваемое между узлами 1 и 2, а скорее общее время, затраченное между источником, первым узлом и вторым узлом, вместе взятыми.

Таким образом, в среднем время, показанное на каждом узле, должно примерно соответствовать времени, которое вы получили бы, если бы вы пропинговали этот конкретный узел «напрямую» (это не более прямое, чем трассировка в реальности ... обычно это будет идти по тому же пути в Интернете).

Просто имейте в виду, что существует такая вещь, как «скачок задержки». Самый точный способ найти источник любой задержки - запустить трассировку при повторении с использованием пакетного файла (если вы работаете в Windows) и найти ближайший (с наименьшим номером) узел с большими числами в любой момент времени.

-

Для командного файла откройте блокнот и введите эти 3 строки:

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

Затем сохраните как «Trace.bat», но убедитесь, что изменили тип файла в диалоге сохранения на «все файлы» перед сохранением, иначе он все равно будет сохранен как текстовый файл.

При открытии, это будет постоянно запускать traceroutes (в Google). Вы можете остановить его, нажав Ctrl + C, пока у вас выбрано окно.

-

Разумеется, вы можете изменить место, где выполняется трассировка, изменив "www.google.com" на любой адрес, который вам нравится.

Вы также можете удалить опцию «-d», если хотите увидеть разрешенные имена хостов, но это сделает трассировку более длительной из-за получения имен хостов с DNS-сервера для каждого узла (однако это НЕ меняет сами фактические результаты) ).

Наконец, если вы нашли узел с большим временем и просто хотите запустить трассировку к этому конкретному узлу на случай, если у другого узла возникнут проблемы, вы можете либо изменить «www.google.com» на IP-адрес этого узла или имя хоста, ИЛИ Вы можете использовать опцию -h, чтобы указать, сколько узлов искать, т.е.

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

Поскольку tracert использует UDP-пакеты, например, ping использует ICMP-пакеты. Под Linux есть traceroute -Iвозможность сделать трассировку ICMP.

В вашем тесте время для подключения к Google одинаково в traceroute и ping: 34 мс. Все маршрутизаторы в середине имеют свое время для ответа, но не влияют на окончательное время передачи.

http://en.wikipedia.org/wiki/Traceroute объяснить все на Traceroute

Вы можете повысить свою трассировку, отключив обратный просмотр DNS, который часто приводит к сбою: tracert -d www.google.com