Как определить полный путь (прохождение) при скачивании файла Сергей Иванов
Точный маршрут пакетов неопределим в силу своего непостоянства – пакеты движутся по очень сложной кривой, избегая перегруженных маршрутизаторов и огибая поврежденные участки. Вовсе не факт, что два одновременно посланных пакета дойдут по получателя одним и тем же путем: вот случится посреди дороги сбой – один пакет успеет проскочить, а второй будет вынужден идти в обход.
??? Рисунок "карикатура" Дорога через лес, падает дерево, один человек, символизирующий пакет, успевает под ним проскочить, а второй идет по узкой тропике в обход.
"Мгновенный маршрут" может быть определен утилитой 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% |
Время задержки по мере продвижения по цепочке маршрутизаторов нарастает отнюдь не линейно, а хаотично, испещряясь отрицательными значениями, а погрешность в своей массе залазит за 50%, местами доходя до 100% и выше. Не очень-то точные измерения получаются!
Родственные вопросы:
Провайдер и удаленный доступ à Оптимизация соединения с Интернет
Почему tracert умирает на полпути к узлу