Работа программы в глобальных сетях

При работе в глобальных сетях результат может значительно отличаться. Следующий пример был получен в рабочий день после полудня, время, когда Internet обычно довольно загружен:

 

ping vangogh.cs.berkeley.edu PING vangogh.cs.berkeley.edu: 56 data bytes 64 bytes from (128.32.130.2): icmp_seq=0. time=660. ms 64 bytes from (128.32.130.2): icmp_seq=5. time=1780. ms 64 bytes from (128.32.130.2): icmp_seq=7. time=380. ms 64 bytes from (128.32.130.2): icmp_seq=8. time=420. ms 64 bytes from (128.32.130.2): icmp_seq=9. time=390. ms 64 bytes from (128.32.130.2): icmp_seq=14. time=110. ms 64 bytes from (128.32.130.2): icmp_seq=15. time=170. ms 64 bytes from (128.32.130.2): icmp_seq=16. time=100. ms ^?                        вводим символ прерывания ---- vangogh.CS.Berkeley.EDU PING Statistics ---- 17 packets transmitted, 8 packets received, 52% packet loss round-trip (ms) min/avg/max = 100/501/1780

При работе в глобальных сетях можно встретиться с дублированием пакетов (один и тот же номер последовательности появляется дважды или несколько раз), также может возникнуть перемешивание номеров последовательности (номер последовательности N+1 появляется перед номером последовательности N).

Когда принимается ICMP эхо отклик, печатается номер последовательности, затем параметр время жизни (TTL) и рассчитанное время возврата. Как видно из примера, приведенного выше, эхо отклики возвращаются в том же порядке, в котором были отправлены (0, 1, 2 и так далее). Эхо запросы и эхо отклики с номерами последовательности 1, 2, 3, 4, 6, 10, 11, 12 и 13 были потеряны. ping может рассчитать время возврата, так как он сохраняет время, когда был отправлен эхо запрос, в разделе данных ICMP сообщения. Когда отклик возвращается, эти данные извлекаются и сравниваются с текущим временем.

Обратите внимание на значительную разницу между величинами времен возврата. (Количество потерянных пакетов, а именно 52%, является ненормальным. Это неприемлимо для Internet даже в рабочие дни после полудня.)

Первая строка вывода содержит IP адрес хоста назначения, даже если было указано имя (vangogh.cs.berkeley.edu). Это означает, что имя было преобразовано в IP адрес. После запуска программы ping проходит несколько секунд, перед тем как появляется первая строка вывода с напечатанным IP адресом, это время необходимо DNS, чтобы определить IP адрес, соответствующий имени хоста.

Опция записи ip маршрута

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

Как бы просто это не звучало, в действительности, запись маршрута - достаточно сложный процесс. Генерация IP опции RR хостом источником, обработка опции RR промежуточными маршрутизаторами и отражение входящего списка RR из ICMP эхо запроса в исходящий ICMP эхо отклик все это дополнительные и необязательные характеристики. Большинство систем в настоящее время поддерживают эти дополнительные характеристики, однако некоторые системы не отображают список IP адресов.

Самая большая проблема, однако, заключается в ограниченном размере IP заголовка, в который должен поместиться список IP адресов. Из рисунка видно, что поле длины заголовка (header length) в IP заголовке составляет 4 бита, что ограничивает размер IP заголовка в пределах пятнадцати 32-битных слов (60 байт). Так как фиксированный размер IP заголовка составляет 20 байт, а RR опция использует 3 байта для своей установки (что мы опишем ниже), то остается 37 байт (60-20-3) на список адресов, а это, в свою очередь, позволяет поместить туда до 9 IP адресов. На рисунке показан общий формат опции записи маршрута в IP датаграмме.

Рисунок 1. Общий формат опции маршрута в IP заголовке

 

Код (code) - однобайтовое поле, содержащее тип IP опции. Для опции RR установлено значение 7. Длина (len) - это полный размер в байтах опции RR, в данном случае 39. (Несмотря на то, что существует возможность указать опцию RR с размером меньше максимального, ping всегда предоставляет поле опции размером 39 байт, что позволяет записать до 9 IP адресов. Несмотря на то, что существует ограничение в размере опций в IP заголовке, оно, тем не менее, позволяет указать размер меньше максимального.)

Указатель (ptr) - это индекс в 39-байтной опции, который указывает на то, где хранится следующий IP адрес. Его минимальное значение 4, что указывает на первый IP адрес. Когда следующий IP адрес записывается в список, значение ptr меняется следующим образом: 8, 12, 16 и так до 36. После того как записан девятый адрес, ptr устанавливается в значение 40, указывая на то, что список полон. А теперь давайте зададим себе такой вопрос.

Когда маршрутизатор (который по определению имеет несколько интерфейсов) записывает свой IP адрес в список, какой IP адрес он записывает? Это должен быть адрес либо входящего интерфейса, либо исходящего. RFC 791 [Postel 1981a] указывает, что маршрутизатор записывает IP адрес исходящего интерфейса. Исходный хост, на примере ниже, (хост, запустивший ping) получает ICMP эхо отклик с включенной опцией RR, он вносит в список IP адрес своего входящего интерфейса.

Обычный пример

Давайте попробуем запустить программу ping с опцией RR. Мы запустили ping с хоста svr4 на хост slip. Промежуточный роутер (bsdi) обрабатывает датаграмму, следующий вывод будет получен от svr4:

 

svr4 % ping -R slip PING slip (140.252.13.65): 56 data bytes 64 bytes from 140.252.13.65: icmp_seq=0 ttl=254 time=280 ms RR: bsdi (140.252.13.66) slip (140.252.13.65) bsdi (140.252.13.35) svr4 (140.252.13.34) 64 bytes from 140.252.13.65: icmp_seq=1 ttl=254 time=280 ms (same route) 64 bytes from 140.252.13.65: icmp_seq=2 ttl=254 time=280 ms (same route) ^? --- slip ping statistics --- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max = 270/276/280 ms

 

На рисунке 2 показаны 4 пересылки, через которые проходит пакет (по две в каждом направлении), а также IP адреса добавляемые к списку RR при каждой пересылке.

Рисунок 2. Программа ping с опцией записи маршрутизации

 

Маршрутизатор bsdi добавляет в список разные IP адреса в зависимости от направления движения датаграммы. Он всегда добавляет IP адрес исходящего интерфейса. Однако, когда ICMP эхо отклик достигает системы, которая инициировала запрос (svr4), она добавляет в список IP адрес входящего интерфейса.

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

Программа Traceroute, написанная Van Jacobson, - отладочное средство, которое позволяет лучше понять устройство протоколов TCP/IP. Обычно две последовательные датаграммы отправленные от одного и того же источника к одному и тому же пункту назначения проходят по одному и тому же маршруту, однако гарантировать этого невозможно. Traceroute позволяет нам посмотреть маршрут, по которому двигаются IP датаграммы от одного хоста к другому. С помощью Tracert можно воспользоваться IP опцией маршрутизации от источника.

В предыдущей команде была уже рассмотрена опция трассировки маршрута. Зачем нужна отдельная программа?

Во-первых, исторически не все маршрутизаторы поддерживают опцию записи маршрута, из чего следует, что некоторые маршруты становятся неиспользуемыми. (Tracert не требует каких-либо специальных характеристик на промежуточных маршрутизаторах.)

Во-вторых, запись маршрута обычно осуществляется в одном направлении. Отправитель включает опцию, а получатель должен вставить все значения из принятого IP заголовка и каким-либо образом вернуть их отправителю. Большинство реализаций сервера Ping (функция ICMP эхо отклика, встроенная в ядро) отображают входящий RR список, однако при этом удваивается количество записанных IP адресов (путь туда и обратно), помимо этого существует еще несколько ограничений. (Tracert требует только того, чтобы на пункте назначения присутствовал работающий UDP модуль - никаких специальных серверных приложений не требуется.)

Третья и основная причина заключается в том, что размер, предоставляемый для опций в IP заголовке, недостаточен для того, чтобы обработать большинство маршрутов. В поле опций IP заголовка входит всего 9 IP адресов. Если во времена ARPANET этого хватало, на сегодняшний день этого слишком мало.

Формат команды:

tracert [-d] [-h максимальное число] [-j список Узлов] [-w интервал] host_name

Праметры:

-d	Без разрешения в имена узлов
-h	Максимальное число прыжков при поиске узла
-j	Свободный выбор маршрута по списку узлов.
-w	Интервал ожидания каждого ответа в миллисекундах.

Tracert использует ICMP и поле TTL в IP заголовке. Поле TTL (время жизни) это 8-битное поле, которое отправитель устанавливает в какое-либо значение. Рекомендуемое исходное значение указано в Assigned Numbers RFC и в настоящее время равно 64. Более старые системы устанавливают это значение в 15 или 32. На примерах работы программы Ping видно,что ICMP эхо отклики часто отправляются с TTL, установленным в максимальное значение - 255.

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

 С помощью поля TTL предотвращается зацикливание датаграммы в петлях маршрутизации. Например, если маршрутизатор вышел из строя или соединение между двумя маршрутизаторами потеряно, может потребоваться некоторое время (от нескольких секунд до нескольких минут), для того чтобы определить, что маршрут потерян и что его необходимо обойти. В это время существует вероятность, что датаграмма будет уничтожена в петле маршрутизации. Чтобы предотвратить потерю датаграммы, поле TTL устанавливается в максимальную величину.

Когда маршрутизатор получает IP датаграмму с TTL равным либо 0, либо 1, он не должен отправлять эту датаграмму дальше. (Хост приемник должен доставить подобную датаграмму в приложение, так как датаграмма не может быть смаршрутизировна. Как правило, системы не должны получать датаграммы с TTL равным 0.) Если такую датаграмму получает маршрутизатор, он уничтожает ее и посылает хосту, который ее отправил ICMP сообщение "время истекло" (time exceeded). Принцип работы Tracert заключается в том, что IP датаграмма, содержащая это ICMP сообщение, имеет в качестве адреса источника IP адрес маршрутизатора.

При работе Tracert на хост назначения отправляется IP датаграмма с TTL, установленным в единицу. Первый маршрутизатор, который должен обработать датаграмму, уничтожает ее (так как TTL равно 1) и отправляет ICMP сообщение об истечении времени (time exceeded). Таким образом, определяется первый маршрутизатор в маршруте. Затем Tracert отправляет датаграмму с TTL равным 2, что позволяет получить IP адрес второго маршрутизатора. Это продолжается до тех пор, пока датаграмма не достигнет хоста назначения. Однако, если датаграмма прибыла именно на хост назначения, он не уничтожит ее и не сгенерирует ICMP сообщение об истечении времени, так как датаграмма достигла своего конечного назначения. Как можно определить, что датаграмма достигла конечного пункта назначения?

В UDP датаграммах, которые посылает Tracert, устанавливается несуществующий номер UDP порта (больше чем 30000), что делает невозможным обработку этой датаграммы каким-либо приложением. Поэтому когда прибывает подобная датаграмма, UDP модуль хоста назначения генерирует ICMP сообщение "порт недоступен" (port unreachable). Все что необходимо в этом случае, Tracert это определить тип принятого ICMP сообщения - либо об истечении времени, либо о недоступности порта - именно таким образом мы узнаем, доставлена ли датаграмма в пункт назначения.

На рисунке 3 показано как отправляется запрос от sun к NIC. 

sun>tracertnic.ddn.miltraceroutetonic.ddn.mil(192.112.36.5), 30hopsmax, 40bytepackets1netb.tuc.noao.edu(140.252.1.183) 218ms 227ms 233ms2gateway.tuc.noao.edu(140.252.1.4) 233ms 229ms 204ms3butch.telcom.arizona.edu(140.252.104.2) 204ms 228ms 234ms4Gabby.Telcom.Arizona.EDU(128.196.128.1) 234ms 228ms 204ms5NSIgate.Telcom.Arizona.EDU(192.80.43.3) 233ms 228ms 234ms6JPL1.NSN.NASA.GOV(128.161.88.2) 234ms 590ms 262ms7JPL3.NSN.NASA.GOV(192.100.15.3) 238ms 223ms 234ms8GSFC3.NSN.NASA.GOV(128.161.3.33) 293ms 318ms 324ms9GSFC8.NSN.NASA.GOV(192.100.13.8) 294ms 318ms 294ms10SURA2.NSN.NASA.GOV(128.161.166.2) 323ms 319ms 294ms11nsn-FIX-pe.sura.net(192.80.214.253) 294ms 318ms 294ms12GSI.NSN.NASA.GOV(128.161.252.2) 293ms 318ms 324ms13NIC.DDN.MIL(192.112.36.5) 324ms 321ms 324ms

 

Рисунок 3. tracert от sun к nic.ddn.mil.

Когда датаграмма выходит из сети tuc.noao.edu, она попадает в сеть telcom.arizona.edu. Затем она попадает в сеть nsn.nasa.gov. Второе RTT для TTL равного 6 (590) почти в два раза больше, чем два другие RTT (234 и 262). Это показывает динамику IP маршрутизации. Подобное может произойти где-нибудь по пути от источника к маршрутизатору если какой-нибудь промежуточный маршрутизатор задержал датаграмму.

RTT для первой попытки с TTL равным 3 (204) меньше, чем RTT для первой попытки с TTL равной 2 (233). Так как каждое полученное RTT является полным временем прохода от посылающего хоста к маршрутизатору, это вполне объснимо.

Первая строка, без номера содержит имя и IP адрес пункта назначения и указывает на то, что величина TTL не может быть больше 30. Размер датаграммы установлен в 40 байт, из которых 20 байт отводится на IP заголовок, 8 байт на UDP заголовок и 12 байт на пользовательские данные. (В 12 байтах пользовательских данных содержится номер последовательности, который увеличивается на единицу при отправке каждой следующей датаграммы, копия исходящего TTL и время, когда датаграмма была отправлена.)

Следующие две строки вывода начинаются с TTL, после чего следует имя хоста или маршрутизатора и их IP адреса. Для каждого значения TTL отправляется 3 датаграммы. Для каждого возвращенного ICMP сообщения рассчитывается и печатается время возврата (round-trip). Если ответ не получен в течении пяти секунд на любую из трех датаграмм, печатается звездочка, после чего отправляется следующая датаграмма.