ICMP и ping: что этот инструмент измеряет на самом деле

ping — первая команда, которую набирает инженер, и первая, которую он неправильно трактует. Она отвечает на очень узкий вопрос, а мы регулярно спрашиваем у неё то, чего она не знает. В этом уроке разберём протокол, на котором она построена, что именно измеряется честно, почему потери в проверке до маршрутизатора часто не означают ничего — и как получить из этой простой утилиты настоящее доказательство для смежников.

Рабочая ситуация

«Клиент жалуется: сайт открывается через раз. Дежурный пингует пограничный маршрутизатор оператора — 2% потерь. Пишет в заявке: „потери на магистрали, эскалирую в транспортный отдел“. Транспортный отдел смотрит счётчики на стыках: ошибок нет, загрузка 40%, ни одного отброшенного пакета за сутки. Заявка гуляет между отделами вторые сутки, клиент злится.»

Обе стороны смотрят на честные показания приборов и делают противоположные выводы. Ошибка сделана на первом шаге: измерили не то, о чём спорят. Разберёмся, что именно измерил дежурный.

Подумай до объяснения

Маршрутизатор пересылает 40 Гбит/с транзита без единой ошибки — почему он может «не успевать» отвечать на десяток эхо-запросов в секунду?
Если узел не ответил на эхо-запрос, значит ли это, что узел недоступен?
Пинг проходит идеально, а тяжёлые страницы не открываются. Как такое возможно, если пакеты явно доходят?

Что узнаешь

Зачем в IP понадобился отдельный служебный протокол и почему он не «поверх» IP, а внутри него
Прочитаешь формат Echo Request и Echo Reply по полям и поймёшь, зачем в них идентификатор и номер
Различишь два принципиально разных случая: пинг до устройства и пинг сквозь устройство
Объяснишь, откуда берутся «потери 2%» при полностью исправном канале — и как это доказать
Прочитаешь вывод построчно: TTL, время, минимум и максимум, разброс, процент потерь
Научишься мерить предельный размер пакета обычным ping — это пригодится в уроке про MTU
Разберёшь, чем ICMPv6 отличается по объёму задач и почему его нельзя фильтровать целиком
Получишь диагностический ключ «наблюдение → вероятная причина → следующее действие»

Вспомни из прошлых треков

Пакет IP несёт адрес отправителя и получателя, а промежуточные устройства принимают решение по адресу назначения. Сегодня мы увидим, что бывает, когда адрес назначения — сам маршрутизатор.
Счётчик TTL в заголовке IP уменьшается на каждом переходе. Сегодня он даст нам оценку длины обратного пути, а в следующем уроке станет основой трассировки.
TCP восстанавливает потери повторной передачей, UDP — нет. Отсюда следует, что «немного потерь» по-разному видно разным сервисам.

1. Зачем в IP отдельный служебный протокол

IP спроектирован как протокол без гарантий: отправил пакет — и всё, никаких подтверждений, никаких уведомлений. Но полностью молчащая сеть неработоспособна: если пакет отброшен, кто-то должен сказать отправителю об этом, иначе тот будет вечно повторять одну и ту же ошибку. Для этого и появился ICMP — Internet Control Message Protocol, описанный в RFC 792.

Важная тонкость, которую пропускают почти все: ICMP не находится над IP, как TCP или UDP. RFC 792 прямо говорит, что ICMP является обязательной частью реализации IP, хотя его сообщения и переносятся внутри IP-пакетов. Практический вывод простой: узел, который «не умеет ICMP», не является корректной реализацией IP. Это не диагностическая надстройка, которую можно выключить без последствий, а часть механизма работы протокола.

Сообщения ICMP делятся на две группы, и путать их нельзя:

Сообщения об ошибке — их порождают устройства на пути: пакет отброшен, время жизни истекло, узел недостижим, пакет слишком велик. Это реакция на чужой пакет.
Запросы и ответы — эхо-запрос и эхо-ответ. Их порождает диагностика, и они не связаны ни с какой ошибкой.

Разделение принципиально, потому что операционные системы и оборудование обращаются с этими группами по-разному: ограничивают их скорость отдельно, фильтруют отдельно и трактуют отдельно. Мы вернёмся к этому в разделе о ложных потерях.

Ещё одно правило из RFC 792, которое избавляет от целого класса «а что если»: «No ICMP messages are sent about ICMP messages» — на служебное сообщение об ошибке не порождается новое служебное сообщение об ошибке. Иначе одна ошибка вызывала бы лавину.

2. Формат эхо-запроса: что реально летит по проводу

Эхо-запрос и эхо-ответ устроены одинаково и отличаются только полем типа: 8 — запрос, 0 — ответ. Код в обоих случаях 0. Дальше идут контрольная сумма, идентификатор, номер последовательности и произвольные данные.

Эхо-запрос лежит внутри обычного IP-пакета. Поле «протокол» в заголовке IP равно 1 — по нему получатель понимает, что дальше идёт ICMP, а не TCP или UDP.

Зачем нужны идентификатор и номер? Ответ приходит обратно тем же путём в стеке, и операционной системе надо понять, кому его отдать: на машине может одновременно работать пять процессов, которые пингуют разные адреса. Идентификатор отвечает на вопрос «чей запрос», номер последовательности — «какой по счёту». Именно номер позволяет утилите сказать «пакет 7 потерян», а не просто «чего-то не хватает».

Поле данных заполняется произвольным содержимым — обычно шаблоном или меткой времени. RFC 1122 (раздел 3.2.2.6) требует от узла реализовать эхо-сервер и вернуть полученные данные неизменными. Отсюда следует полезное свойство: если вернувшиеся данные отличаются от отправленных, значит что-то повредило пакет по дороге, и это уже не вопрос доступности, а вопрос целостности.

Частое заблуждение

«Узел не ответил на эхо — значит, узел недоступен». Неверно. Стандарт обязывает узел отвечать, но администратор вправе закрыть эхо на межсетевом экране, и множество серверов в интернете так и настроены. Молчание — это отсутствие информации, а не свидетельство отказа. Проверять доступность сервиса нужно обращением к самому сервису: попыткой установить соединение на его порт.

3. Пинг до устройства и пинг сквозь устройство: главное различие урока

Современный маршрутизатор — это два разных мира внутри одного корпуса.

Плоскость данных — специализированные микросхемы, которые пересылают транзитные пакеты. Они делают это на скорости интерфейсов и почти без участия процессора.
Плоскость управления — обычный процессор, на котором живут протоколы маршрутизации, командная строка, журнал и, в том числе, формирование эхо-ответов на пакеты, адресованные самому устройству.

Транзитный пакет и пакет, адресованный маршрутизатору, идут разными путями внутри устройства. И это меняет всё в трактовке измерения.

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

Ограничение скорости здесь не дефект, а защита. Если бы устройство честно отвечало на любой объём адресованных ему пакетов, положить магистральный маршрутизатор мог бы кто угодно с домашнего канала. Поэтому применяется защита плоскости управления: трафик, поднимающийся в процессор, классифицируется и ограничивается политикой. Cisco описывает этот механизм как Control Plane Policing — фильтр качества обслуживания, защищающий процессор устройства от разведки и атак отказа в обслуживании.

Это не самодеятельность вендоров, а прямо предусмотренное стандартом поведение. RFC 1812 в разделе 4.3.2.8 говорит буквально: «a router may limit the frequency at which some other sorts of messages, such as ICMP Echo Replies, are generated» — маршрутизатору разрешено ограничивать частоту в том числе эхо-ответов. Два названных документом мотива: расход полосы на обратном пути и расход ресурсов самого маршрутизатора — памяти и процессорного времени.

Аналогичное ограничение есть и на обычных серверах. Ядро Linux документирует параметр icmp_ratelimit со значением по умолчанию 1000 — «минимальный промежуток между ответами в миллисекундах» для типов сообщений, попадающих в маску icmp_ratemask. То есть по умолчанию Linux шлёт такие сообщения не чаще одного в секунду (kernel.org, ip-sysctl). Обрати внимание: маска по умолчанию покрывает сообщения об ошибках, а не эхо-ответ, — и это ровно та деталь, которую путают, когда объясняют потери «рейт-лимитом» без разбора.

Правило, которое закрывает половину споров между отделами

Хочешь судить о транзите — пингуй сквозь участок, то есть конечный узел за ним, а не сам промежуточный маршрутизатор. Пинг до маршрутизатора отвечает только на вопрос «жив ли его процессор и есть ли до него маршрут». Это тоже полезно, но это другой вопрос.

4. Чтение вывода построчно

Типичный вывод в Linux выглядит так:

$ ping -c 5 198.51.100.10
PING 198.51.100.10 (198.51.100.10) 56(84) bytes of data.
64 bytes from 198.51.100.10: icmp_seq=1 ttl=57 time=12.4 ms
64 bytes from 198.51.100.10: icmp_seq=2 ttl=57 time=12.1 ms
64 bytes from 198.51.100.10: icmp_seq=4 ttl=57 time=11.9 ms
64 bytes from 198.51.100.10: icmp_seq=5 ttl=57 time=12.6 ms

--- 198.51.100.10 ping statistics ---
5 packets transmitted, 4 received, 20% packet loss, time 4051ms
rtt min/avg/max/mdev = 11.9/12.2/12.6/0.3 ms

Что здесь есть на самом деле:

56(84) bytes — 56 байт данных плюс 8 байт заголовка ICMP и 20 байт заголовка IP. Полезно помнить: когда задаёшь размер ключом -s, ты задаёшь именно данные, а по проводу летит на 28 байт больше.
icmp_seq — номер из заголовка. Пропущенный номер 3 в примере и есть потерянный пакет. Смотреть надо на распределение пропусков: одиночные разбросанные потери и подряд идущая серия — разные диагнозы.
ttl=57 — счётчик в пришедшем ответе. Он говорит о числе переходов на обратном пути. Ядро Linux документирует начальное значение ip_default_ttl = 64; Microsoft документирует DefaultTTL = 128. Значит 57 при старте от 64 — это семь переходов назад.
time — время туда-обратно, RTT. Оно всегда суммарное: разделить его пополам и получить одностороннюю задержку нельзя, потому что пути в две стороны бывают разной длины.
min/avg/max/mdev — минимум, среднее, максимум и среднее отклонение. Самое ценное здесь не среднее, а разница между минимумом и максимумом.

Почему среднее обманывает

Двадцать ответов: девятнадцать по 10 мс и один на 480 мс. Среднее — 33 мс, выглядит терпимо. А на деле это либо очередь на перегруженном участке, либо всплеск нагрузки на процессоре, либо ожидание в буфере. Для голосового трафика такой выброс уже слышен. Всегда смотри максимум и разброс, а при подозрении — запускай длинное наблюдение, а не пять пакетов.

5. Размер пакета и запрет фрагментации

Утилита умеет больше, чем «работает или нет». Два ключа превращают её в измерительный прибор: задание размера и запрет фрагментации. Смысл прост: запрет фрагментации означает «либо пакет доходит целиком, либо отбрасывается». Наращивая размер, находим точку перелома — предельный размер, проходящий по пути.

Linux:    ping -M do -s 1472 -c 3 198.51.100.10
macOS:    ping -D -s 1472 -c 3 198.51.100.10
Windows:  ping -f -l 1472 198.51.100.10

1472 байта данных + 8 байт ICMP + 20 байт IP = 1500 байт — ровно
обычный предел кадра Ethernet.

Если такой пакет не проходит, а на 1400 проходит — на пути есть участок с меньшим предельным размером: туннель, MPLS, дополнительная метка VLAN. Полностью этот механизм со всеми накладными расходами разберём в уроке про MTU; здесь важно запомнить сам приём и то, что он делается штатной утилитой без всякого прибора.

6. ICMPv6: тот же инструмент, но в разы важнее

В IPv6 служебный протокол описан отдельным документом — RFC 4443. Номера типов другие:

Сообщение	IPv4 (RFC 792)	IPv6 (RFC 4443)
Эхо-запрос	тип 8	тип 128
Эхо-ответ	тип 0	тип 129
Узел недостижим	тип 3	тип 1
Пакет слишком велик	тип 3, код 4	тип 2 (отдельный тип)
Время жизни истекло	тип 11	тип 3

Разница не только в номерах. В IPv6 на этот протокол переложены задачи, которые в IPv4 решались отдельно: обнаружение соседей вместо ARP, автоматическая настройка адреса, обнаружение дублирования адреса. Практический вывод жёсткий: глухая фильтрация ICMPv6 ломает сеть, а не только диагностику. Кроме того, «пакет слишком велик» в IPv6 вынесен в отдельный тип, потому что маршрутизаторы IPv6 не фрагментируют транзитные пакеты вообще — об этом подробно в третьем уроке.

RFC 4443 требует вкладывать в сообщение об ошибке столько исходного пакета, сколько влезает без превышения минимального размера IPv6-пакета, и рекомендует ограничивать скорость таких сообщений маркерным ведром: средняя скорость ограничена, но короткий всплеск разрешён. Для IPv4 RFC 792 требовал возвращать заголовок и первые 64 бита данных исходного пакета — этого хватало, чтобы отправитель понял, о каком именно соединении речь.

7. Диагностический ключ: наблюдение → причина → действие

Что видишь	Вероятная причина	Следующее действие
Потери до маршрутизатора, сервис за ним работает	Ограничение скорости служебных ответов на процессоре	Пинговать сквозь: конечный узел за участком. Счётчики интерфейсов вместо споров
Ответа нет вообще, маршрут в таблице есть	Фильтрация эхо или отсутствие обратного маршрута	Проверить соединением на порт сервиса; проверить обратный маршрут с той стороны
Среднее нормальное, максимум в десятки раз выше	Очередь на узком участке, всплеск на процессоре, буфер	Длинное наблюдение, счётчики отбрасывания в очередях, загрузка стыка по графику
Потери ровной серией, а не вразброс	Кратковременный обрыв, переключение маршрута, перезагрузка карты	Журнал событий за это время, счётчики флапов интерфейса, состояние соседств
Мелкие проходят, крупные с запретом фрагментации — нет	Ограничение размера на участке пути	Найти границу перебором и перейти к разбору MTU и накладных расходов
Разное TTL в ответах на один адрес	Несколько путей до цели или несколько узлов за одним адресом	Трассировка и проверка распределения по путям

8. Мини-лаба: попробуй прямо сейчас

Все команды выполняются на твоём компьютере, ничего ставить не нужно.

Шаг 1. Оценить длину обратного пути.

Linux/macOS:  ping -c 4 1.1.1.1
Windows:      ping -n 4 1.1.1.1

Ожидаемый результат: четыре ответа, значение TTL заметно меньше 64 или 128. Посчитай разницу до ближайшего сверху «круглого» значения — это и есть оценка числа переходов на обратном пути. Запиши число, в следующем уроке сравним его с трассировкой.

Шаг 2. Сравнить свой шлюз и внешний узел.

Linux:    ip route | grep default      # узнать адрес шлюза
Windows:  ipconfig | findstr /i "Основной шлюз"
затем:    ping <адрес шлюза>

Ожидаемый результат: до шлюза время меньше миллисекунды или единицы миллисекунд, до внешнего узла — десятки. Разница показывает, что почти всё время уходит на путь, а не на обработку.

Шаг 3. Найти предельный размер пакета.

Linux:    ping -M do -s 1472 -c 2 1.1.1.1
          ping -M do -s 1500 -c 2 1.1.1.1
Windows:  ping -f -l 1472 -n 2 1.1.1.1
          ping -f -l 1500 -n 2 1.1.1.1

Ожидаемый результат: на 1472 ответ приходит, на 1500 — сообщение о необходимости фрагментации либо тишина. Если и 1472 не проходит — у тебя на пути туннель или PPPoE; уменьшай размер шагами по 8 байт и найди границу.

Шаг 4. Увидеть разброс, а не среднее.

Linux/macOS:  ping -c 100 1.1.1.1 | tail -3
Windows:      ping -n 100 1.1.1.1

Ожидаемый результат: в итоговой строке минимум и максимум различаются в несколько раз даже на исправном канале. Это нормальный фон; тревожит не сам разброс, а его рост и связь с временем суток.

9. Задачи самопроверки

1. Дежурный пингует стык оператора: 200 пакетов, 6 потерь. Загрузка стыка 35%, ошибок на интерфейсах нет, клиент за этим стыком не жалуется. Что написать в заявке?

Что измерение проведено до устройства и потому непригодно для вывода о транзите: ответы формирует процессор, и они ограничены по скорости политикой защиты плоскости управления. Чтобы говорить о транзите, нужно измерение сквозь участок — до конечного узла за ним — плюс счётчики отбрасывания и ошибок на самих интерфейсах. Заявку в транспортный отдел в такой формулировке эскалировать нельзя: она отправит людей искать несуществующую неисправность.

2. Один и тот же адрес отвечает с TTL 57 и TTL 121 в разных пакетах. Что это значит?

Начальные значения у систем разные, поэтому такая картина означает, что отвечают разные узлы: скорее всего, за одним адресом стоит балансировщик или группа серверов на разных операционных системах. Второй вариант — существенно разные обратные пути. Дальше это проверяется трассировкой и обращением к самому сервису, а не эхо-запросом.

3. Почему разделить RTT пополам и получить одностороннюю задержку — ошибка?

Потому что путь туда и путь обратно в IP-сети не обязаны совпадать: маршрутизация односторонняя, и обратный маршрут может идти через другого оператора и быть длиннее. Кроме того, очередь может быть загружена только в одном направлении. Односторонняя задержка измеряется отдельными методиками с синхронизацией часов на обоих концах.

4. Сервер не отвечает на эхо, но веб-страница на нём открывается. Кто неправ — сервер или стандарт?

Формально сервер не выполняет требование RFC 1122 отвечать на эхо-запрос. Практически это осознанное решение администратора: фильтрация эхо на межсетевом экране — обычная практика. Вывод для инженера: доступность сервиса проверяется обращением к сервису. Отсутствие эхо-ответа само по себе не является ни отказом, ни доказательством отказа.

5. Проверка проходит на 1472 байтах, но не проходит на 1473. Что известно о пути и что делать дальше?

Известно, что предельный размер IP-пакета на пути равен 1500 байт: 1472 данных плюс 8 байт ICMP плюс 20 байт IP. Это обычный Ethernet без туннелей — и это хорошая новость. Отдельно стоит проверить, приходит ли при превышении сообщение об ошибке или пакет пропадает молча: во втором случае на пути отфильтрованы служебные сообщения, и это заготовка будущей аварии с крупными пакетами.

6. Почему полная фильтрация ICMPv6 на границе — плохая идея, а фильтрация ICMP в IPv4 обычно проходит без последствий?

Потому что в IPv6 на служебный протокол переложены обнаружение соседей, автонастройка адреса и обнаружение дублирования адреса. Заблокировав его целиком, ты ломаешь не диагностику, а базовую работу сети сегмента. В IPv4 эти задачи решают ARP и DHCP, которые фильтрацией ICMP не затрагиваются, — поэтому последствия там мягче, хотя механизм определения размера пакета ломается и в IPv4.

10. Словарик урока

Термин	English	Что означает
Эхо-запрос / эхо-ответ	Echo Request / Echo Reply	Тип 8 и тип 0 в IPv4; тип 128 и 129 в IPv6
Время туда-обратно	Round-Trip Time, RTT	Суммарное время в обе стороны, делить пополам нельзя
Время жизни	Time To Live, TTL	Счётчик переходов; в IPv6 называется Hop Limit
Плоскость управления	Control Plane	Процессор устройства: протоколы, CLI, служебные ответы
Плоскость данных	Data Plane / Forwarding Plane	Микросхемы, пересылающие транзитный трафик
Защита плоскости управления	Control Plane Policing, CoPP	Ограничение трафика, поднимающегося в процессор
Запрет фрагментации	Don't Fragment, DF	Флаг IPv4: не резать пакет, а отбросить
Разброс задержки	Jitter / delay variation	Колебание времени доставки между пакетами
Маркерное ведро	Token bucket	Ограничение средней скорости с разрешённым всплеском

11. Главное

ICMP — часть IP, а не надстройка над ним. Узел, который «не умеет ICMP», не является корректной реализацией IP.
Пинг до устройства и пинг сквозь устройство — разные измерения. Первое говорит только о процессоре и маршруте до него; судить о транзите по нему нельзя.
Молчание — не доказательство отказа. Эхо может быть отфильтровано; доступность сервиса проверяется обращением к сервису.
Смотри разброс, а не среднее. Один выброс в полсекунды среди быстрых ответов значит больше, чем приличная средняя цифра.
TTL в ответе — оценка обратного пути. Опорные значения: 64 в Linux и 128 по документации Microsoft.
Ping с запретом фрагментации — измерительный прибор. Он находит предельный размер пакета на пути без всякого оборудования.
ICMPv6 фильтровать целиком нельзя: на нём держится обнаружение соседей и автонастройка адресов.

12. Мост к следующему уроку

Мы научились отвечать на вопрос «доходит ли и за сколько». Но когда не доходит, немедленно возникает следующий: где именно. Ответ на него даёт трассировка — и она построена ровно на том счётчике TTL, который мы только что читали в ответах. В следующем уроке разберём, как из этого счётчика получается карта пути, почему в ответе виден адрес входящего интерфейса, и главное — почему звёздочки в середине трассы в четырёх случаях из пяти означают «всё в порядке».

13. Источники

RFC 792 — Internet Control Message Protocol: форматы Echo (тип 8) и Echo Reply (тип 0), Time Exceeded (тип 11), Destination Unreachable (тип 3, коды 0–5), правило о невложении ошибок в ошибки, возврат заголовка и первых 64 бит исходного пакета
RFC 1122, раздел 3.2.2.6 — требование реализовать эхо-сервер и вернуть данные неизменными
RFC 4443 — ICMPv6: типы 1, 2, 3, 128, 129; правило вложения исходного пакета; рекомендация ограничивать скорость маркерным ведром
Документация ядра Linux, ip-sysctl — ip_default_ttl (по умолчанию 64), icmp_ratelimit (по умолчанию 1000 мс), icmp_ratemask, icmp_echo_ignore_all
Microsoft Learn, TCP/IP configuration parameters — параметр DefaultTTL, диапазон 1–255, значение по умолчанию 128
RFC 1812, раздел 4.3.2.8 — разрешение маршрутизатору ограничивать частоту служебных сообщений, включая эхо-ответы, и названные мотивы: полоса обратного пути и ресурсы устройства
Cisco, Control Plane Policing — механизм защиты процессора устройства от потока адресованных ему пакетов