Geum.ru

Книга построена в стиле "вопрос ответ". Ответы бывают двух видов

Вид материалаКнига
Q: Как определить полный путь (прохождение) при скачивании файла Сергей Иванов
Таблица 1 Вычисление скорости передачи пакетов от одного маршрутизатора к другому
Родственные вопросы
Подобный материал:
1   2   3   4   5   6   7   8   9   ...   28

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


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


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


"Мгновенный маршрут" может быть определен утилитой 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й замер

t
2й замер
t
3й замер
t
t средне
откл %

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 умирает на полпути к узлу