Logo Море(!) аналитической информации!
IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware
VPS в 21 локации

От 104 рублей в месяц

Безлимитный трафик. Защита от ДДоС.

🔥 VPS до 5.7 ГГц под любые задачи с AntiDDoS в 7 локациях

💸 Гифткод CITFORUM (250р на баланс) и попробуйте уже сейчас!

🛒 Скидка 15% на первый платеж (в течение 24ч)

Скидка до 20% на услуги дата-центра. Аренда серверной стойки. Colocation от 1U!

Миграция в облако #SotelCloud. Виртуальный сервер в облаке. Выбрать конфигурацию на сайте!

Виртуальная АТС для вашего бизнеса. Приветственные бонусы для новых клиентов!

Виртуальные VPS серверы в РФ и ЕС

Dedicated серверы в РФ и ЕС

По промокоду CITFORUM скидка 30% на заказ VPS\VDS

Вопросы о ping-е

Крис Касперски
kk@sendmail.ru

Что такое ping и для чего он нужен?

Ping — эта такая утилита для проверки работоспособности сети. Принцип ее работы в общих чертах заключается в посылке узлу эхо-запроса и ожидании от него эхо-ответа. Каждый узел сети Интернет должен уметь принимать эхо-запросы и возвращать эхо-ответы, разумеется, если он подсоединен к сети и работает.
Отсутствие эхо-ответа от сервера обозначает: либо сервер "висит", либо имеется неустранимое повреждение сети на участке клиент - сервер, обойти в "обход" которое невозможно.
Это свойство делает ping удобным инструментом проверки работоспособности узла и целостности соединения. Впрочем, отрицательный результат работы ping не всегда свидетельствует о наличии какой-либо проблемы (см. "Почему ping не проходит, а сайт сервера нормально работает и открывается?").

Где я могу достать ping?

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

Каково назначение ключей утилиты 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, позволяет определить максимальный размер нефрагментируемых пакетов.
Ключ –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). Тип сервиса с помощью некоторых абстрактных параметров указывает предпочтительный вид обслуживания — минимальная задержка, максимальная пропускная способность, максимальная надежность, минимальные издержки на пересылку или обычная, неприоритетная, пересылка. Предпочтение может быть отдано только одному типу приоритета — нельзя одновременно требовать молниеносной скорости пересылки пакета в купе с соломоновой надежностью его доставки. Выбирайте уж что-то одно!
Тип сервиса задается одним из следующих десятичных чисел (См. таблицу 1). Как легко увидеть, каждому значению соответствует свой бит:

Таблица 1. Допустимые типы сервиса в поле TOS

Код сервиса

Пояснение

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".

Q:Почему ping не проходит, а сайт сервера нормально работает и открывается?

Бывает, ping к некоторому серверу упорно не проходит, какую бы ни выбрал задержку, но все сервисы (будь то почта или web) работают нормально. Почему? Все объясняется очень просто — администратор сервера защитил его межсетевым экраном, блокирующим либо эхо-запросы, либо эхо-отклики, либо и те, и другие вместе. А может запрет эхо-откликов наложен на сам узел. Все эти меры предосторожности объясняются тем, что эхо-посылки имеют более высокий приоритет по сравнению с обычными пакетами (иначе бы эха век не дождаться) и злоумышленники могут перегрузить сервер, направив на него штурм эхо-запросов. "Упасть", правда, сервер не упадет, но вот общая производительность несколько снизится. Хуже направить шторм эхо-запросов от имени жертвы, выходящей в Интернет по модему: на нее обрушится сокрушительная лавина эхо-ответов от быстродействующего сервера (хорошо, если одного), плотно забивающая канал…
Вот поэтому-то для заблаговременного предотвращения возможности атаки эхо-посылки и запрещаются, делая работу ping невозможной, но все службы сервера продолжают как ни в чем не бывало работать!
VPS/VDS серверы. 30 локаций на выбор

Серверы VPS/VDS с большим диском

Хорошие условия для реселлеров

4VPS.SU - VPS в 17-ти странах

2Gbit/s безлимит

Современное железо!

Бесплатный конструктор сайтов и Landing Page

Хостинг с DDoS защитой от 2.5$ + Бесплатный SSL и Домен

SSD VPS в Нидерландах под различные задачи от 2.6$

✅ Дешевый VPS-хостинг на AMD EPYC: 1vCore, 3GB DDR4, 15GB NVMe всего за €3,50!

🔥 Anti-DDoS защита 12 Тбит/с!

Новости мира IT:

Архив новостей

IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware

Информация для рекламодателей PR-акции, размещение рекламы — adv@citforum.ru,
тел. +7 495 7861149
Пресс-релизы — pr@citforum.ru
Обратная связь
Информация для авторов
Rambler's Top100 TopList liveinternet.ru: показано число просмотров за 24 часа, посетителей за 24 часа и за сегодня This Web server launched on February 24, 1997
Copyright © 1997-2000 CIT, © 2001-2019 CIT Forum
Внимание! Любой из материалов, опубликованных на этом сервере, не может быть воспроизведен в какой бы то ни было форме и какими бы то ни было средствами без письменного разрешения владельцев авторских прав. Подробнее...