Traceroute: может ли он правильно отследить путь от A до B?

Traceroute — это приложение для отслеживания пути от A до B. (A — ваше местоположение, а B — сервер, который вы хотите отслеживать). В Windows вы можете ввести tracert. Основной алгоритм такой:

send UDP with TTL = 1
Server A1 received, and return ICMP packet to A because TTL is expired.
--> know first machine between. For example A1.

send UDP with TTL = 2
Server A1 received, and send this UDP to server A2.
Server A2 received, and return ICMP packet to A because TTL is expired
--> know second machine between. In this example is A2.

Do it until to B. we can track down: A -> A1 -> A2 -> ... ->B

Этот алгоритм работает корректно? Потому что в разное время промежуточный сервер может отправить сообщение другому серверу. Например, сначала UDP-сообщение отправляется на A1, но позже оно может быть отправлено на другой сервер, например, на B1. Таким образом, трассировка маршрута не будет работать должным образом.

Я что-то неправильно понял?


networking icmp tcp-ip
person hqt    schedule 11.11.2012    source источник
comment
Я проголосовал за это, потому что это очень интересный вопрос! Я тоже хочу узнать ответ от специалистов!   -  person JamesHoux    schedule 11.11.2012

Ответы (2)


arrow_upward
3
arrow_downward

Со страницы руководства:

traceroute отслеживает маршрут, по которому пакеты проходят из IP-сети на пути к заданному хосту.

Поэтому, если вы пытаетесь найти один из возможных путей, по которым может пройти ваш пакет, вы найдете друга в traceroute .

Теперь, поскольку таблицы маршрутизации не меняются каждую минуту, отправляемые вами пакеты скорее всего будут проходить по тому же пути, который отслеживается traceroute.

Еще один важный момент, который нельзя упустить, — это параметр записать маршрут в заголовке IP v4. Как только вы укажете, что хотите использовать эту опцию, каждый маршрутизатор на пути добавит свой IP-адрес к параметрам в заголовке. Подробнее об этом можно прочитать здесь. Загвоздка в том, что пункт назначения узнает о промежуточных переходах, а не источник.

Я вижу, что вы упустили роль эхо-запросов и ответов icmp в описании traceroute. Если это было сделано непреднамеренно, посмотрите .

Обновление: вы можете увидеть опцию записи маршрута в действии, выполнив ping -R

ping -R Включает запись маршрута для пакетов эхо-запроса и отображает буфер маршрута для возвращаемых пакетов (игнорируется многими маршрутизаторами).

person axiom    schedule 11.11.2012

arrow_upward
2
arrow_downward

Алгоритм работает корректно. Действительно, маршрутизация может измениться из-за различных серверов на пути, таких как нагрузка на сервер или его доступность. Допустим, вы хотите отправить сообщение из точки А в точку Б. Если маршрут нельзя изменить, что произойдет, если какой-либо сервер на маршруте выйдет из строя? Если бы маршрутизацию нельзя было настроить динамически, это привело бы к невозможности доставки сообщения в пункт назначения в этом примере. Вот другой пример: предположим, у вас есть сервер, который днем ​​используется для тяжелых вычислений, а ночью он простаивает. Можно разрешить ему пропускать трафик только ночью, поэтому любую маршрутизацию, использующую его, нужно будет менять днем.

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

Дополнение:

Tracert отправляет сообщение от A к B. Он показывает переходы по пути. Эти прыжки составляют допустимый маршрут от A до B во время выполнения. Нет никакой гарантии, что соединение между двумя соседними точками на пути будет действительным после завершения прыжка. Единственное, что гарантируется, это то, что для каждого прыжка существовала связь между двумя его конечными точками, когда сообщение, отправленное tracert, проходило там.

person SomeWittyUsername    schedule 11.11.2012
comment
Я думаю, вы неправильно поняли мой вопрос. У меня вопрос, потому что маршрут изменчив, поэтому мы не можем точно знать маршрут от А до Б с помощью этого алгоритма? - person hqt; 11.11.2012