Для данной заметки я взял самую существенную информацию. Если хотите почитать больше, открывайте исходную статью.
Типичный результат работы команды traceroute (tracert):
- Код: Выделить всё
Трассировка маршрута к yahoo.com [69.147.125.65]
с максимальным числом прыжков 30:
1 10 ms 11 ms 12 ms 172.16.0.1
2 8 ms 10 ms 8 ms cerberus-pluton.telenet.dn.ua [195.39.211.177]
3 8 ms 11 ms 8 ms juniper.telenet.dn.ua [195.39.211.181]
4 21 ms 15 ms 15 ms pandora.telenet.dn.ua [195.39.210.25]
5 * * * Превышен интервал ожидания для запроса.
6 38 ms 33 ms 25 ms telenet-gw.so.net.ua [193.254.233.97]
7 164 ms 147 ms 146 ms gi9-43.214.ccr01.kbp01.atlas.cogentco.com [149.6.190.129]
8 169 ms 164 ms 162 ms te7-2.ccr01.bts01.atlas.cogentco.com [130.117.3.69]
9 144 ms 153 ms 151 ms te8-7.ccr01.muc01.atlas.cogentco.com [130.117.48.173]
10 289 ms 297 ms 292 ms te0-1-0-2.mpd21.fra03.atlas.cogentco.com [130.117.0.165]
11 180 ms 177 ms 158 ms te0-1-0-2.mpd21.par01.atlas.cogentco.com [130.117.0.102]
12 199 ms 176 ms 194 ms te0-0-0-7.mpd21.iad02.atlas.cogentco.com [154.54.25.113]
13 144 ms 183 ms 150 ms te4-7.mpd01.iad01.atlas.cogentco.com [154.54.31.198]
14 167 ms 168 ms 180 ms yahoo.iad01.atlas.cogentco.com [154.54.10.2]
15 173 ms 152 ms 152 ms ae-6.pat1.dcp.yahoo.com [216.115.102.174]
16 172 ms 186 ms 171 ms ae2-p170.msr2.re1.yahoo.com [216.115.108.69]
17 168 ms 186 ms 186 ms te-9-4.bas-a1.re1.yahoo.com [66.196.112.207]
18 161 ms 225 ms 154 ms ir1.fp.vip.re1.yahoo.com [69.147.125.65]
Трассировка завершена.
Описание работы traceroute
Все IP-пакеты изначально отсылаются с выставленным оптимальным образом значением Time-To-Live (TTL). При каждом проходе через IP-маршрутизатор значение TTL уменьшается на единицу. Как только значение TTL становится равным нулю, пакет считается недействительным и отбрасывается. Таким образом, в сети пресекается появление «вечно блуждающих пакетов» в случае неправильной настройки маршрутизатора.
Каждый запрос traceroute отправляется с очень малым значением TTL. Как только значение TTL приравнивается к нулю, происходит не привычный отброс пакета, а отправка специального предупреждения — «ICMP TTL-exceeded». В это время traceroute ожидает получение этого пакета, чтобы замерить время, которое понадобилось на его доставку. Для первого хопа (прыжка, узла — прим. пер.) TTL устанавливается в значение «1», при этом отправляется три запроса и замеряется время отклика. Затем, для следующего хопа значение TTL увеличивается на единицу и снова отправляется три запроса для замера времени отклика. Так продолжается до тех пор, пока узел на очередном хопе не ответит сообщением «echo». Для traceroute это показатель того, что перед нами искомый узел, а не очередной промежуточный маршрутизатор. Выполнение traceroute завершается.
Заблуждения, к которым обычно приводит неправильная интерпретация вывода команды traceroute
- Отображаемый маршрут — это прямой маршрут, по которому идут запросы к опрашиваемым узлам. Установить же маршрут, по которому они возвращаются к абоненту, невозможно. Возможен вариант, когда обратный маршрут будет отличаться от прямого и при этом будет задействоваться иное количество хопов. Каждый из отображаемых маршрутизаторов может иметь свой обратный маршрут. Более того, возможна ситуация, когда каждый из трех ответов одного маршрутизатора (то есть, на одном хопе) будет проходить по разным маршрутам. Все это разнообразие маршрутов может вносить искажения в отображаемое время отклика (RTT) узла. Например, возможны резкие флуктуации RTT по сравнению с предыдущим маршрутизатором, либо большой разброс в RTT одного маршрутизатора (см. хопы № 9-10).
- Современные маршрутизаторы отдают высокий приоритет пакетам с данными и минимально возможный — служебным пакетам. Это, к примеру, может выражаться в необычно высоких значениях RTT (см. хоп № 9), в то время как пакеты с данными этим же маршрутизатором будут доставляться в нормальном режиме. Маршрутизаторы также могут отбрасывать пакеты со служебной информацией, что в нашем примере выглядит как * * * (см. хоп № 5). В обоих случаях приемлемое время отклика на других хопах, через которые пакет должен пройти, чтобы добраться до места назначения, а также отсутствие потерь пакетов свидетельствуют о том, что маршрутизатор на хопе № 5 находится в надлежащем состоянии. Значения RTT на последнем хопе более близки к истинным по той причине, что они исходят от искомого узла, а не промежуточного маршрутизатора. Таким образом, только лишь время отклика последнего узла является единственно верным при определении времени отклика игровых серверов и пр.
- Скорость света при прохождении сигнала по оптоволокну или по медному кабелю также привносит задержки в RTT отдаленных от абонента узлов. Имя этому явлению — задержка распространения. Используя самые оптимистичные прогнозы, можно предположить, что каждые 160 км будут добавлять по меньшей мере 1 мс к конечному RTT. На практике значения получаются несколько выше, поскольку сигнал проходит через различные повторители и усилители. К примеру, RTT от узла, который находится за Атлантическим океаном по отношению к абоненту, будет равняться как минимум 110 мс. В случае с примером выше, маршрутизатор на хопе № 6 находится в Украине, а маршрутизатор на хопе № 7 - в США, поэтому стремительное увеличение времени отклика неизбежно.
- Большие значения RTT не всегда означают проблемы с передачей пакетов. Алгоритмы прохождения TCP-пакетов разработаны таким образом, что имеется возможность контролировать оптимальный объем трафика при прохождении на длинные расстояния при условии, что значение "TCP Receive Window" достаточно велико. В современных операционных системах (Windows Vista, Windows 7) значение RWIN автоматически адаптируется в зависимости от пропускной способности канала и условий соединения с интернетом (прим. пер.).
- Малые значения RTT также не обязательно означают и хорошее состояние линии. Вполне возможна такая ситуация, когда на маршруте у большинства узлов будет отображаться низкое время отклика, но при этом будут происходить потери пакетов. Некоторые маршрутизаторы устроены таким образом, что не отвечают на запросы команды traceroute (см. узел № 5 в примере выше). В результате, абонент будет видеть строку из трех звездочек, однако команда traceroute может продолжить выдавать информацию вплоть до узла назначения.
- Некоторые компании блокируют запросы traceroute на брандмауэрах. В таком случае, traceroute с определенного хопа всегда будет выдавать три звездочки и никогда не дойдет до узла назначения.
«Так для чего вообще нужна эта команда?», спросите вы. Прежде всего, она позволяет надежным образом определить прямой маршрут прохождения пакетов. Но не стоит строить какие-то конкретные выводы о состоянии сети на основании одного лишь отчета traceroute. С уверенностью можно сказать, что результат работы traceroute не является достаточным основанием утверждать, что на линии присутствуют проблемы как минимум по той причине, что traceroute замеряет время отклика каждого узла всего трижды. Однако, если же признаки потерь пакетов (звездочки) проявляются начиная с определенного хопа и продолжаются на каждом следующем, то можно с определенной степенью уверенности утверждать, что на этом участке на данный момент присутствуют проблемы.
