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

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

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

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

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

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

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

-

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

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

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

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

-

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

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

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

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

-

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

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

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

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

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

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

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

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

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

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

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

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

Ответ

Причина traceroute медленно это:

1. он последовательно пингует каждый маршрутизатор по пути, пока не достигнет хоста (последовательно, в зависимости от точной реализации)
2. это медленнее всего, когда есть *. Это означает, что данный маршрутизатор не подтвердил получение пакета, и вместо этого истекло время ожидания запроса. Тайм-аут по умолчанию составляет 5 секунд и traceroute по умолчанию отправляет три пакета, поэтому требуется 15 секунд, чтобы выяснить, что один из маршрутизаторов не ответил (* * *).¹

Ускориться

Вы можете ускорить traceroute, отправив только два зонда на маршрутизатор и сократив время ожидания до 3 секунд, например:

traceroute -q 2 -w 3 google.com

Задний план

Команда traceroute используется, чтобы увидеть, как маршрутизируются пакеты. Это работает отправка пакетов с увеличивающимися значениями TTL, начиная с 1. Итак, первый маршрутизатор получает пакет и уменьшает значение TTL на единицу, таким образом отбрасывая пакет. В маршрутизатор отправляет нам ICMP-сообщение о превышении времени. Затем следующий пакет получает TTL равный 2, поэтому он проходит мимо первого маршрутизатора, но когда он попадает на второй маршрутизатор, TTL равен 0, и он возвращает другое сообщение ICMP Time Exceeded. Traceroute работает таким образом, потому что при отправке и отбрасывании пакетов он составляет список маршрутизаторов, через которые проходят пакеты, пока, наконец, не доберется до места назначения и не получит сообщение ICMP Echo Reply.²

Обратите внимание, что превышенное время ICMP отличается от времени ожидания запроса. В последнем случае ответа нет вообще, а в первом - есть.

Чтобы ускорить процесс, нам не обязательно ждать ответа от маршрутизатора, прежде чем пинговать следующий:

Однако современные версии программы traceroute не отправляют только один пакет за раз. Чтобы ускорить это отправляет сразу несколько пакетов с разным количеством переходов, поэтому программе не нужно ждать ответа от каждого маршрутизатора перед отправкой следующего пакета.³

¹ Источник: что означает "***", когда traceroute

² Источник: https://linuxjourney.com/lesson/traceroute

³ Источник: https://www.perl.com/article/how-does-traceroute-work-/

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

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

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

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