Что такое ping и почему сервер может на него не отвечать

Утилите ping уже больше сорока лет, но вокруг неё до сих пор хватает мифов. Разбираемся, как работает ICMP, почему ping «молчит» чаще, чем кажется, и зачем он всё ещё нужен в мониторинге

Откуда вообще взялся ping

Декабрь 1983 года. Майк Мьюс, программист исследовательской лаборатории армии США, садится вечером за компьютер и за несколько часов пишет утилиту, которую сегодня запускали почти с каждой машины в мире.

Название он выбрал не случайно. Ping — это звук активного сонара подводной лодки: акустический импульс уходит в воду, отражается от препятствия, возвращается. По задержке между отправкой и эхом моряки оценивают расстояние до объекта. Утилита делает то же самое, только в сети: посылает пакет, ждёт ответ, замеряет время.

Сам Мьюс называл свою программу «тысячестрочным хаком» и не ожидал, что она проживёт десятилетия. Но конструкция оказалась настолько простой и удобной, что её портировали во все операционные системы — от Windows и Linux до микроконтроллеров и роутеров. Сегодня ping есть на любом устройстве, где есть TCP/IP-стек, а в мониторинге на нём основана автоматическая проверка ping.

Что такое ICMP — и почему это не TCP и не UDP

Большинство привыкло, что в сети есть две вещи: TCP (надёжный, с подтверждениями) и UDP (быстрый, без подтверждений). Ping работает по третьему протоколу — ICMP (Internet Control Message Protocol).

Главное отличие ICMP от TCP/UDP: у него нет портов. Это служебный протокол сетевого уровня, через который сетевые устройства обмениваются служебными сообщениями — «этот хост недоступен», «время жизни пакета истекло», «сеть перегружена». Ping — всего лишь один из частных случаев использования ICMP.

Когда вы запускаете ping example.ru, происходит следующее:

• Ваш компьютер шлёт ICMP-пакет типа Echo Request (тип 8) — буквально «скажи мне эхо»
• В payload пакета лежит произвольная нагрузка (по умолчанию 56 байт — например, латинский алфавит)
• Удалённый хост, если настроен на ответ, возвращает Echo Reply (тип 0) с тем же payload
• Утилита замеряет время между отправкой и получением и показывает его в миллисекундах

Полный размер дефолтного ping-пакета — 64 байта: 8 байт ICMP-заголовок + 56 байт данных. Минимально полезный пакет в сети.

Как пользоваться ping

Базовый синтаксис одинаков везде, но есть нюансы по операционным системам.

Linux и macOS — ping шлёт пакеты бесконечно, пока не нажмёшь Ctrl+C:

Если нужно ровно 5 пакетов и потом выйти:

Windows — наоборот, по умолчанию шлёт 4 пакета и завершается. Чтобы пинговать бесконечно, нужен флаг -t:

Вывод выглядит примерно так:

Что важно в выводе:

• time — время от отправки до получения ответа (round-trip time, RTT). Для сайта в той же стране норма — 5–30 мс
• ttl — сколько прыжков (хопов) сделал пакет в обратном направлении (об этом ниже)
• packet loss — процент потерянных пакетов. Любое значение больше 0% — сигнал, что в сети что-то не так
• min/avg/max — разброс RTT. Большая разница между min и max означает джиттер: сеть нестабильна
• icmp_seq — порядковый номер пакета. Если номер в выводе пропущен — именно этот пакет потерялся
• mdev — стандартное отклонение RTT (есть в Linux-выводе). Высокое значение — признак нестабильного соединения
• число хопов — его можно прикинуть из ttl: Linux-серверы стартуют с TTL 64, поэтому ttl=58 означает 64 − 58 = 6 маршрутизаторов на пути

Как выглядит плохой вывод

Выше был пример здоровой сети. А вот как выглядит проблемная — сто пакетов до нестабильного хоста:

Диагноз: 13% потерь плюс высокий mdev (312 мс) — нестабильное соединение. Проблема либо у провайдера, либо сервер перегружен. Сайт при этом будет тормозить или частично не загружаться.

Шпаргалка команд

Кроме базовых -c и -t, в хозяйстве пригодятся ещё несколько команд:

Почему сервер может не отвечать на ping

А вот это самое интересное. Молчание ping не значит, что сервер мёртв. Причин у тишины может быть с десяток — и почти каждая из них в практике встречалась с известными сайтами.

1. Админ выключил ICMP на firewall

Самая частая причина. Корни уходят в 1996 год, когда обнаружили атаку Ping of Death: специально собранный фрагментированный ICMP-пакет размером больше 65 535 байт обрушивал ядро Windows 95 и NT. Уязвимость давно закрыли, но многие сисадмины с тех пор по привычке режут ICMP на периметре — «на всякий случай».

Хрестоматийный пример — microsoft.com. Корпоративная политика Microsoft много лет запрещала отвечать на ping. В какой-то момент сайт начал отвечать снова, потом снова замолчал. Если пингуете и получаете тишину — первое, что стоит проверить, это правила фильтрации.

Под блокировку при этом попадает не только сам ping — у каждого типа ICMP-сообщений своя мотивация для запрета:

Отдельный нюанс — облака: AWS, Google Cloud и Azure по умолчанию блокируют входящий ICMP в Security Groups. Чтобы новый сервер начал отвечать на ping, правило «All ICMP» нужно открывать явно.

2. Cloudflare, CDN и другая инфраструктура

Сайт может стоять за Cloudflare или другим CDN. В этом случае вы пингуете не сервер, а edge-узел провайдера. Большинство CDN отвечают на ping (Cloudflare — да), но отвечают они не с того IP, что показал DNS, а с того, который ближе к вам по anycast-маршрутизации.

Что это значит на практике: пингуя cloudflare.com из Москвы и Новосибирска, вы попадаете в разные дата-центры. RTT в Москве — 2 мс, в Новосибирске — 40 мс. Это не значит, что «сайт медленнее в Новосибирске» — это значит, что в Новосибирске вас обслуживает другой edge-узел.

3. AWS Network Load Balancer

В облаке Amazon есть Network Load Balancer — и он архитектурно не отвечает на ICMP. Если сайт стоит за AWS NLB, ping не работает в принципе. Это не баг и не атака — так устроен сервис. Здоровье балансировщика проверяется через TCP-health-check, ping ничего не показывает.

4. Защита от DDoS

При большом потоке ICMP-пакетов сервер тратит CPU на их обработку. Сервисы защиты от DDoS (StormWall, DDoS-Guard, Qrator) автоматически режут ICMP, когда видят аномальный объём. Иногда оптом, иногда выборочно — в зависимости от подозрительности источника.

5. Rate limiting

Многие хостеры и операторы связи лимитируют ICMP по умолчанию: не больше N пакетов в секунду с одного IP. Если пинговать «ping flood» (флаг -f), после первых десятков пакетов начнётся потеря — не потому что сервер упал, а потому что промежуточный роутер режет трафик.

Лимит есть и на уровне самой ОС сервера: Linux по умолчанию ограничивает отправку ICMP Echo Reply (параметр net.ipv4.icmp_ratelimit). Один сервис мониторинга с редкими проверками в лимит не упрётся, но если тот же сервер параллельно пингуют несколько сервисов, часть ответов начнёт дропаться — при том что машина в полном порядке.

6. Хост вообще не TCP/IP-машина

На периметре могут стоять устройства, которые не должны «светиться» в сети: VPN-концентраторы, корпоративные шлюзы, специализированные firewall-устройства. Они принимают трафик строго на нужные порты и игнорируют всё остальное, включая ICMP.

7. Вы пингуете не тот IP

Домен может резолвиться в разные IP в зависимости от локации (GeoDNS). А ещё поддомен www.example.ru может смотреть на один сервер, а example.ru — на другой. В итоге вы пингуете один адрес, а сайт работает через другой: ping молчит, хотя с сервисом всё хорошо.

8. ICMP отключён на уровне ОС

Кроме firewall, ответы на Echo Request можно выключить средствами самого ядра. Администратору достаточно одной команды:

После этого сервер будет принимать ping-запросы, но молча их отбрасывать. Снаружи — таймаут, неотличимый от блокировки на файрволе.

Ложные срабатывания в мониторинге

Есть ещё три сценария, когда ping молчит, а сервер жив, — и все три регулярно ловят автоматический мониторинг:

• Файрвол забанил IP точек мониторинга. После серии однотипных проверок fail2ban, CSF или iptables recent могут занести адреса серверов мониторинга в чёрный список. Ping перестаёт проходить, хотя сервер работает. Решение — внести IP точек мониторинга в белый список файрвола
• ОС жертвует ICMP под нагрузкой. При высокой нагрузке система может отбрасывать ICMP-пакеты, отдавая приоритет TCP-трафику (HTTP, SSH). Ping покажет потери или таймауты, а сайт при этом будет работать
• Асимметричная маршрутизация. Пакет к серверу идёт через одну сеть, а обратно — через другую. Если обратный маршрут сломан, Echo Reply не доходит, хотя сервер его отправил: ping покажет 100% потерь, а HTTP через другой маршрут работает

Главная ловушка: ping ≠ сайт работает

А теперь самый важный пункт, который пропускают почти все.

Ping показывает, что у сервера живая сеть. То есть сетевой стек поднят, ядро отвечает на пакеты, маршрут до машины существует. Это всё.

Ping ничего не говорит о том, работает ли:

• Веб-сервер (nginx, Apache) — может быть упавшим, повисшим, перегруженным
• База данных — может тормозить или вообще не отвечать
• Бэкенд-приложение — PHP-FPM, Node.js, любой код
• SSL-сертификат — может быть просрочен или выписан не на тот домен
• DNS — домен мог отвалиться или резолвиться на чужой IP

Картина «ping есть, сайт не открывается» — это норма, а не аномалия. Машина в сети жива, а сайт — нет. Поэтому ping в чистом виде не годится как единственная проверка для мониторинга веб-сайта. Это базовый кирпич, который имеет смысл сочетать с GET, HEAD или TCP-проверкой нужного порта.

Как это выглядит в терминале

Классическая картина «машина жива, сервис мёртв» воспроизводится двумя командами:

Диагноз: сеть до сервера в порядке (ping OK), но nginx или Apache не слушает порт 80 — веб-сервер упал или слушает другой порт. ICMP-проверка в этой ситуации будет рапортовать «всё хорошо».

TTL и неожиданный побочный эффект

В заголовке каждого IP-пакета есть поле TTL (Time To Live) — счётчик, который уменьшается на 1 при прохождении каждого роутера. Когда TTL доходит до 0, пакет умирает, а роутер шлёт обратно ICMP-сообщение типа Time Exceeded.

Изначально это придумали как защиту от петель: если пакет попадёт в кольцо, он не будет крутиться бесконечно, а через 64 (или 128) прыжков самоликвидируется.

А потом кто-то заметил: если послать пакет с TTL=1, первый же роутер на пути его прибьёт и пришлёт Time Exceeded. С обратным IP-адресом этого роутера. Если послать TTL=2 — ответит второй роутер. TTL=3 — третий. И так далее.

Именно так работает traceroute — утилита, которая показывает путь пакета от вашего компьютера до сервера, хоп за хопом. Это не магия и не отдельный протокол: это умное использование TTL и ICMP Time Exceeded.

На Windows та же команда называется tracert. Если ping молчит, а сайт не открывается — traceroute покажет, на каком именно хопе обрывается путь.

Начальный TTL: бонус для диагностики

Стартовое значение TTL пакет получает от операционной системы отправителя — и у разных ОС оно разное:

Anycast: один IP, разные дата-центры

Есть ещё одна тонкость, про которую забывают. Современный интернет вовсю использует anycast — технологию, при которой один и тот же IP-адрес объявляется одновременно из десятков физически разных точек, а маршрутизация BGP сама выбирает ближайшую.

Самый известный пример — 1.1.1.1, публичный DNS-резолвер Cloudflare. Этот адрес одновременно живёт в 300+ городах мира. Когда вы пингуете его, вы попадаете в дата-центр, физически ближайший к вашему провайдеру.

Что это значит на практике: один и тот же IP может пинговаться с разным RTT из разных городов — и это нормально. Не потому что сеть нестабильна, а потому что вы попадаете в разные физические узлы.

Для мониторинга это означает простую вещь: проверять сайт с одной точки — недостаточно. Если узел Cloudflare в Москве лёг, а в Новосибирске работает, проверка из Москвы покажет фейл, проверка из Новосибирска — ОК. Только мониторинг доступности сайта с разных географических точек даёт реальную картину.

Когда ICMP всё ещё нужен в мониторинге

Несмотря на все ограничения, ICMP-проверка остаётся самой дешёвой и быстрой. Это первый эшелон диагностики:

• Серверы без HTTP — маршрутизаторы, NAS, IoT-устройства, бэкенд-машины. Для них ICMP — единственный универсальный сигнал жизни
• Сетевая связность — быстро понять, доступна ли машина по сети в принципе, прежде чем копать глубже
• Дешёвая базовая проверка — ping создаёт минимальную нагрузку и на сервер, и на сеть. Им можно молотить чаще, чем HTTP
• Измерение задержек — ping даёт честный сетевой RTT, без накладных расходов TLS и обработки на бэкенде
• География — если пинги идут хорошо из одного города и плохо из другого, проблема не в сервере, а в сетевом пути

Сравнение типов проверок

Как Пруфен использует ICMP

В Пруфене ICMP-проверка доступности сервера — одна из 18 типов мониторинга и одна из самых дешёвых.

Под капотом — 13 точек мониторинга:

• Москва (две независимые точки на разных провайдерах)
• Санкт-Петербург (две точки)
• Екатеринбург (две точки)
• Уфа, Мурманск, Новосибирск, Кемерово, Владивосток
• Минск и Испания — зарубежные точки для сравнения

Все тринадцать точек пингуют друг друга по ICMP каждые 5 минут — вы можете прямо сейчас посмотреть живой статус на странице prufen.ru/status. Это, по сути, публичная демонстрация того, как работает наша инфраструктура.

Проверка считается провалом, если ответа не пришло из 80% локаций — это защищает от ложных алертов, когда один из узлов мониторинга временно перегружен или у конкретного провайдера сетевые проблемы. 

Уведомление о падении приходит в Telegram, Макс, на почту или голосовым звонком.

Стоит такая проверка 0,01 ₽ за запуск — это самый дешёвый тип мониторинга в сервисе.

Как считается статус

Результат каждой проверки превращается в статус по простым порогам:

Итого

Ping — одна из старейших утилит интернета и одна из самых недооценённых. За простым «пакет ушёл, пакет вернулся» стоит целый протокол служебных сообщений, на котором держится диагностика сетей: от traceroute до anycast-маршрутизации.

Главное, что стоит запомнить: ping проверяет сеть, а не сайт. Молчание сервера на ping не значит, что он мёртв — возможно, просто запрещён ICMP. А успешный ping не значит, что сайт работает — внутри всё могло давно сломаться.

Поэтому ICMP-проверка в мониторинге хороша как первый эшелон: дешёвая, быстрая, ловит сетевые проблемы. Но в одиночку для веб-сайта её мало — рядом обязательно должен стоять GET, HEAD или TCP-проверка нужного порта.