Используйте утилиту ping
| | |
Один из самых главных и полезных инструментов отладки сетей и работающих в них приложений - это утилита ping. Ее основное назначение - проверить наличие связи между двумя хостами.
Прежде необходимо разъяснить несколько моментов, касающихся ping. Во-первых, по словам Майка Муусса, слово «ping» не расшифровывается как «packet internet groper» (проводящий межсетевые пакеты). Своим названием эта программа обязана звуку, который издает сонар, устанавливаемый на подводных лодках. История создания программы ping изложена в статье «The Story of the Ping Program» Муусса на Web-странице http://ftp.arl.mil/-mike/ping/html. Там же приведен и ее исходный текст.
Во-вторых, эта утилита не использует ни TCP, ни UDP, поэтому для нее нет никакого хорошо известного порта. Для проверки наличия связи ping пользуется функцией эхо-контроля, имеющейся в протоколе ICMP. Помните (совет 14), что, хотя сообщения ICMP передаются в IP-датаграммах, ICMP считается не отдельным протоколом, а частью IP.
Примечание: В RFC 792 [Postel 1981] на первой странице сказано: «1СМР использует базовую поддержку IP, как если бы это был протокол более высокого уровня, однако в действительности ICMP является неотъемлемой частью IP и должен быть реализован в каждом IP-модуле».
Таким образом, структура пакета, посылаемого ping, имеет такой вид, как на рис. 4.1. Показанная на рис. 4.2 ICMP-часть сообщения состоит из восьмибайтного ICMP-заголовка и n байт дополнительной информации.
Рис. 4.1. Формат пакета ping
Обычно в качестве значения n- числа дополнительных байтов в пакете ping выбирается 56 (UNIX) или 32 (Windows), но эту величину можно изменить с помощью флагов -s (UNIX) или -l (Windows).
В некоторых версиях ping пользователь может задавать значения дополнительных данных или даже указывать, что они должны генерироваться псевдослучайным образом. По умолчанию в большинстве версий дополнительные данные циклически переставляемый по кругу набор байтов.
Примечание: Задание конкретных данных бывает полезно при отладке ошибок, зависящих от данных.
UNIX - версия ping помещает временной штамп (структуру timeval) в первые восемь байт дополнительных данных (при условии, конечно, что пользователь не задал меньшее количество). Когда программа ping получает эхо-ответ, она использует этот временной штамп для вычисления периода кругового обращения (RTT). Windows-версия ping этого не делает (вывод основан на анализе информации, полученной с помощью программы tcpdump), но в тексте примера ping, поставляемого в составе компилятора Visual C++, этот алгоритм присутствует.
Рис. 4.2. Пакет эхо – сообщения запрос/ответ протокола ICMP
Поскольку поля идентификатор и порядковый номер не задействованы ни в эхо-запросе, ни в эхо-ответе, ping использует их для идентификации полученных ICMP-ответов. Так как для IP-датаграмм нет специального порта, они доставляются каждому процессу, который открыл простой (raw) сокет с указанием протокола ICMP (совет 40). Поэтому ping помещает свой идентификатор процесса в поле идентификатор, так что каждый запущенный экземпляр способен отличить ответы на свои запросы. Таким образом, поле идентификатор в этом случае можно представить как аналог номера порта.
Таким же образом ping помещает в поле порядковый номер значение счетчика для того, чтобы связать ответ с запросом. Именно это значение ping показывает как icmp_seq.
Обычно первое ваше действие при пропадании связи с удаленным хостом - это запуск ping с указанием адреса этого хоста (хост «пингуется»). Предположим, что нужно связаться с хостом А с помощью программы telnet, но соединение не устанавливается из-за истечения тайм-аута. Причин может быть несколько: проблема в сети между двумя хостами, не работает сам хост А, проблема в удаленном стеке TCP/IP или не запущен сервер telnet.
Сначала следует проверить, «пингуя» хост А, что он достижим. Если работа ping Проходит нормально, то можно сказать, что с сетью все в порядке, а проблема, вероятно, связана с самим хостом А. Если же невозможно «достучаться» до хоста А с помощью ping, то требуется «пропинговать» ближайший маршрутизатор, чтобы понять, удается ли достичь хотя бы границы собственной сети. Если это получается, то воспользуйтесь программой traceroute (совет 35), чтобы выяснить, насколько далеко можно продвинуться по маршруту от вашего хоста к хосту А. Часто это помогает идентифицировать сбойный маршрутизатор или хотя бы сделать предположение о месте возникновения ошибки.
Поскольку ping работает на уровне протокола IP, она не зависит от правильности конфигурации TCP или UDP. Поэтому иногда полезно «пропинговать» свой собственный хост, чтобы проверить правильность установки сетевого программного обеспечения. Сначала можно указать ping возвратный адрес localhost (127.0.0.1), чтобы убедиться в работе хотя бы части сетевой поддержки. Если при этом проблем не возникает, то следует «пропинговать» один или несколько сетевых интерфейсов и удостовериться, что они правильно сконфигурированы.
Попробуйте «пропинговать» хост netcom4.netcom.com, который находится от вас в десяти переходах (рис. 4.3).
bsd: $ ping netcom4.netcom.com
PING netcom4.netcom.com (199.183.9.104): 56 data bytes
64 bytes from 199.183.9.104: icmp_seq=0 tt1=245 time=598.554 ms
64 bytes from 199.183.9.104: icmp_seq=1 tt1=245 time=550.081 ms
64 bytes from 199.183.9.104: icmp_seq=2 tt1=245 time=590.079 ms
64 bytes from 199.183.9.104: icmp_seq=3 tt1=245 time=530.114 ms
64 bytes from 199.183.9.104: icmp_seq=5 tt1=245 time=480.137 ms
64 bytes from 199.183.9.104: icmp_seq=6 tt1=245 time=540.081 ms
64 bytes from 199.183.9.104: icmp_seq=7 tt1=245 time=580.084 ms
64 bytes from 199.183.9.104: icmp_seq=8 tt1=245 time=490.078 ms
64 bytes from 199.183.9.104: icmp_seq=9 tt1=245 time=560.090 ms
64 bytes from 199.183.9.104: icmp_seq=10 tt1=245 time=490.090 ms
^C завершили ping вручную
- - - netcom4.netcom.com ping statistics - - -
12 packets transmitted, 10 packets received, 16% packet loss
round-trip min/avg/max/stddev = 480.137/540.939/598.554/40.871 ms
bsd: $
Рис. 4.З. Короткий прогон ping
Прежде всего, RTT для разных пакетов мало меняется и остается в пределах 500 мс. Как следует из последней строки, RTT модифицируется в диапазоне от 480,137 мс до 598,554 мс со стандартным отклонением 40,871 мс. Тест слишком рано прерван, чтобы можно было сделать какие-то выводы, но и при более длительном прогоне (около 2 мин) результат существенно не изменится. Так что можно предположить, что нагрузка на сеть постоянная. Значительный разброс RTT это, как правило, признак изменяющейся загрузки сети. При повышенной загрузке возрастает длина очереди в маршрутизаторе, а вместе с ней - и RTT. При уменьшении загрузки очередь сокращается, что приводит к уменьшению RTT.
Далее из рис. 4.3 видно, что на эхо-запрос ICMP с порядковым номером 4 не пришел ответ. Это означает, что запрос либо ответ был потерян одним из промежуточных маршрутизаторов. По данным сводной статистики, было послано 12 запросов (0-11) и получено лишь, 10 ответов. Один из пропавших ответов имеет порядковый номер 4, второй - 11 (вероятно, он был засчитан как пропавший, поскольку не вовремя прервана работа ping).
