Утилита для проверки доступности узлов в сети средствами протокола ICMP. Как правило важен лишь сам факт активности узла, но при детальном анализе ответа и использовании опций командной строки можно использовать ping как механизм позволяющий детализировать или заменить traceroute, оценить скорость и качество взаимодействия с удалённым узлом или узнать причину недоступности.
>ping 127.0.0.1
Обмен пакетами с 127.0.0.1 по с 32 байт данных:
Ответ от 127.0.0.1: число байт=32 время<1мс TTL=128
Ответ от 127.0.0.1: число байт=32 время<1мс TTL=128
Ответ от 127.0.0.1: число байт=32 время<1мс TTL=128
Ответ от 127.0.0.1: число байт=32 время<1мс TTL=128
Статистика Ping для 127.0.0.1:
Пакетов: отправлено = 4, получено = 4, потеряно = 0
(0% потерь)
Приблизительное время приема-передачи в мс:
Минимальное = 0мсек, Максимальное = 0 мсек, Среднее = 0 мсек
Результат вывода команды содержит адрес ответившего устройства, размер переданного пакета, время ответа и значение поля TTL в ответе. Результат не обязательно должен содержать ответ от того узла доступность до которого проверяется, ответить может любой промежуточный узел если ситуация не позволяет переслать запрос по назначению. Также ответ или не ответ проверяемого узла не всегда может быть причиной ошибки в сети, существует вероятность административного запрета прохождения пакетов ICMP, хотя это и не принято, наоборот сетевые инженеры стараются максимально обеспечить прозрачность в работе протокола.
Единственной необходимой опцией при использовании утилиты является адрес проверяемого узла в виде доменного имени или IP адреса:
ping <адрес узла>
при этом в ОС Windows будет послано 4 пакета, после чего выведена статистика работы (см. вставку выше). В *nix средах, обычно, ping будет посылать запросы до тех пор пока его не прервут. Рассмотрим подробнее строчки ответов выводимые в результате 1.
Ответ
В случае если произошла ошибка, узел не ответил, или в ответ пришёл предопределённый код ответа то именно это и будет отображено в результате работы. Любой пришедший ответ снабжается адресом узла который его прислал. В примере выше ответивший узел 127.0.0.1. Если ответ не пришёл, то возможно стоит увеличить время его ожидания (если узел находится достаточно далеко от нас, или используются медленные линии связи), сделать это можно с помощью опции командной строки: ping -w <время в миллисекундах> <адрес узла>
Число байт
Число байт - это размер передаваемого пакета. При отправке запроса размер можно установить в пределах от 0 до 65500 с использованием опции -l <размер пакета>. Так как протокол ICMP предназначен в первую очередь для диагностики, то нет гарантии что проверяемое устройство будет обрабатывать пакеты большого объёма, кроме того пакеты превышающие размер MTU будут подвергнуты фрагментации, такие запросы (состоящие из нескольких пакетов ICMP) конечными устройствами тоже могут отвергаться. Больший объём передаваемых данных также подвержен большей вероятности потери части этих данных при передаче. Там где нерегулярной ошибке очень сложно попасть на пакет минимального объёма, большие пакеты таким ошибкам подвержены больше, соответственно если часть данных при передаче потеряется то ответа от удалённого устройства получено не будет. Таким образом при диагностике доступности узла сети с помощью пакетов больших объёмов, можно с большей уверенностью судить о качестве работы сети в целом.
Изменения размера передаваемых данных, также поможет выяснить дополнительные характеристики сети. Параметр -f - не фрагментировать запрещает разбивать пакет на части, в результате узел на котором это может потребоваться для дальнейшей отправки данных вынуждено будет пакет отбросить. Основываясь на это принципе и комбинируя запросы различной длины, можно использовать ping для выяснения наименьшего MTU на пути следования от источника до проверяемого узла. В свою очередь MTU косвенно может показать используемые транспортные технологии - например PPPoE.
Время
Следующее значение - время от момента посылки пакета до его получения. Обычно, при стандартных настройках, внутри сети провайдера это значение не превышает 5-10мс, в сегменте Российского интернета хорошими показателями будут значения меньшие 30мс. Зарубежные сайты в зависимости от направления и используемых технологий передачи могут отвечать от 50-60мс до 300,400,600мс и больших значений. На время ответа влияет расстояние до узла назначения, используемая технология передачи, пропускные способности оборудования используемого на пути следования, количество этого оборудования. Все эти показатели сказываются в разных условиях по разному, но в целом всё сводится к тому - чем дальше находится узел назначения от источника тем задержка больше, при этом следует учитывать что пакет даже при отправке в пределах одного региона может пройти полмира. Там где расстояние влияет непосредственно - это спутниковые каналы связи, где задержка может выражаться значениями в несколько секунд.
Размер передаваемых данных также отражается на значении показателя “время”, соответственно чтобы передать больший объём данных потребуется и большее время. Применяя этот подход можно косвенно оценить скорость передачи от источника до назначения, выполняя команду ping с разными значениями размера пакетов и вычисляя разницу во времени ответа.
>ping www.ru -l 10000
Обмен пакетами с www.ru [194.87.0.50] с 10000 байт данных:
Ответ от 194.87.0.50: число байт=10000 время=40мс TTL=58
Ответ от 194.87.0.50: число байт=10000 время=40мс TTL=58
Ответ от 194.87.0.50: число байт=10000 время=38мс TTL=58
Ответ от 194.87.0.50: число байт=10000 время=39мс TTL=58
Статистика Ping для 194.87.0.50:
Пакетов: отправлено = 4, получено = 4, потеряно = 0
(0% потерь)
Приблизительное время приема-передачи в мс:
Минимальное = 38мсек, Максимальное = 40 мсек, Среднее = 39 мсек
>ping www.ru -l 60000
Обмен пакетами с www.ru [194.87.0.50] с 60000 байт данных:
Ответ от 194.87.0.50: число байт=60000 время=110мс TTL=58
Ответ от 194.87.0.50: число байт=60000 время=110мс TTL=58
Ответ от 194.87.0.50: число байт=60000 время=108мс TTL=58
Ответ от 194.87.0.50: число байт=60000 время=109мс TTL=58
Статистика Ping для 194.87.0.50:
Пакетов: отправлено = 4, получено = 4, потеряно = 0
(0% потерь)
Приблизительное время приема-передачи в мс:
Минимальное = 108мсек, Максимальное = 110 мсек, Среднее = 109 мсек
Например, мы отправили запросы с размером 10000 байт и получили ответ за 40мс. А ответ на запрос в 60000 байт мы получили за 110мс. Посчитаем разницу 110-40 = 70мс потребовалось чтобы отправить и получить 50000 байт (не забываем что это общее время с момента отправки до момент получения ответа). Таким образом 50000/0,07 ~ 714286 Байт/c. Если мы используем симметричный канал (скорость до узла и обратно равна), то можно поделить на два чтобы узнать скорость передачи в одном направлении, итого 357143Байт/c или около 3Мбит/c. Конечно это оценка является очень приблизительной, львиную долю задержки здесь вносят сами узлы передающий и отвечающий, но использовать подобные оценки для сравнения друг с другом всё же можно.
TTL
TTL - это переменная счётчик которая уменьшается на единицу при проходе очередного маршрутизатора. Это значение используется traceroute, чтобы отображать промежуточные узлы. Но также как и размер MTU эта величина косвенно может раскрыть используемое оборудование проверяемого узла. Обратите внимание в первом примере команда ping 127.0.0.1 показывала значение TTL=128. Второй пример показывает данную величину уже равную 58. В разных системах принято различные реализации начальной установки данной величины. В первом примере был узел с ОС Windows с начальным значением TTL=128, второй пример, если учесть что ответ уже прошёл несколько промежуточных маршрутизаторов, скорее всего содержал начальное значение равное 64, что показывает нам на *nix системы. Даже не смотря на то что используемые стандартны одни и те же, иначе бы взаимодействия вовсе бы не было, по их реализации можно судить об используемом оборудовании и системах.
Запись маршрута
Утилита ping обладает одним уникальным параметром, позволяющим очень точно оценить через какие промежуточные узлы проходит отправленный пакет, этот параметр -r <число>, в *nix системах -R. Число это значение от 1 до 9, показывающее сколько промежуточных узлов (учитываются узлы туда и обратно) надо записать, а потом показать. 9 - максимальное значение не зависимо от используемой ОС, даже если не задано явно. То есть ping выступает в качестве traceroute, но при этом промежуточные маршрутизаторы сами заполняют соответствующее поле в пакете, таким образом раскрывая свои внутренние идентификаторы, которые могут быть недоступны для traceroute, например видно немаршрутизируемые частные адреса из глобальной маршрутизируемой сети. При достижении узла назначения, заполненное поле копируется в пакет отправляемый обратно и таким образом в результате работы ping -r будет видно полный маршрут до проверяемого узла и обратно (чего нельзя достичь traceroute). Все остальные части ответа также сохранены:
>ping -r 9 www.ru
Обмен пакетами с www.ru [194.87.0.50] с 32 байт данных:
Ответ от 194.87.0.50: число байт=32 время=32мс TTL=59
Маршрут: 88.87.67.53 ->
10.0.254.149 ->
193.232.245.132 ->
194.87.0.29 ->
#Узел назначения:
194.87.0.50 ->
#Обратный маршрут:
194.87.0.50 ->
194.87.0.111 ->
193.232.244.35
Добавленные комментарии отмечают различные части маршрута.
Можно сравнить с результатом выполнения команды traceroute
>tracert -d www.ru
Трассировка маршрута к www.ru [194.87.0.50]
с максимальным числом прыжков 30:
1 120 ms 2 ms 2 ms 10.93.255.254
2 13 ms 13 ms 13 ms 88.87.67.54
3 29 ms 27 ms 28 ms 193.232.245.132
4 107 ms 205 ms 210 ms 193.232.244.35
5 29 ms 28 ms 28 ms 194.87.0.50
Трассировка завершена.
Видно что маршруты отличаются, точнее отличаются идентификаторы промежуточных узлов - адрес 10.0.254.149, который соответствует 88.87.67.54 в команде traceroute, и адрес 88.87.67.53, соответствующий 10.93.255.254. Но данное мощное средство анализа является лишь добавлением, потому что, как уже было сказано выше, имеет существенное ограничение поля для записи этих данных (максимум 9 промежуточных узлов), в примере обратный маршрут не записан до конца, кроме того запросы с такой опцией могут фильтроваться в сети, и это вообще исключает использование данного параметра в работе.
-
Здесь и далее рассматривается работы утилиты в ОС Windows ↩︎