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

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

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

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

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

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

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

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

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

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

Трассировка маршрута к aport.ru [194.67.18.8]
с максимальным числом прыжков 30:
C:\>tracert www.aport.ru
 1 150 ms 130 ms 131 ms nas.itech.ru [195.151.210.36]
 2 140 ms 141 ms 150 ms ns.itech.ru [195.151.210.33]
 3 221 ms 180 ms 220 ms gw.itech.ru [195.151.210.29]
 4 310 ms 401 ms 330 ms 195.151.200.90
 5 300 ms 341 ms 270 ms krd-gw.mtt.ru [195.151.52.41]

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

C:\>ping www.aport.ru -i 1
Обмен пакетами с aport.ru [194.67.18.8] по 32 байт:
Ответ от 195.151.210.36: Превышен срок жизни (TTL) при передаче пакета.

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

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

C:\>ping www.aport.ru –i 2
Обмен пакетами с aport.ru [194.67.18.8] по 32 байт:
Ответ от 195.151.210.33: Превышен срок жизни (TTL) при передаче пакета.

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

C:\>ping www.aport.ru –i 3 
Обмен пакетами с aport.ru [194.67.18.8] по 32 байт:
Ответ от 195.151.210.29: Превышен срок жизни (TTL) при передаче пакета.

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

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

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

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

C:\>ping www.itech.ru –v 0x2
Обмен пакетами с ns1.itech.ru [195.151.210.34] по 32 байт:
Ответ от 195.151.210.34: число байт=32 время=130мс TTL=254

C:\>ping www.itech.ru –v 0x4 –n 1
Обмен пакетами с ns1.itech.ru [195.151.210.34] по 32 байт:
Ответ от 195.151.210.34: число байт=32 время=130мс TTL=254

C:\>ping www.itech.ru –v 0x8 –n 1
Обмен пакетами с ns1.itech.ru [195.151.210.34] по 32 байт:
Ответ от 195.151.210.34: число байт=32 время=130мс TTL=254

C:\>ping www.itech.ru –v 16
Обмен пакетами с ns1.itech.ru [195.151.210.34] по 32 байт:
Ответ от 195.151.210.34: число байт=32 время=130мс TTL=254

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

C:\>ping www.krintel.ru –v 2
Обмен пакетами с www.krintel.ru [195.161.42.218] по 32 байт:
Ответ от 195.161.42.218: число байт=32 время=2143мс TTL=127

C:\>ping www.krintel.ru –w 10000 –v 4
Обмен пакетами с www.krintel.ru [195.161.42.218] по 32 байт:
Ответ от 195.161.42.218: число байт=32 время=1763мс TTL=127

C:\>ping www.krintel.ru –v 8
Обмен пакетами с www.krintel.ru [195.161.42.218] по 32 байт:
Превышен интервал ожидания для запроса.
Ответ от 195.161.42.218: число байт=32 время=1332мс TTL=127

C:\>ping www.krintel.ru –v 16
Обмен пакетами с www.krintel.ru [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 на данном маршруте и, если имеется несколько альтернативных маршрутов, выбрать из них наиболее подходящий².

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

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

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

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

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

C:\>ping www.itech.ru –s 2

Обмен пакетами с ns1.itech.ru [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.

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

Ключ -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мс

Все эти меры предосторожности объясняются тем, что эхо-посылки имеют более высокий приоритет по сравнению с обычными пакетами (иначе бы эха век не дождаться), и злоумышленники могут перегрузить сервер, направив на него штурм эхо-запросов. "Упасть", правда, сервер не упадет, но вот общая производительность несколько снизится. Хуже, если направить шторм эхо-запросов от имени жертвы, выходящей в Интернет по модему: на нее обрушится сокрушительная лавина эхо-ответов от быстродействующего сервера (хорошо, если одного), плотно забивающая канал…

Вот поэтому-то для заблаговременного предотвращения возможности атаки, эхо-посылки и запрещаются, делая работу ping невозможной, но все службы сервера продолжают, как ни в чем не бывало, работать!

информация с сайта