Каково назначение ключей утилиты ping?
Несмотря на свою простоту, утилита ping из штатной поставки Windows, принимает достаточно большое количество ключей командной строки, более чем поверхностно описанных в прилагаемой документации. Неудивительно, что многие возможности ping ускользают не только от начинающих, но и умудренных жизнью пользователей!
Ключ –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мс
Ключ –n задает количество отправляемых эхо – запросов (по умолчанию 4). Увеличение количества запросов бывает необходимо для контроля надежности и устойчивости работы сервера. Чем выше качество канала, тем меньше разброс по времени ответов.
Ключ –t заставляет утилиту ping посылать запросы в бесконечном цикле до ее прерывания нажатием комбинации клавиш <Ctrl-C>. Внимание: <Ctrl-Break> не прерывает процесс, а выводит текущую статистику! Этот ключ очень удобен для ожидания момента пробуждения некстати зависшего сервера – запустил "ping www.hover-server.fu -t" и жди появления сообщения "Host Alive" или что-то в этом роде.
Ключ –l задает размер дейтаграммы без учета длины заголовка (28 байт), посылаемой в эхо – запросе. Допустимыми являются значения от 0 до 65.500 включительно. По умолчанию размер дейтаграммы составляет 32 байта. Манипулируя этим значением можно выяснить зависимость скорость доставки – размер дейтаграммы. Если размер дейтаграммы превысит некоторую критическую величину (определяемую каждым промежуточным узлом самостоятельно), дейтаграмма разрезается на несколько пакетов подходящего размера, каждый из которых добирается до конечной точки маршрута самостоятельно, а на узле назначения они вновь собираются в исходную дейтаграмму.
Ключ –f устанавливает на дейтаграмме специальную пометку, запрещающую ее разрезание (то есть, говоря техническим языком, фрагментацию). Если хотя бы один из промежуточных узлов не может обрабатывать пакеты таких размеров, он прибивает дейтаграмму и посылает отправителю уведомление, объясняя причину смерти тем, что требуется фрагментация, но установлена пометка, ее запрещающая. Впрочем, некоторые узлы не посылают такого уведомления, молчаливо отправляя пакет на тот свет или же разрезают дейтаграмму вопреки запрету (впрочем, последнее встречается редко). Вкупе с ключом –l, задающим длину дейтаграммы, запрет фрагментации ключом –f, позволяет определить максимальный размер не фрагментируемых пакетов. (см. "Оптимизация соединения с Интернет" и "Описание утилиты MTUSpeed").
Ключ –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) при передаче пакета.
В самом деле, этот прием работает! Правда, уж очень утомительно перебирать пакеты вручную. Но работу легко оптимизировать командным файлом следующего содержания {>>>> сноска Работает только под Windows 2000 или выше} FOR /L (%%I) IN (1,1,30) DO ping %1 -i %%I, вызываемого с аргументом – доменным именем или IP-адресом трассируемого узла, и он самостоятельно начнет перебирать все значения TTL от 1 до 30.
Ключ –v задает значения поля типа службы (TOS - Type Of Service). Тип сервиса с помощью некоторых абстрактных параметров указывает предпочтительный вид обслуживания – минимальная задержка, максимальная пропускная способность, максимальная надежность, минимальные издержки на пересылку или обычная, неприоритетная, пересылка. Предпочтение может быть отдано только одному типу приоритета – нельзя одновременно требовать молниеносной скорости пересылки пакета в купе с соломоновой надежностью его доставки. Выбирайте уж что-то одно!
Тип сервиса задается одним из следующих десятичных чисел (См. таблицу 3). Как легко видеть, каждому значению соответствует свой бит:
|
Код сервиса |
Пояснение |
|
2 |
минимальные издержки на пересылку |
|
4 |
максимальная надежность доставки |
|
8 |
максимальная пропускная способность |
|
16 |
минимальная задержка |
Не все маршрутизаторы анализируют поле 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 на данном маршруте и если имеется несколько альтернативных маршрутов – выбрать из них наиболее подходящий {>>>>> сноска К слову сказать, далеко не все приложения устанавливают поле 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 (см. "Каково назначение ключей tracert?").
Ключ –k похож на ключ –j, но задает список узлов для жесткой маршрутизации, т.е. пакет передается из рук в руки строго по перечню перечисленных узлов и ни один их них не может позволить себе воспользоваться услугами "собственного" маршрутизатора для передачи пакета следующему узлу. Если узел не может передать пакет напрямую, он уничтожает его и посылает отправителю соответствующее уведомление, дескать, такая маршрутизация от источника невозможна. Существует очень мало причин, требующих применения свободной, а тем более жесткой маршрутизации. Все это пережиток старых времен, – современные сети самостоятельно решают проблемы маршрутиазции пакетов и пытаться помочь им, право, не стоит – они и без того справляются со своей задачей слишком хорошо.
Ключ –-a задает определение имен узлов по их IP-адресам. Так, во всяком случае, сказано в документации. Смысл этого неясен – такое определение и без того происходит автоматически независимо от наличия (отсутствия) ключа "-a".
Родственные вопросы:
Провайдер и удаленный доступ à Оптимизация соединения с Интернет
Провайдер и удаленный доступ à Описание утилиты MTUSpeed
Как определить полный путь (прохождение) при скачивании файла
Можно ли обойти защиту от трассировки?
Каково назначение ключей tracert?
