|
программа ping предназначена для проверки доступности удаленного хоста. программа посылает icmp эхо запрос на хост и ожидает возврата icmp эхо отклика. (на рисунке 6.3 приведен список типов icmp сообщений.) обычно, если вы не можете послать ping на хост, то не сможете получить доступ к этому хосту, используя telnet или ftp. с другой стороны, если вы не можете зайти на хост с помощью telnet, ping, как правило, начальная точка, с которой начинается идентификация проблемы. помимо этого, с помощью ping можно оценить время возврата пакета от хоста, что дает представление о том, "насколько далеко" находится хост. в этой главе мы воспользуемся программой ping в качестве диагностического средства, а также для дальнейшего рассмотрения icmp. кроме упомянутого выше, ping имеет опции записи маршрута и временной марки. раздел 11 [stevens 1990] содержит исходные тексты программы ping. раньше можно было считать верным утверждение, что если мы не можем послать ping на хост, то не сможем работать с хостом и с использованием telnet или ftp. в настоящее время это утверждение не является верным. связано это с тем, что в сети internet появились повышенные требования к секретности. маршрутизаторы поддерживают списки доступа, появились шлюзы, использующие технологию firewall. в настоящее время доступность хоста основывается не только на доступности ip уровня, а также от того, какой используется протокол и какой при этом работает порт. ping может показывать хост как недоступный, однако мы можем получить доступ через telnet на порт 25 (почтовый сервер). программа ping мы будем называть программу ping, которая посылает эхо запросы - клиент, а хост, на который посылаются эхо запросы - сервер. большинство реализаций tcp/ip поддерживают ping сервер непосредственно в ядре - сервер не является пользовательским процессом. (два сервиса, работающие с icmp запросами, которые мы описали в главе 6, маска адреса и запросы временной марки, также обрабатываются непосредственно в ядре.) на рисунке 7.1 показаны icmp эхо запрос и эхо отклик.
рисунок 7.1 формат icmp сообщения для эхо запроса и эхо отклика.
так же, как в случае других icmp запросов, в отклике сервера должены содержаться поля идентификатора (identifier) и номера последовательности (sequence number). кроме того, любые дополнительные данные, посланные клиентам, должны быть отражены эхом. реализации ping, присутствующие в unix, устанавливают в поле идентификатора icmp сообщения идентификатор процесса, отправляющего запрос. это позволяет программе ping идентифицировать вернувшийся ответ, если на одном и том же хосте в одно и то же время запущено несколько программ ping. номер последовательности начинается с 0 и увеличивается на единицу каждый раз когда посылается следующий эхо запрос. ping печатает номер последовательности каждого возвращенного пакета, позволяя нам увидеть, потерялся ли пакет, поменялась ли последовательность движения пакетов и был ли пакет продублирован. так как ip является ненадежным сервисом доставки датаграмм, любое из трех вышеперечисленных условий может появиться при работе программы ping. исторически сложилось так, что программа ping посылает эхо запрос один раз в секунду, печатая каждый эхо отклик в момент его возвращения. однако новые разработки требуют указания опции -s, чтобы программа работала подобным образом. по умолчанию новые реализации посылают только один эхо запрос и выдают сообщение "host is alive" (хост доступен), если эхо отклик получен, или "no answer" (не отвечает), если отклик не получен в течение 20 секунд. работа программы в локальных сетях вывод программы ping при работе в локальных сетях обычно выглядит следующим образом:
bsdi % ping svr4
когда принимается icmp эхо отклик, печатается номер последовательности, затем параметр время жизни (ttl) и рассчитанное время возврата. (ttl это поле времени жизни в ip заголовке. в настоящее время программа ping в bsd печатает полученное ttl каждый раз, когда принимается эхо отклик - некоторые реализации этого не делают. мы рассмотрим использование ttl в главе 8 с программой traceroute.) как видно из примера, приведенного выше, эхо отклики возвращаются в том же порядке, в котором были отправлены (0, 1, 2 и так далее). ping может рассчитать время возврата, так как он сохраняет время, когда был отправлен эхо запрос, в разделе данных icmp сообщения. когда отклик возвращается, эти данные извлекаются и сравниваются с текущим временем. обратите внимание на то, что посылающая система, bsdi, во всех случаях рассчитала время возврата равное 0 мс. это объясняется тем, что программе доступен таймер с низким разрешением. система bsd/386 может использовать только таймер с дискретом 10 мс. (мы обсудим это более подробно в приложении в.) позже, с использованием вывода команды tcpdump, мы увидим, что в системах с часами с более высоким разрешением (sun) разница во времени между icmp эхо запросом и эхо откликом составляет примерно 4 мс. первая строка вывода содержит ip адрес хоста назначения, даже если было указано имя (svr4). это означает, что имя было преобразовано в ip адрес. мы рассмотрим процедуру преобразования и dns в главе 14. после запуска программы ping проходит несколько секунд, перед тем как появляется первая строка вывода с напечатанным ip адресом, это время необходимо dns, чтобы определить ip адрес, соответствующий имени хоста. на рисунке 7.2 показан вывод tcpdump для этого примера.
1 0.0
bsdi
> svr4: icmp: echo request
рисунок 7.2 вывод ping при работе в локальной сети.
время между отправкой эхо запроса и приемом эхо отклика составляет 3,7 мс. также мы видим, что эхо запросы посылаются с интервалом примерно в 1 секунду. часто бывает, что первое время возврата больше чем все остальные. это происходит в том случае, если аппаратный адрес назначения отсутствует в arp кэше отправителя. как мы помним из главы 4, отправка arp запроса и получение arp отклика может занять несколько миллисекунд, только после этого отправляется первый эхо запрос. это проиллюстрировано в следующем примере:
sun % arp -a
убедимся,
что arp кэш пуст
дополнительные 3 миллисекунды в первом rtt скорее всего потрачены на отправку arp запроса и получение отклика. этот пример был запущен на хосте sun, который имеет таймер с разрешением в одну микросекунду, но не смотря на это, программа ping печатает время возврата только с разрешением в одну миллисекунду. в предыдущем примере, запущенном под bsd/386 version 0.9.4, время возврата равно 0 миллисекунд, так как таймер имеет разрешение в 10 миллисекунд. следующий вывод получен с использованием bsd/386 version 1.0, где есть таймер с разрешением в одну микросекунду. существует версия программы ping, которая имеет более высокое временное разрешение.
bsdi % ping svr4
работа программы в глобальных сетях при работе в глобальных сетях результат может значительно отличаться. следующий пример был получен в рабочий день после полудня, время, когда internet обычно довольно загружен:
gemini % ping vangogh.cs.berkeley.edu
эхо запросы и эхо отклики с номерами последовательности 1, 2, 3, 4, 6, 10, 11, 12 и 13 были потеряны. также обратите внимание на значительную разницу между величинами времен возврата. (количество потерянных пакетов, а именно 52%, является ненормальным. это неприемлимо для internet даже в рабочие дни после полудня.) при работе в глобальных сетях можно встретиться с дублированием пакетов (один и тот же номер последовательности появляется дважды или несколько раз), также может возникнуть перемешивание номеров последовательности (номер последовательности n+1 появляется перед номером последовательности n). давайте рассмотрим время возврата при работе по slip каналам, так как они обычно работают в асинхронном режиме с низкими скоростями, например 9600 бит/сек или меньше. обратимся к расчету пропускной способности последовательной линии, приведенному в разделе "вычисление загруженности последовательной линии" главы 2. предположим, скорость slip канала между хостами bsdi и slip составляет 1200 бит/сек. оценить время возврата можно следующим образом. во-первых, обратимся к примеру вывода ping, показанному ранее. по умолчанию, icmp сообщение содержит 56 байт данных. а также, 20 байт ip заголовка и 8 байт icmp заголовка, что в сумме дает размер ip датаграммы - 84 байта. (мы можем проверить это, запустив tcpdump -e, с помощью этой опции можно посмотреть размеры ethernet фреймов.) из раздела "slip: ip по последовательной линии" главы 2 мы знаем, что в начало и в конец датаграммы добавляется по меньшей мере два дополнительных байта, а именно - байт end. не исключено, что при создании фреймов slip будут добавлены дополнительные байты, однако это зависит от величины каждого байта в датаграмме. предположим, что скорость составляет 1200 бит/сек, в байте 8 бит, один старт-бит и один стоп-бит, при этом скорость будет 120 байт/сек или 8,33 мс на один байт. время возврата составит (86 x 8,33 x 2) или 1433 мс. (здесь умножается на 2 потому, что мы рассчитываем время возврата - то есть время, за которое пакет ушел и вернулся.) следующий вывод должен подтвердить правильность наших вычислений:
svr4 % ping -s slip
(опция -s необходима для svr4, чтобы посылать один запрос каждую секунду.) время возврата составляет почти 1,5 секунды, однако программа все еще посылает icmp эхо запросы с интервалом в 1 секунду. это означает, что будет выдано два эхо запроса (в момент времени 0 и в момент времени 1), перед тем как вернется первый отклик (момент времени 1,480). именно поэтому программа считает, что один пакет потерян. в действительности он не был потерян, скорее всего он еще просто не вернулся. мы снова обратимся к медленному slip каналу в главе 8, когда будем рассматривать работу программы traceroute. slip каналы с дозвоном (dialup) при использовании slip каналов с дозвоном существуют некоторые отличия, так как на каждом конце канала присутствуют модемы. модемы, которые используются между системами netb и sun, предоставляют то, что называется модуляцией v.32 (9600 бит/сек), контроль ошибок v.42 (также иногда называемый lap-m) и сжатие данных v.42bis. это означает, что наши простые вычисления, которые были достаточно точны для выделенного канала, где известны все параметры, в таких условиях практически неверны. в данном случае играют роль несколько фактов. модемы вносят некоторую задержку. размер пакета может быть уменьшен благодаря сжатию данных, однако размер может быть и увеличен, так как используется протокол контроля ошибок. в дополнение, принимающий модем не может выдать полученные байты данных до тех пор, пока не будет проверена контрольная сумма. и в завершение, на каждом конце используется последовательный асинхронный интерфейс компьютера, а большинство операционных систем читают эти интерфейсы через определенный интервал времени или после того, как было получено определенное количество символов. в следующем примере мы послали ping на хост gemini с хоста sun.
sun % ping gemini
обратите внимание на то, что в первой строке rtt не кратен 10 миллисекундам, однако в остальных строках значение rtt кратно 10 миллисекундам. если запустить этот пример несколько раз, то можно заметить, что подобное поведение сохранится. (это вызвано точностью часов хоста sun - они предоставляют разрешение в одну миллисекунду. это было проверено тестами, которые приведены в приложении в.) также обратите внимание на то, что первый rtt больше чем следующие, а остальные уменьшаются в процессе работы команды и их диапазон находится между 280 и 300 мс. если не останавливать программу примерно минуту или две, rtt останутся в этом диапазоне, никогда не уменьшаясь меньше чем 260 мс. если рассчитать ожидаемый rtt для скорости 9600 бит/сек (упражнение 2 главы 7), величина составит 180 миллисекунд, таким образом мы ошиблись в расчете примерно в 1,5 раза от реального значения. если программа ping будет работать в течение 60 секунд, то среднее rtt при использовании v.42 и v.42bis составит 277 миллисекунд. (это лучше, чем значение, полученное в предыдущем примере, так как программа работала долше, при этом значение rtt застабилизировались в определенном диапазоне.) если выключить сжатие данных v.42bis, то среднее значение составит 330 миллисекунд. если выключить контроль ошибок v.42 (который также выключается при выключении сжатия данных v.42bis), среднее значение составит 300 миллисекунд. эти параметры модемов влияют на rtt, однако все же лучше использовать контроль ошибкок и сжатие данных. программа ping предоставляет возможность просмотреть ip опцию записи маршрута (rr). в большинстве версий программы ping присутствует опция -r, которая включает характеристику записи маршрута. при использовании этой опции ping устанавливает опцию ip записи маршрута (rr) в исходящих датаграммах (которые содержат icmp эхо запрос). при этом каждый маршрутизатор, который обрабатывает датаграмму, добавляет свой ip адрес в список, находящийся в дополнительном поле. когда датаграмма достигает конечного пункта назначения, список ip адресов копируется в исходящий icmp эхо отклик, а все маршрутизаторы на обратном пути также добавляют свои ip адреса в список. когда ping принимает эхо отклик, печатает список ip адресов. как бы просто это не звучало, в действительности, запись маршрута - достаточно сложный процесс. генерация ip опции rr хостом источником, обработка опции rr промежуточными маршрутизаторами и отражение входящего списка rr из icmp эхо запроса в исходящий icmp эхо отклик все это дополнительные и необязательные характеристики. большинство систем в настоящее время поддерживают эти дополнительные характеристики, однако некоторые системы не отображают список ip адресов. самая большая проблема, однако, заключается в ограниченном размере ip заголовка, в который должен поместиться список ip адресов. из рисунка 3.1 видно, что поле длины заголовка (header length) в ip заголовке составляет 4 бита, что ограничивает размер ip заголовка в пределах пятнадцати 32-битных слов (60 байт). так как фиксированный размер ip заголовка составляет 20 байт, а rr опция использует 3 байта для своей установки (что мы опишем ниже), то остается 37 байт (60-20-3) на список адресов, а это, в свою очередь, позволяет поместить туда до 9 ip адресов. на заре развития arpanet 9 ip адресов - было очень много, однако, в настоящее время, подобный размер существенно ограничивает работу команды ping с опцией -r. (в главе 8 мы рассмотрим программу traceroute, которая используется для отслеживания маршрута, по которому двигается датаграмма.) несмотря на все ограничения, опция записи маршрута работает и предоставляет возможность пронаблюдать, как обрабатываются опции ip. на рисунке 7.3 показан общий формат опции записи маршрута в ip датаграмме.
рисунок 7.3 общий формат опции маршрута в 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
на рисунке 7.4 показаны 4 пересылки, через которые проходит пакет (по две в каждом направлении), а также ip адреса добавляемые к списку rr при каждой пересылке.
рисунок 7.4 программа ping с опцией записи маршрутизации.
маршрутизатор bsdi добавляет в список разные ip адреса в зависимости от направления движения датаграммы. он всегда добавляет ip адрес исходящего интерфейса. однако, когда icmp эхо отклик достигает системы, которая инициировала запрос (svr4), она добавляет в список ip адрес входящего интерфейса. мы можем наблюдать за обменом пакетами с хоста sun, на котором запущена программа tcpdump с опцией -v (просмотр ip опций). на рисунке 7.5 показан вывод.
1 0.0
svr4>slip:
icmp: echo request (ttl 32, id 35835,
рисунок 7.5 вывод программы tcpdump c записью опций маршрутизации.
вывод optlen=40 указывает на то, что пространство опций в ip заголовке, используемое в данном случае, равно 40 байтам. (обратите внимание, длина ip заголовка должна быть кратна 4 байтам.) rr {39} означает, что включена опция записи маршрута, а длина ее поля составляет 39. затем приводится список из 9 ip адресов, знак (#) показывает на который из ip адресов указывает поле ptr в заголовке опции rr. так как мы наблюдали за пакетами с хоста sun (см. рисунок 7.4), то видели только icmp эхо запросы с пустым списком и icmp эхо отклики, в списке которых содержится 3 адреса. мы удалили оставшиеся строки в выводе tcpdump, так как они практически идентичны тем, которые показаны на рисунке 7.5. комбинация eol в конце записи маршрута указывает на ip опцию "конец списка" (end of list). опция eol имеет значение 0. в поле опций ip заголовка, состоящего из 40 байт присутствует 39 байт данных rr. так как пространство опций устанавливается в 0, перед тем как датаграмма отсылается, последний байт 0 следующий за 39-ю байтами данных rr интерпретируется как eol. если в поле опций ip заголовка присутствует несколько опций и появляется необходимость использовать байты заполнения перед началом следующей опции, используется специальный символ "нет операции" (nop - no operation), значение которого равно единице. на рисунке 7.5 svr4 устанавливает в поле ttl в эхо запросе значение 32, а bsd/386 устанавливает значение 255. (это значение печатается как 254, потому что маршрутизатор bsdi уже успел уменьшить это значение на единицу.) все новые системы устанавливают ttl icmp сообщений по максимуму (255). необходимо отметить, что две системы, bsd/386 и svr4, из трех tcp/ip реализаций, описываемых в качестве примера в этой книге, поддерживают опцию записи маршрута. таким образом, они корректно обновляют rr список при перенаправлении датаграммы. также они корректно отражают rr список из входящих icmp эхо запросов в исходящий icmp эхо отклик. sunos 4.1.3, однако, обновляет rr список, когда перенаправляет датаграмму, но не отображает rr список. solaris 2.x исправляет эту проблему.
ненормальный вывод следующий пример был рассмотрен автором и является исходной точкой для дальнейшего описания icmp сообщений о перенаправлении в главе 9. мы посылаем ping на хост aix, находящийся в подсети 140.252.1, с хоста slip (доступ осуществляется через slip соединение с дозвоном на компьютере sun) с опцией записи маршрута. при этом получаем следующий вывод:
slip % ping -r aix
мы могли бы запустить этот пример с хоста bsdi, но выбрали хост slip, чтобы увидеть все 9 ip адресов, которые появятся в списке rr. странность этого вывода заключается в том, что исходящая датаграмма (icmp эхо запрос) направляется непосредственно от netb к aix, а возвращается (icmp эхо отклик) от aix через маршрутизатор gateway, перед тем как попасть в netb. то что мы видим здесь, является характеристикой ip маршрутизации, которую мы опишем ниже. на рисунке 7.6 показан путь датаграммы.
рисунок 7.6 работа программы ping с записью маршрута, показывающая характеристику ip маршрутизации.
проблема заключается в том, что aix не знает как послать ip датаграмму, направляющуюся в подсеть 140.252.13 к netb. однако, aix имеет в своей таблице маршрутизации пункт по умолчанию, который сообщает о необходимости посылать все датаграммы на маршрутизатор gateway, если не существует конкретного маршрута к пункту назначения. маршрутизатор gateway знает значительно больше о существующих маршрутах, чем любой другой хост в подсети 140.252.1. (в этой сети ethernet присутствует более чем 150 хостов, и вместо того чтобы каждому иметь запущенный демон маршрутизации, они используют пункт "по умолчанию" (default), который указывает на маршрутизатор gateway.) вопрос, на который пока нет ответа, заключается в том, почему gateway не послал сообщение icmp о перенаправлении (глава 9, раздел "icmp ошибки перенаправления") на aix, чтобы обновить его таблицу маршрутизации? по некоторым причинам (возможно потому, что датаграмма, генерирующая перенаправление, является icmp эхо запросом) перенаправление не произошло. однако, если мы используем telnet и подключимся к серверу дневного времени на aix, icmp перенаправление произойдет, и таблица маршрутизации aix будет обновлена. если мы затем запустим ping со включенной опцией записи маршрута, маршрут покажет, что датаграммы идут от netb к aix и назад к netb без дополнительной пересылки через маршрутизатор gateway. мы рассмотрим сообщения icmp о перенаправлении более подробно в разделе "icmp ошибки перенаправления" главы 9. опция ip временной марки во многом напоминает опцию записи маршрута. на рисунке 7.7 показан формат ip опции временной марки (сравните с рисунком 7.3).
рисунок 7.7 общий формат опции временной марки в ip заголовке.
для опции временной марки поле кода (code) устанавливается в 0x44. два поля длина (len) и указатель (ptr) такие же как в опции записи маршрута: полная длина опции (обычно 36 или 40) и указатель на следующий доступный пункт (5, 9, 13 и так далее). размер двух следующих полей составляет 4 бита: of - поле переполнения (overflow) и fl - поле флагов (flags). функционирование опции временной марки определяется полем флагов (flags), как показано на рисунке 7.8.
рисунок 7.8 значение флагов в опции временной марки.
в случае если маршрутизатор не может добавить временную марку, из-за того что не хватает места, он увеличивает на единицу поле переполнения (overflow). обычное значение для временной марки это количество миллисекунд после полуночи, utc, что напоминает запрос и отклик временной марки icmp (глава 6, раздел "icmp запрос и отклик временной марки"). если маршрутизатор не поддерживает подобный стандарт, он может вставить то представление времени, которое он использует, однако затем он должен установить в единицу старшие биты временной марки, чтобы указать на нестандартный формат. заданные ограничения, которые мы рассматривали с опцией записи маршрута, с опцией временной марки становятся еще более жесткими. если осуществляется запись и ip адресов и временных марок (флаги установлены в единицу), то можно сохранить только 4 подобные пары. сохранение только временной марки практически бесполезно, потому что мы не имеем представления, какому маршрутизатору соответствует определенная временная марка (если только мы не имеет фиксированную топологию, которая никогда не изменяется). если установить флаги в значение 3, то появится возможность выбрать, каким маршрутизаторам необходимо вставлять их временные марки. более глобальная проблема заключается в том, что мы не можем контролировать то, насколько точно маршрутизаторы устанавливают временные марки. поэтому довольно сложно оценить время пересылки между маршрутизаторами с использованием этой ip опции. вскоре мы увидим, что программа traceroute (см. главу 8) предоставляет более совершенный способ оценки времени пересылки между маршрутизаторами. программа ping является основным тестирующим средством, которое позволяет определить наличие соединения между системами, использующими tcp/ip. она использует icmp эхо запрос и эхо отклик и не использует транспортные уровни (tcp или udp). ping сервер обычно является частью реализации ядра icmp. мы рассмотрели стандартный вывод команды ping для локальных, глобальных сетей и каналов slip (с дозвоном и выделенных), и рассчитали пропускную способность последовательных линий выделенных slip каналов. ping также позволяет использовать ip опцию записи маршрута. мы использовали эту ip опцию, чтобы посмотреть как используется маршрут по умолчанию. мы вернемся к этой теме в главе 9. также мы рассмотрели ip опцию временной марки, однако она имеет ограниченную практическую ценность.
|
