Поиск

Полнотекстовый поиск:
Где искать:
везде
только в названии
только в тексте
Выводить:
описание
слова в тексте
только заголовок

Рекомендуем ознакомиться

'Закон'
Даже если мы и не знаем точно, что из себя представляют еврейские законы, мы знаем, что они были разработаны мудрыми раввинами, и что раввинатская сис...полностью>>
'Кодекс'
Об утверждении Правил предоставления, приостановки и ограничения предоставления коммунальных услуг собственникам и пользователям помещений в многоква...полностью>>
'Документ'
Экспериментальные устройства оказывают существенное влияние на физические и эксплуатационные характеристики исследовательских реакторов, а также пара...полностью>>
'Методичні рекомендації'
Економічна освіта, її якість та результати – академічні, професійні та життєві – сьогодні є ключовими пунктами розвитку суспільства не тільки в Украї...полностью>>

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

Главная > Книга
Сохрани ссылку в одной из сетей:

Q:Можно ли увидеть карту всего Internet, связи, каналы, структура? Сергей Иванов

С "высоты птичьего полета" карту Интернет можно изобразить прямой линией с множеством нанесенных на нее IP адресов, так, чтобы каждый IP-адрес был связан со всеми остальными (см. рис. 10)

Рисунок 10 Рис. 0x014 – Схематическое изображение карты Интернет

Подлетев поближе, мы увидим, что IP-адреса группируются в "стаи", на техническом языке именуемые сетями, а самих сетей существует бесчисленное множество. Члены одной сети, как правило, обслуживаются одним "вожаком", то бишь одним поставщиком сетевых услуг и очень прытко спариваются друг с другом – гораздо легче и быстрее, чем с членами чужих сетей. С другой стороны – если вожак скинет копыта (провайдер зависнет) – парализуется работа всей стаи.

Определить принадлежность узла к той или иной подсети можно по его IP-адресу. Существует несколько различных типов сетей, отличающихся друг от друга максимально возможным количеством входящих в них узлов, – от сетей-малюток в пару сотен абонентов до гигантских мегаполисов из десятков миллионов узлов. Чем же вызвана такая вопиющая несправедливость?

Камень преткновения в ограниченной разрядности IP-адреса – при всем желании в жалкие 32 бита нельзя втиснуть больше, чем четыре миллиарда постоянных узлов. Учитывая все ускоряющие темпы роста Интернет – это совсем немного!

Если откинуть немногочисленные клинические случаи (оговоренные ниже), всякий IP-адрес состоит, по меньшей мере, из адреса сети и адреса узла в этой сети. Адрес сети занимает от одного до трех октетов (октет – это восьмерка бит, в общепринятой нотации представленная десятичным числом от 0 до 255 и отделенная от другого октета символом точки). Из-за переменной длины определить принадлежат ли два IP-адреса одной или различным сетям не так-то просто! Поэтому, ниже приведена таблица 2, облегчающая решение этой задачи.

Диапазон IP адресов

Класс сети

Макс. кол-во узлов сети

Макс. кол-во сетей

001.ххх.ххх.ххх - 126.ххх.ххх.ххх

А

16.777.214

126

128.000.ххх.ххх – 191.255.ххх.ххх

B

65.534

16.382

192.000.000.ххх – 223.255.255.ххх

С

254

2.097.150

Таблица 2 Классификация сетей Интернет

Попробуем это таблицей воспользоваться. Например, есть у нас два адреса: 119.013.200.01 и 119.014.22.221 – так, смотрим, старший, т.е. первый слева октет, – 119 – входит в диапазон 1 – 126 и, следовательно, указывает на сеть класса А. Три остальных октета задают адрес узла в этой сети. Таким образом, оба IP-адреса принадлежат одной сети – 119.000.000.000.

Другой пример: возьмем адреса 191.222.067.129 и 191.221.067.129. Так-с, первый октет – 191 – явно не входит в интервал 1 – 126 и не принадлежит сети класса А, но принадлежит сети класса B. Адрес сети класса B задается двумя октетами, следовательно, второй октет слева – это продолжение адреса сети. Но у наших IP-адресов вторые слева октеты разные – 222 против 221. Выходит, эти узлы принадлежат различным сетям.

Чтобы построить карту Интернет остается только разобраться как соединяются узлы одной сети и как сами сети взаимодействуют друг с другом.

При модемном соединении с провайдером все абоненты соединяются друг с другом и с внешним миром через специальный выделенный сервер (см. рис. 11.1). Для локальных Ethernet сетей более характерно "параллельное" подсоединение – с внешним миром узлы общаются через специальный сервер, а друг с другом – напрямую без посредников. Разумеется, это упрощенная модель: сети могут делиться на подсети, связанные между собой маршрутизаторами, а каждый узел локальной сети может принимать входящие звонки с одного или нескольких модемов. Таким образом, схема функционирования типичного провайдера сильно отличается от идеализированных моделей и ближе к рис. 11.2.

Рис 0x015 Типичная схема подключения к провайдеру, Рис 0x016 Типичная локальная Ethernet-сеть

Рисунок 11 Рис 0x017. Комбинированная модель

Сами сети в свою очередь так же соединены меж собой некоторым образом, причем, не всегда напрямую, а зачастую через длинную цепочку промежуточных сетей. Самое интересное, маршрут путешествия пакетов от одной сети к другой в большинстве случаев не единственный и не постоянный. Точно так, из Москвы в Ленинград можно отправиться и на самолете, и на поезде, и на легковой машине, и… да мало ли еще на чем! Аналогично: при соединении с сайтом , случается, что один пакет направляется по трансатлантическому кабелю, другой – из-за перегрузки маршрутизатора – идет через спутник, а третий доставляется совсем иным путем.

Разумеется, это возможно только в тех случаях, когда сети соединены друг с другом множественным образом, иначе – путь только один, равно как из таежной деревни Большие Грибы в Москву можно добраться лишь одним путем – сначала на санях до вокзала, а оттуда поездом до точки назначения с кучей пересадок. И никаких вам ни самолетов, ни вертолетов, ни спутников…

??? Рисунок "карикатура" – обыграть предыдущий абзац

Чтобы построить любую карту, не обязательно именно Интернет, необходимо отправиться в путешествие в процессе которого наносить на бумагу свой маршрут с указанием географических (или Интернет) координат. В Интернете координатами служат IP-адреса, ну а в роли картографа выступает утилита tracert из штатной поставки Windows, скрупулезно отмечающая все промежуточные узлы, посещенные пакетом. Остается только выбрать маршрут путешествия. Куда бы нам направится? Давайте посетим сайт провайдера . Итак, набираем в "Сеансе MS-DOS" "tracert.exe www.aha.ru" и ждем-с. Маршрут путешествия автора, пользующегося услугами првайдера krinel, выглядел так:

Трассировка маршрута к [195.2.70.38]

1 831 ms 871 ms * [195.161.42.210]

2 801 ms 771 ms 801 ms [195.161.42.222]

3 841 ms 831 ms 821 ms 195.161.241.1

4 841 ms 831 ms 851 ms 195.161.241.226

5 831 ms 802 ms 841 ms 217.106.16.49

6 811 ms 811 ms 891 ms 217.106.17.69

7 842 ms 811 ms 861 ms [213.24.141.185]

8 891 ms * 861 ms [195.161.0.2]

9 1061 ms 751 ms 831 ms [195.161.161.158]

10 932 ms 811 ms 871 ms [195.2.89.13]

11 1001 ms 851 ms 842 ms [213.189.198.22

22 942 ms 871 ms 931 ms [195.2.70.38]

О чем этот протокол говорит? Сначала пакеты попадают на "сортировочный пункт" – маршрутизатор с IP-адресом 195.161.42.210. Обратившись к таблице 2, выясняем, что это сеть класса "С", следовательно, адрес сети задается тремя старшими октетами и выглядит так: 195.161.42.0. Затем пакеты направляются на "сборочный пункт" – , судя по адресу сети, принадлежащий все тому же провайдеру, а затем – в другую сеть 195.161.241.0, затем вновь в другую и, наконец, добираются до крупного провайдера RosTelecom, который и является провайдером провайдера krintel. Погуляв немного по серверам Ростелеком-а, пакетики, наконец, устремляются в локальную сеть провайера zenon – того, что владеет сервером …

Таким образом, первая линия на карте Интернет проведена. Попробуем теперь другой маршрут – исследуем траекторию путешествия пакетов к серверу NASA, расположенного в далекой Америке.

Трассировка маршрута к foundation.hq.nasa.gov [198.116.142.34]

1 781 ms 982 ms 991 ms [195.161.42.210]

2 831 ms 912 ms 901 ms [195.161.42.222]

3 971 ms 832 ms 861 ms 195.161.241.1

4 841 ms 851 ms 841 ms 195.161.241.226

5 841 ms 861 ms 852 ms 217.106.16.49

6 862 ms 861 ms 831 ms [217.106.17.25]

7 851 ms * 861 ms [213.24.141.185]

8 * 882 ms 821 ms [195.161.0.2]

9 1052 ms 1031 ms 1112 ms [206.24.206.65]

10 1081 ms 1062 ms 1101 ms [206.24.194.62]

11 1062 ms * 1112 ms [204.70.9.139]

12 1111 ms 1162 ms 1061 ms [204.70.4.105]

13 1042 ms 1161 ms 1072 ms cable- [204.70.1.18]

14 1081 ms 1102 ms 1232 ms mae-east.nsn.nasa.gov [192.41.177.125]

15 1132 ms 1121 ms 1152 ms 128.161.3.14

16 1231 ms 1242 ms 1312 ms 128.161.1.62

17 1372 ms 1602 ms 1392 ms border.hcn.hq.nasa.gov [198.116.63.34]

Ага, оказывается, начальная часть маршрута совпадает – куда бы мы ни шли, мы все равно попадаем в Ростелеком, на базовый перевалочный путь, т.е. ту железнодорожную станцию Больших Грибов, куда приходится добиться на санях.

Впрочем, не всегда одними и тем же путями – в прошлый раз пакет направлялся на Московский сервер Ростелеком, а сейчас – на Ростовский! Но в целом путь всех пакетов идентичен – жирным шрифтом выделены совпадающие в обоих случаях точки маршрута.

Продолжая действовать в том же духе, поочередно соединясь с различными сетями, в некотором (весьма отдаленном) будущем мы сумеем построить если карту не всего Интернет, то, по крайней мере, некоторой его части. Нельзя ли как-нибудь автоматизировать этот процесс? Увы, нет…

Так надо ли этим заниматься? В общем-то, нет, но знать каким именно образом ваш провайдер соединен с внешним миром и кто провйдер првайдера под час очень полезно. Проследим маршрут пакетов к серверу , подключившись к другому провайдеру – itech.

Трассировка маршрута к [195.2.70.38]

1 140 ms 130 ms 140 ms [195.151.210.36]

2 151 ms 140 ms 150 ms [195.151.210.33]

3 171 ms 160 ms 170 ms [195.151.210.29]

4 161 ms 160 ms 180 ms 195.151.200.90

5 260 ms 231 ms 300 ms [195.151.52.41]

6 391 ms 340 ms 371 ms [194.84.251.246]

7 340 ms 451 ms 410 ms [193.232.88.23]

8 360 ms 501 ms 330 ms [193.232.244.48]

9 821 ms 901 ms 2164 ms [213.189.198.25]

10 441 ms 320 ms 341 ms [195.2.70.38]

Заметно, что теперь пакеты доходят втрое быстрее (320 ms задержки против 870) к тому же маршрут вдвое короче, а сам провайдер пользуется услугами Sprint-а, а не Ростелекома. Но самое интересное посмотреть каким образом идут пакты от провайдера itech к провайдеру krintel. Самих провайдеров физически разделяет каких-то двадцать километров, поэтому, думается, маршрут пакетов будет очень коротким…

Трассировка маршрута к [195.161.42.222]

1 * 2984 ms * [195.151.210.36]

2 2895 ms 1051 ms 180 ms [195.151.210.33]

3 220 ms 491 ms 180 ms [195.151.210.29]

4 240 ms 261 ms 220 ms 195.151.200.90

5 621 ms 1162 ms 1872 ms [195.151.52.41]

6 * * * Превышен интервал ожидания для запроса.

7 451 ms 450 ms 311 ms [193.232.88.20]

8 360 ms 501 ms 360 ms P [193.232.90.5]

9 1142 ms 521 ms * [193.251.248.41]

10 511 ms 611 ms 490 ms [193.251.150.241]

11 631 ms 441 ms 390 ms [193.251.150.33]

12 391 ms 561 ms 430 ms [193.251.154.185]

13 421 ms 540 ms 491 ms [193.251.154.114]

14 501 ms 430 ms 411 ms 195.66.225.48

15 1953 ms 1863 ms 2603 ms [193.45.0.129]

16 741 ms 431 ms 441 ms [193.45.129.37]

17 610 ms 491 ms 591 ms [193.45.129.4]

18 500 ms 381 ms 461 ms [193.45.36.202]

19 2925 ms 811 ms 641 ms [195.161.0.7]

20 431 ms 721 ms 441 ms [213.24.141.186]

21 420 ms 441 ms 451 ms [217.106.17.2]

22 751 ms 411 ms 521 ms 217.106.16.50

23 470 ms 421 ms 471 ms 195.161.241.227

24 531 ms 601 ms 550 ms [195.161.42.222]

О-го-го! Двадцать четыре перехода, с заходом в Санкт-Петербург, Стокгольм, Лондон, Москву, Краснодар, Ростов... Вот это "короткая" дорога! Дважды обогнуть Землю, чтобы попасть в исходную точку!

Зная, как провайдер соединен с внешним миром, с другими странами и провайдерами, можно не задумываясь распознавать самый быстрый из нескольких зеркальных серверов, причем осмысленно, а не методом тыка!

Например, входя в сеть через провайдера krintel бессмысленно пользоваться web и ftp Proxy-серверами провайдера itech – это только замедлит соединение. Напротив, зная, что у krintel-а связь с Америкой препаршивейшая, а с Японией даже быстрее, чем по России – имеет смысл найти бесплатный японский Proxy и через него скачивать с сайта любимой фирмы новую beta-версию всем известного браузера.

Q: Что такое ping и для чего он нужен?

Ping – эта такая утилита для проверки работоспособности сети. Принцип ее работы в общих чертах заключается в посылке узлу эхо – запроса и ожидании от него эха – ответа. Каждый узел сети Интернет должен уметь принимать эхо – запросы и возвращать эхо – ответы, разумеется, если он подсоединен к сети и работает.

Отсутствие эхо – ответа от сервера обозначает либо сервер "висит", либо имеется неустранимое повреждение сети на участке клиент – сервер, обойти в "обход" которое невозможно.

??? Рисунок "карикатура" Чел. кричит в бассейн || горы "ау! Есть тут кто живой!" и приложив руку к уху ждет ответа. А ему в ответ "да нет тут никого!"

Это свойство делает ping удобным инструментом проверки работоспособности узла и целостности соединения. Впрочем, отрицательный результат работы ping не всегда свидетельствует о наличии какой-либо проблемы (см. "Почему ping не проходит, а сайт сервера нормально работает и открывается?").

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

Почему ping не проходит, а сайт сервера нормально работает и открывается?

Q: Где я могу достать ping?

В штатный комплект поставки Windows входит консольная версия утилиты ping, вполне удовлетворяющая запросы непритязательного пользователя. Ping в графическом исполнении можно обнаружить в составе практически любого пакета сетевых утилит (NetInfo, CyberKit и т.д.)

Комплект разработчика Windows-приложений (SDK), входящий в частности в поставку компилятора Microsoft Visual Studio, содержит исходные тексты программы ping с достаточно подробными комментариями, что легко позволяет адоптировать ее к собственным нуждам и перекроить под собственный вкус.

Q: Каково назначение ключей утилиты ping?

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

Ключ w используется для задания интервала ожидания эхо – ответа в миллисекундах (по умолчанию 20 секунд). Если отклик от сервера не будет получен в течение указанного времени, утилита ping сообщит "Превышен интервал ожидания для запроса", намекая на неработоспособность сервера или повреждение сети. На загруженных каналах медленных провайдеров ответ может прийти и через 30, и даже через 60 секунд, поэтому, интервал ожидания приходится увеличивать, например, так:

C:\>ping www.nastyhost.fu

Обмен пакетами с www.nastyhost.fu [195.2.70.38] по 32 байт:

Превышен интервал ожидания для запроса.

Превышен интервал ожидания для запроса.

Превышен интервал ожидания для запроса.

Превышен интервал ожидания для запроса.

Статистика Ping для 195.2.70.38:

Пакетов: отправлено = 4, получено = 0, потеряно = 4 (100% потерь),

Приблизительное время передачи и приема:

наименьшее = 0мс, наибольшее = 0мс, среднее = 0мс

C:\>ping www.nastyhost.fu -w 60000

Обмен пакетами с www.nastyhost.fu [195.2.70.38] по 32 байт:

Ответ от 195.2.70.38: число байт=32 время=34100мс TTL=117

Ответ от 195.2.70.38: число байт=32 время=38310мс TTL=117

Ответ от 195.2.70.38: число байт=32 время=39001мс TTL=117

Ответ от 195.2.70.38: число байт=32 время=10220мс TTL=117

Статистика Ping для 195.2.70.38:

Пакетов: отправлено = 4, получено = 4, потеряно = 0 (0% потерь),

Приблизительное время передачи и приема:

наименьшее = 10220мс, наибольшее = 39001мс, среднее = 30408мс

Ключ n задает количество отправляемых эхо – запросов (по умолчанию 4). Увеличение количества запросов бывает необходимо для контроля надежности и устойчивости работы сервера. Чем выше качество канала, тем меньше разброс по времени ответов.

Ключ t заставляет утилиту ping посылать запросы в бесконечном цикле до ее прерывания нажатием комбинации клавиш <Ctrl-C>. Внимание: <Ctrl-Break> не прерывает процесс, а выводит текущую статистику! Этот ключ очень удобен для ожидания момента пробуждения некстати зависшего сервера – запустил "ping www.hover-server.fu -t" и жди появления сообщения "Host Alive" или что-то в этом роде.

Ключ l задает размер дейтаграммы без учета длины заголовка (28 байт), посылаемой в эхо – запросе. Допустимыми являются значения от 0 до 65.500 включительно. По умолчанию размер дейтаграммы составляет 32 байта. Манипулируя этим значением можно выяснить зависимость скорость доставки – размер дейтаграммы. Если размер дейтаграммы превысит некоторую критическую величину (определяемую каждым промежуточным узлом самостоятельно), дейтаграмма разрезается на несколько пакетов подходящего размера, каждый из которых добирается до конечной точки маршрута самостоятельно, а на узле назначения они вновь собираются в исходную дейтаграмму.

Ключ f устанавливает на дейтаграмме специальную пометку, запрещающую ее разрезание (то есть, говоря техническим языком, фрагментацию). Если хотя бы один из промежуточных узлов не может обрабатывать пакеты таких размеров, он прибивает дейтаграмму и посылает отправителю уведомление, объясняя причину смерти тем, что требуется фрагментация, но установлена пометка, ее запрещающая. Впрочем, некоторые узлы не посылают такого уведомления, молчаливо отправляя пакет на тот свет или же разрезают дейтаграмму вопреки запрету (впрочем, последнее встречается редко). Вкупе с ключом –l, задающим длину дейтаграммы, запрет фрагментации ключом –f, позволяет определить максимальный размер не фрагментируемых пакетов. (см. "Оптимизация соединения с Интернет" и "Описание утилиты MTUSpeed").

Ключ i задает время жизни (сокращенно TTLTime To Live) пакета посылаемых дейтаграмм, измеряемое количеством узлов, которые может посетить пакет (по умолчанию 128). Каждый промежуточный узел уменьшает значение TTL на единицу и когда оно достигает нуля, пакет уничтожается с посылкой отправителю соответствующего уведомления. Это обстоятельство позволяет отслеживать маршрут путешествия пакетов, используя ping вместо утилиты tracert, что будет нелишним в тех ситуациях, когда tracert нет под рукой. (см. "Как определить полный путь (прохождение) при скачивании файла").

Для контроля выясним маршрут к некоторому узлу с помощью tracert, входящей в штатную поставку Windows:

Трассировка маршрута к [194.67.18.8]

с максимальным числом прыжков 30:

C:\>tracert

1 150 ms 130 ms 131 ms [195.151.210.36]

2 140 ms 141 ms 150 ms [195.151.210.33]

3 221 ms 180 ms 220 ms [195.151.210.29]

4 310 ms 401 ms 330 ms 195.151.200.90

5 300 ms 341 ms 270 ms [195.151.52.41]

А теперь вызовем ping, задав значение TTL равное одному. Первый же маршрутизатор, уменьшив его на единицу, обнаружит, что оно равно нулю и пошлет нам соответствующее уведомление. Итак…

C:\>ping -i 1

Обмен пакетами с [194.67.18.8] по 32 байт:

Ответ от 195.151.210.36: Превышен срок жизни (TTL) при передаче пакета.

И в самом деле, получен ответ от узла 195.151.210.36 – первого маршрутизатора в цепочке, как это видно по протоколу работы tracert.

Теперь увеличим значение TTL до двух и повторим процедуру:

C:\>ping -i 2

Обмен пакетами с [194.67.18.8] по 32 байт:

Ответ от 195.151.210.33: Превышен срок жизни (TTL) при передаче пакета.

Действительно, теперь найдет второй маршрутизатор в цепочке! Увеличиваем значение TTL еще на единицу…

C:\>ping -i 3

Обмен пакетами с [194.67.18.8] по 32 байт:

Ответ от 195.151.210.29: Превышен срок жизни (TTL) при передаче пакета.

В самом деле, этот прием работает! Правда, уж очень утомительно перебирать пакеты вручную. Но работу легко оптимизировать командным файлом следующего содержания {>>>> сноска Работает только под Windows 2000 или выше} FOR /L (%%I) IN (1,1,30) DO ping %1 -i %%I, вызываемого с аргументом – доменным именем или IP-адресом трассируемого узла, и он самостоятельно начнет перебирать все значения TTL от 1 до 30.

Ключ v задает значения поля типа службы (TOS - Type Of Service). Тип сервиса с помощью некоторых абстрактных параметров указывает предпочтительный вид обслуживания – минимальная задержка, максимальная пропускная способность, максимальная надежность, минимальные издержки на пересылку или обычная, неприоритетная, пересылка. Предпочтение может быть отдано только одному типу приоритета – нельзя одновременно требовать молниеносной скорости пересылки пакета в купе с соломоновой надежностью его доставки. Выбирайте уж что-то одно!

Тип сервиса задается одним из следующих десятичных чисел (См. таблицу 3). Как легко видеть, каждому значению соответствует свой бит:

Код сервиса

Пояснение

2

минимальные издержки на пересылку

4

максимальная надежность доставки

8

максимальная пропускная способность

16

минимальная задержка

Таблица 3. Допустимые типы сервиса в поле TOS

Не все маршрутизаторы анализируют поле TOS, - многие из них его напрочь игнорируют, что и подтверждает следующий эксперимент.

C:\>ping -v 0x2

Обмен пакетами с [195.151.210.34] по 32 байт:

Ответ от 195.151.210.34: число байт=32 время=130мс TTL=254

C:\>ping -v 0x4 -n 1

Обмен пакетами с [195.151.210.34] по 32 байт:

Ответ от 195.151.210.34: число байт=32 время=130мс TTL=254

C:\>ping -v 0x8 -n 1

Обмен пакетами с [195.151.210.34] по 32 байт:

Ответ от 195.151.210.34: число байт=32 время=130мс TTL=254

C:\>ping -v 16

Обмен пакетами с [195.151.210.34] по 32 байт:

Ответ от 195.151.210.34: число байт=32 время=130мс TTL=254

Независимо от типа сервиса время отклика всегда составляло ровно 130 мс, и быстроты пересылки при TOS равном 16 не наблюдалось. А вот пример сети, поддерживающей TOS.

C:\>ping -v 2

Обмен пакетами с [195.161.42.218] по 32 байт:

Ответ от 195.161.42.218: число байт=32 время=2143мс TTL=127

C:\>ping -w 10000 -v 4

Обмен пакетами с [195.161.42.218] по 32 байт:

Ответ от 195.161.42.218: число байт=32 время=1763мс TTL=127

C:\>ping -v 8

Обмен пакетами с [195.161.42.218] по 32 байт:

Превышен интервал ожидания для запроса.

Ответ от 195.161.42.218: число байт=32 время=1332мс TTL=127

C:\>ping -v 16

Обмен пакетами с [195.161.42.218] по 32 байт:

Ответ от 195.161.42.218: число байт=32 время=1092мс TTL=127

Наибольшая задержка наблюдалась при TOS равном 2 (минимальные издержки на пересылку), а наименьшая – при TOS равным 16 (минимальная задержка), и чуть менее быстрой оказались посылки с TOS равным 8.

Какую пользу из этого можно извлечь? А вот какую – прикладные программы могут манипулировать полем TOS по своему усмотрению, выбирая значение, соответствующее специфике своей работы. Например, telnet-клиенты, ICQ и чаты очень чувствительны к задержкам, ftp клиентам задержки не страшны – была бы хорошей пропускная способность, и т.д. Разумеется, если промежуточные узлы игнорируют содержимое поля TOS, никакого выигрыша не получается и высокоприоритетные пакеты (например, от ICQ) обрабатываются с той же скоростью, что и пакеты, скажем, от почтового сервера, не критичные к скорости доставки. Использование ping с ключом –v позволяет выяснить поддерживается ли TOS на данном маршруте и если имеется несколько альтернативных маршрутов – выбрать из них наиболее подходящий {>>>>> сноска К слову сказать, далеко не все приложения устанавливают поле TOS в соответствующее значение, оставляя его по умолчанию}

Ключ r заставляет промежуточные узлы записывать в заголовок отправляемых эхо – запросов свои IP-адреса (см. "Можно ли обойти защиту от трассировки?"). Не все маршртузаторы поддерживают такую возможность, но очень многие. Ping, вызванная с ключом –r, позволяет отслеживать маршрут пересылки пакетов и могла бы полностью заменить собой утилиту tracert (см. "Как определить полный путь (прохождение) при скачивании файла") если бы не ограничения, налагаемые размером IP-заголовка на максимальное количество запоминаемых адресов, – их умещается всего девять, и более длинные пути отслеживать этим способом невозможно.

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

На количество запоминаемых временных меток наложены те же самые ограничения, что и на количество запоминаемых IP-адресов, за одним небольшим исключением – временная метка, вставленная неизвестно каким маршрутизатором, бесполезна (разве что маршрут путешествия пакетов заведомо не меняется с течением времени и может быть предварительно выявлен трассировкой). По умолчанию утилита ping автоматически запоминает IP-адреса узлов при записи временных меток – таких пар в заголовок пакета может вместиться только четыре.

Временная метка выгодно отличается тем, что позволяет вычислять точную скорость пересылки пакета, поскольку содержит в себе не общий интервал задержки (от пересылки в оба конца), а время пересылки на заданный узел. По непонятным причинам штатная (да и большинство остальных) реализация утилиты ping не позволяет задавать запись временной метки для произвольного узла в цепочке (хотя, в принципе это возможно), чем полностью обесценивает ключ –s, ну, право же, редкий сервер отделен от клиента менее чем четырьмя промежуточными узлами!

Пример вызова ping с ключом –s приведен ниже. Обратите внимание на временную метку – похоже она представляет собой ни что иное, как случайное число.

C:\>ping -s 2

Обмен пакетами с [195.151.210.34] по 32 байт:

Ответ от 195.151.210.34: число байт=32 время=151мс TTL=254

Штамп времени: 195.151.210.36 : 3658968578 ->

195.151.210.34 : 2275040770

Ответ от 195.151.210.34: число байт=32 время=140мс TTL=254

Штамп времени: 195.151.210.36 : 3357240834 ->

195.151.210.34 : 1956535810

Ответ от 195.151.210.34: число байт=32 время=141мс TTL=254

Штамп времени: 195.151.210.36 : 3122621954 ->

195.151.210.34 : 1738694146

Ответ от 195.151.210.34: число байт=32 время=140мс TTL=254

Штамп времени: 195.151.210.36 : 2888003074 ->

195.151.210.34 : 1504075266

Статистика Ping для 195.151.210.34:

Пакетов: отправлено = 4, получено = 4, потеряно = 0 (0% потерь),

Приблизительное время передачи и приема:

наименьшее = 140мс, наибольшее = 151мс, среднее = 143мс

Ключ j задает список узлов для свободной маршрутизации от клиента и аналогичен одноименному ключу утилиты tracert (см. "Каково назначение ключей tracert?").

Ключ k похож на ключ –j, но задает список узлов для жесткой маршрутизации, т.е. пакет передается из рук в руки строго по перечню перечисленных узлов и ни один их них не может позволить себе воспользоваться услугами "собственного" маршрутизатора для передачи пакета следующему узлу. Если узел не может передать пакет напрямую, он уничтожает его и посылает отправителю соответствующее уведомление, дескать, такая маршрутизация от источника невозможна. Существует очень мало причин, требующих применения свободной, а тем более жесткой маршрутизации. Все это пережиток старых времен, – современные сети самостоятельно решают проблемы маршрутиазции пакетов и пытаться помочь им, право, не стоит – они и без того справляются со своей задачей слишком хорошо.

Ключ –-a задает определение имен узлов по их IP-адресам. Так, во всяком случае, сказано в документации. Смысл этого неясен – такое определение и без того происходит автоматически независимо от наличия (отсутствия) ключа "-a".

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

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

Провайдер и удаленный доступ  Описание утилиты MTUSpeed

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

Можно ли обойти защиту от трассировки?

Каково назначение ключей tracert?



Скачать документ

Похожие документы:

  1. Лондонской Школы Бизнеса, координатор организационного развития компании rcn, мастер-практик нлп. Наконец-то у нас есть книга

    Книга
    НЛП развивает ваш потенциал в достижении успехов,—создавая порядок из хаоса. Порядок, который может изменяться и развиваться в гармонии с потребностями персонала и бизнеса.
  2. Кино, театр, бессознательное

    Документ
    К 41 Кино, театр, бессознательное. Том 1. /Пер. с итальянского ННБФ "Онтопсихология". — М.: ННБФ "Онтопсихология", 2001. — 384 с., 11 илл.
  3. Введени е (1)

    Документ
    Полагаем, что желание открыть эту книгу возникло у Вас в связи с возникшим интересом к людям. Возможно, уделить время вопросам психодиагностики Вас сподвигли особенности профессиональной деятельности предполагающей изучение персонала
  4. Ответ на клевету под названием

    Реферат
    Хвала Аллаху, Которого мы восхваляем и к Которому взываем о помощи и прощении. Мы ищем защиты у Аллаха от зла наших душ и дурных дел. Кого Аллах ведет по прямому пути, того никто не сможет ввести в заблуждение.
  5. Вопрос Философия, ее предмет и функции. Взаимосвязь философии и частных наук

    Документ
    Философия (Пифагор автор слова фило — любовь, софи — мудрость). С точки зрения Аристотеля мудрость означает — знание общего в различных вещах, знание первопричин действительности, всеобщих свойств, всеобщих законов, всеобщих форм и

Другие похожие документы..