Эффективное программирование TCP-IP

       

Как работает traceroute


А теперь разберемся, как работает traceroute. Вспомним (совет 22), что в IP-датаграмме есть поле TTL, которое уменьшается на единицу каждым промежуточным

bsd: $ traceroute panther.cs.ucla.edu

traceroute to panther.cs-ucla.edu (131.179.128.25),

                     30 hops max, 40 bytes packets

  1 tam-f1-pm8.netcom.net (163.179.44.15)

                     178.957 ms 129.049 ms 129.585 ms

  2 tam-f1-gw1.netcom.net (163.179.44.254)

                     1390435 ms 139.258 ms 139.434 ms

  3 h1-0.mig-f1-gw1.netcom.net (165.236.144.110)

                     139.538 ms 149.202 ms 139.488 ms

  4 a5-0-0-7.was-dc-gw1.netcom.net (163.179.235.121)

                     189.535 ms 179.496 ms 168.699 ms

  5 h2-0.mae-east.netcom.net (163.179.136.10)

                     180.040 ms 189.308 ms 169.479 ms

  6 cpe3-fddi-0.Washington.cw.net (192.41.177.180)

                     179.186 ms 179.368 ms 179.631 ms



  7 core5-hssi6-0-0.Washington.cw.net (204.70.1.21)

                     199.268 ms 179.537 ms 189.694 ms

  8 corerouter2.Bloomington.cw.net (204.70.9.148)

                     239.441 ms 239.560 ms 239.417 ms

  9 bordercore3.Bloomington.cw.net (166.48.180.1)

                     239.322 ms 239.348 ms 249.302 ms

 10 ucla-internet –t-3.Bloomington.cw.net (166.48.181.254)

                     249.989 ms 249.384 ms 249.662 ms

 11 cbn5-t3-1.cbn.ucla.edu (169.232.1.34)

                     258.756 ms 259.370 ms 249.487 ms

 12 131.179.9.6 (131.179.9.6) 249.457 ms 259.238 ms 249.666 ms

 13 Panther.CS.UCLA.EDU (131.179.128.25) 259.256 ms 259.184 ms*

bsd: $

Рис. 4.8. Маршрут до хоста panther.cs.ucla.edu, прослеженный traceroute

маршрутизатором. Когда маршрутизатор получает датаграмму, у которой в поле TTL находится единица (или нуль), он отбрасывает ее и посылает отправителю ICМР-сообщение «истекло время в пути».

Программа traceroute использует это свойство. Сначала она посылает получателю UDP-датаграмму, в которой TTL установлено в единицу. Когда датаграмма доходит до первого маршрутизатора, тот определяет, что поле TTL равно единице, отбрасывает датаграмму и посылает отправителю ICМР-сообщение. как вы узнаете адрес первого промежуточного узла (из поля «адрес отправителя» в заголовке ICMP). И traceroute пытается выяснить его имя с помощью Функции gethostbyaddr. Чтобы получить информацию о втором узле, traceroute Повторяет процедуру, на этот раз установив TTL равным двум. Маршрутизатор в первом промежуточном узле уменьшит TTL на единицу и отправит датаграмму Дальше. Но второй маршрутизатор определит единицу в поле TTL, отбросит датаграмму и пошлет ICМР-сообщение отправителю. Повторяя эти действия, но увеличивая каждый раз значение TTL, traceroute может построить весь маршрут От отправителя к получателю.




Рис. 4.9. Маршрутизатор N ошибочно переправляет датаграмму с TTL, равным нулю

Когда датаграмма с достаточно большим начальным значением TTL наконец доходит до получателя, TTL будет равно единице, но, поскольку дальше переправлять датаграмму некуда, стек TCP/IP попытается доставить ее ожидающему приложению. Однако traceroute установлено в качестве порта назначения такое значение, которое вряд ли кем-то используется, поэтому хост-получатель вернет ICMP-сообщение «порт недоступен». Получив такое сообщение, tracerout определяет, что конечный получатель обнаружен, и трассировку можно завершить.

Поскольку протокол UDP ненадежен (совет 1), не исключена возможность потери датаграмм. Поэтому traceroute пытается «достучаться» до каждого промежуточного хоста или маршрутизатора несколько раз, то есть посылает несколько датаграмм с одним и тем же значением TTL. По умолчанию делается три попытки, но это можно изменить с помощью опции -q.

Кроме того, tracerout нужно определить, сколько времени ждать IСМР- сообщения после каждой попытки. По умолчанию время ожидания - 5 с, но это значение можно изменить с помощью опции -w. Если в течение этого времени IСМР-сообщение не получено, то вместо значения RTT печатается звездочка (*).

В описанном процессе могут быть некоторые трудности: traceroute полагается на то, что маршрутизаторы будут, как положено, отбрасывать IP-датаграммы, в которых TTL равно единице, и посылать при этом ICMP-сообщение «истекло время в пути». К сожалению, некоторые маршрутизаторы таких сообщений не посылают, и тогда печатаются звездочки. Есть также маршрутизаторы, которые посылают сообщение, но с тем значением TTL, которое обнаружили во входящей датаграмме. Поскольку оно оказалось равным нулю, то датаграмма будет отброшена первым узлом на обратном пути (если, конечно, это не случилось на первом шаге). Результате точно такой же, как если бы ICMP-сообщение не посылалось вовсе.

Некоторые маршрутизаторы ошибочно переправляют далее датаграммы, в которых TTL равно нулю. Если такое происходит, то следующий маршрутизатор, например N + 1, отбросит датаграмму и вернет ICMP-сообщение «истекло врем в пути». На дальнейшей итерации маршрутизатор N + 1 получит датаграмму со значением TTL, равным единице, и вернет обычное ICMP-сообщение. Таким образом, маршрутизатор N + 1 появится дважды: первый раз в результате ошибки предыдущего маршрутизатора, а второй - после корректного отбрасывания датаграммы с истекшим временем работы. Такая ситуация изображена на рис. 4.9, а ее видимое проявление - в строках, соответствующих узлам 5 и 6 на рис. 4.10.



bed: $ traceroute syrup.hill.com

traceroute to syrup.hil1.corn (208.162.106.3),

30 hops max, 40 byte packets

  1  tam-fl-pm5.netcom.net (163.179.44.11)

129.120 ms  139.263 ms  129.603 ms

  2  tarn-fl-gwl.netcom.net (163.179.44.254)

29.584 ms  129.328 ms  149.578 ms

  3  hl-O.mig-fl-gwl.netcom.net (165.236.144.110)

219.595 ms  229.306 ms  209.602 ms

  4  a5-0-0-7.was-dc-gwl.netcom.net (163.179.235.121)

179.248 ms  179.521 ms  179.694 ms

  5  h2-0.mae-east.netcom.net (163.179.136.10)

179.274 ms  179.325 ms  179.623 ms

  6  h2-0.mae-east.netcom.net (163.179.136.10)

169.443 ms  199.318 ms  179.601 ms

  7  cpe3-fddi-0.washington.cw.net (192.41.177.180) 189.529 ms

core6-seria!5-l-0.Washington.cw.net

(204.70.1.221) 209.496 ms  209.247 ms

  8  bordercore2.Boston.cw.net (166.48.64.1)

209.486 ms  209.332 ms  209.598 ms

  9  hill-associatesinc-internet.Boston.cw.net (166.48.67.54)

229.602 ms  219.510 ms *

 10  syrup.hill.corn (208.162.106.3) 239.744 ms 239.348 m 219.607 ms

bsd: $

Рис. 4.10. Выдача traceroute с повторяющимися узлами

На рис. 4.10 показано еще одно интересное явление. Вы видите, что в узле 7 маршрут изменился после первой попытки. Возможно, это было вызвано тем, что маршрутизатор в узле 6 выполнил какие-то действия по балансированию нагрузки. А возможно, что узел среЗ-fddi-0 .washington.cw.net за время, прошедшее с момента первой попытки, успел «отключиться», и вместо него был использован маршрутизатор с адресом core6-serial5-l-0.Washington.cw.net.

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



Следующая проблема при работе с traceroute - это асимметрия маршрутов. Запуская traceroute, вы получаете маршрут от пункта отправления до пункта назначения, но нет гарантии, что датаграмма, отправленная из пункта назначении будет следовать тем же маршрутом. Хотя кажется естественным предположении о том, что почти все маршруты одинаковы, в действительности, как показано в работе [Paxson 1997], 49% изученных маршрутов демонстрируют асимметрию хотя бы в одном промежуточном узле.

Примечание: С помощью опции -s, которая устанавливает режим свободной маршрутизации, заданной источником (loose source routing) oт пункта назначения в пункт отправления, теоретически можно получить оба маршрута. Но, как отмечает Джекобсон в комментариях к исходному тексту trace-route, количество маршрутизаторов, которые некорректно выполняют маршрутизацию, заданную источником, настолько велико, что этот метод на практике не работает. В главе 8 книги [Stevens 1994] объясняетсясуть метода и приводится пример его успешного применения.

В другой работе Паксон отмечает, что асимметричные маршруты возникают также из-за эффекта «горячей картофелины» [Paxson 1995].

Примечание: Этот эффект состоит в следующем. Предположим, что хост А, расположенный на восточном побережье Соединенных Штатов, отправляет датаграмму хосту В на западном побережье. Хост А подключен к Internet через провайдера 1, а хост В - через провайдера 2. Допустим, что у обоих провайдеров есть опорные сети, проходящие через всю страну. Поскольку полоса пропускания опорной сети - это дефицитный ресурс, провайдер 1 пытается доставить датаграмму хосту в сети провайдера 2, пользуясь его же опорной сетью. Но точно также, когда хост В отвечает, провайдер 2 пытается доставить ответ на противоположное побережье, пользуясь опорной сетью провайдера 1. Отсюда и асимметрия.


Содержание раздела