Укрощение @Интернет@

       

Как определить полный путь (прохождение) при скачивании файла Сергей Иванов


Точный маршрут пакетов неопределим в силу своего непостоянства – пакеты движутся по очень сложной кривой, избегая перегруженных маршрутизаторов и огибая поврежденные участки. Вовсе не факт, что два одновременно посланных пакета дойдут по получателя одним и тем же путем: вот случится посреди дороги сбой – один пакет успеет проскочить, а второй будет вынужден идти в обход.

??? Рисунок "карикатура" Дорога через лес, падает дерево, один человек, символизирующий пакет, успевает под ним проскочить, а второй идет по узкой тропике в обход.

"Мгновенный маршрут" может быть определен утилитой tracert, входящий в штатную поставку Windows.

Принцип ее работы в общих чертах выглядит так: она отправляет серию дейтаграмм на несуществующий порт по адресу, указанному в командной строке. Значение поля TTL (Time To Live – см. "Оптимизация соединения с Интернет") первой тройки дейтаграмм равно одному. Все три дейтаграммы "прибиваются" первым же маршрутизатором, поскольку он, уменьшив содержимое поля TTL на единицу, обнаруживает, что оно равно нулю, т.е. срок жизни пакета истек и пакет надлежит уничтожить, уведомив об этом отправителя. А, посылая отправителю "похоронку", маршрутизатор тем самым раскрывает свой IP-адрес!

Затем tracert посылает вторую серию дейтаграмм со значением TTL равным двум и их "прибивает" второй маршрутизатор в цепочке… так, поле TTL продолжает увеличиваться до тех пор, пока пакет не достигнет точки назначения.

А как tracert узнает, что пакет достиг точки назначения? Очень просто – конечный узел сам уведомляет об этом, посылая уведомление о невозможности принятия дейтаграммы на несуществующий порт.

Техника трассировки не свободна от ограничений. Вот некоторые из них

– достаточно часто уведомление об уничтожении пакета идет к отправителю совсем другим путем, нежели исходный пакет. Поэтому, определить точное время пересылки пакета невозможно – оно не всегда равно половине времени задержки с момента отправки дейтаграммы до момента получения уведомления. На практике расхождение составляет 300%-400%, если не больше!


– некоторые маршрутизаторы молчаливо "прибивают" мертвые пакеты, не посылая никакого уведомления или, даже если посылают, эти уведомления могут быть блокированы межсетевыми экранами, владельцы которых справедливо полагают: чем меньше всякие личности знают о топологии их сети, тем безопаснее работа и здоровее сон. (см. "Почему tracert умирает на полпути к узлу").

В простейшем случае tracert вызывается с указанием IP-адреса или доменного имени узла назначения, например, так:

C:\>tracert www.aha.ru

Трассировка маршрута к www.aha.ru [195.2.70.38]



1   140 ms   130 ms   140 ms  nas.itech.ru [195.151.210.36]

2   151 ms   140 ms   150 ms  ns.itech.ru [195.151.210.33]

3   171 ms   160 ms   170 ms  gw.itech.ru [195.151.210.29]

4   161 ms   160 ms   180 ms  195.151.200.90

5   260 ms   231 ms   300 ms  krd-gw.mtt.ru [195.151.52.41]

6   391 ms   340 ms   371 ms  Moscow18-S3-7-0.RoSprint.net [194.84.251.246]

7   340 ms   451 ms   410 ms  Moscow41-F1-0.RoSprint.net [193.232.88.23]

8   360 ms   501 ms   330 ms  m9-3-fa4-1-0.zenon.net [193.232.244.48]

9   821 ms   901 ms  2164 ms  jam-l3sw-2-giga1-2.msk.zenon.net [213.189.198.25]

10  441 ms   320 ms   341 ms  jam-slb-1.msk.zenon.net [195.2.70.38]

Отчет tracert состоит из следующих частей: крайняя слева колонка содержит номер маршрутизатора в цепочке, считая от отправителя (узел самого отправителя в этот список не входит); три следующие колонки содержат время задержки с момента посылки дейтаграммы до получения уведомления. В силу непостоянства скорости передачи пакетов, особенно заметной на перегруженных каналах, однократный замер времени задержки не позволяет судить о средней скорости, вот поэтому-то и используются три последовательные посылки, позволяющие вычислить моду {>>>>> сноска мода

– это наиболее часто встречающиеся значение скорости, например, для ряда замеров 1,6,6,6,7 мода равна 6, а среднее арифметическое –5} скорости.

Большинство руководств утверждает, что, анализируя приращение задержки на каждом последующем маршрутизаторе, можно определить скорость пересылки пакетов между маршрутизаторами. Это неверно! Непостоянство временных задержек в несколько раз превышает скорость доставки пакетов от одного маршрутизатора к другому, к тому же как бы это ни казалось парадоксально, но уведомления от дальних маршрутизаторов могут идти более коротким путем, чем от ближних, и результаты вычисления дадут отрицательные значения. Судите сами (см. табл. 1):



1й замер

Dt

2й замер

Dt

 3й замер

Dt

Dt средне

откл %

1

140

+140

130

+130

140

+140

+137

7%

2

151

+11

140

+10

150

+10

+10

10%

3

171

+20

160

+10

170

+20

+17

6%

4

161

-10

160

0

180

+10

0

---

5

260

+99

231

+71

300

+120

+97

70%

6

391

+131

340

+109

371

+71

+104

50%

7

340

-51

451

+111

410

+39

+99

112%

8

360

+20

501

+50

330

-80

-3

---

9

821

+461

901

+400

2164



+140

57%

10

441

-380

320

-581

341



-480

20%

Таблица 1 Вычисление скорости передачи пакетов от одного маршрутизатора к другому

Время задержки по мере продвижения по цепочке маршрутизаторов нарастает отнюдь не линейно, а хаотично, испещряясь отрицательными значениями, а погрешность в своей массе залазит за 50%, местами доходя до 100% и выше. Не очень-то точные измерения получаются!

Родственные вопросы:

Провайдер и удаленный доступ à Оптимизация соединения с Интернет

Почему tracert умирает на полпути к узлу


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