Ping воспринимается как команда из двух слов, которую новичок вбивает, чтобы понять, есть интернет или нет. Сетевой инженер видит в ней измерительный прибор: ICMP echo умеет менять размер полезной нагрузки, запрещать фрагментацию, считать потери, показывать джиттер и даже вскрывать скрытые издержки инкапсуляции в туннелях. Эта статья превращает ping из индикатора "работает/не работает" в инструмент точной диагностики: от поиска реального MTU бинарным поиском до отличия буферблоата на WiFi от перегрузки магистрали.
Структура пакета и предел 1500 байт
Классический канал Ethernet ограничен размером кадра. MTU в 1500 байт означает, что IP-пакет целиком обязан поместиться в один кадр. Внутри этих 1500 байт лежат: 20 байт заголовка IPv4 и 8 байт заголовка ICMP. Остаётся 1472 байта полезных данных. Именно это число объясняет знаменитый параметр "ping -f -l 1472" в Windows: ключ -l задаёт размер данных, а ключ -f устанавливает бит Don't Fragment в IP-заголовке.
Если пакет с установленным DF-битом упирается в линк с меньшим MTU, маршрутизатор не имеет права его резать. Он выбрасывает пакет и шлёт назад ICMP-сообщение Fragmentation Needed (тип 3, код 4), где указывает MTU проблемного сегмента. Windows выводит знакомое "Требуется фрагментация пакета, но установлен запрещающий флаг". Это и есть механизм Path MTU Discovery, описанный в RFC 1191: хост отправляет пакет с DF, получает ошибку, уменьшает размер и пытается снова, пока путь не скажет своё реальное значение.
Важный нюанс из практики: ключ -l принимает размер именно ICMP-данных, без заголовков. Поэтому 1472 плюс 8 плюс 20 дают ровно 1500. Кто считает от 1500, тот сразу получает фрагментацию на чистом Ethernet и делает ложный вывод о проблемах провайдера.
Бинарный поиск реального MTU на пути
Когда значение 1472 проходит, канал честный, MTU равен 1500, и дальше можно не копать. Когда приходит "frag needed", начинается измерение. Делить пополам привычный диапазон неудобно без калькулятора, поэтому опытные инженеры используют типовые значения туннелей, а строгий бинарный поиск применяют уже локально.
Практический сценарий с PPPoE-линком выглядит так:
- ping -f -l 1472 8.8.8.8 - фрагментация запрещена, пакет отброшен, приходит ошибка.
- ping -f -l 1464 8.8.8.8 - пакет проходит. 1464 + 28 = 1492, классическое значение PPPoE.
- ping -f -l 1465 8.8.8.8 - снова отказ, значение 1492 подтверждено как реальный предел.
PPPoE крадёт ровно 8 байт: поле протокола из 2 байт и заголовок PPP из 6 байт, потому что клиентская сессия поверх Ethernet оставляет кадру те же 1500. GRE-туннель забирает 24 байта (20 нового IP плюс 4 GRE), IPsec в туннельном режиме добавляет до 40 байт в зависимости от шифра и аутентификации. Каждый туннель - это невидимая ступенька вниз по лестнице MTU, и ping с -f показывает эти ступеньки без сниффера.
MTU blackhole и странные зависания TCP
Худший сценарий выглядит не как ошибка, а как тишина. Когда на пути файрвол режет весь ICMP (а это делают на удивление часто из ложных соображений безопасности), сообщение Fragmentation Needed до отправителя не доходит. Хост отправляет пакет 1500 байт, тот молча исчезает в туннеле, ретрансмит повторяет судьбу первого. При этом ping размером 32 байта летает отлично.
Симптомы классические: соединение устанавливается, мелкие ответы приходят, а любой большой ответ (загрузка файла, длинная веб-страница, TLS-сертификат с цепочкой) зависает на ровном месте. Path MTU Discovery сломан, механизм blackhole срабатывает: ICMP blocked на промежуточном железе убивает обратную связь. Диагностируется всё это именно ping с -f и большим -l: мелкий пинг проходит, большой пропадает без единого сообщения - значит, ICMP где-то вырезан.
Лечение известно: на серверной стороне включают MSS clamping, значение TCP MSS принудительно занижают до 1452 или около того на граничном маршрутизаторе, и хосты перестают генерировать пакеты, которые путь не переваривает. На Windows проверяют собственный стек через "netsh interface ipv4 show subinterfaces": там видно, какой MTU выставлен на интерфейсе, и не занижен ли он пользователем вручную до неадеквата.
Флаги ping, которые реально используются
Помимо -f и -l у Windows-версии есть рабочий набор переключателей:
- -t: непрерывный поток запросов до Ctrl+C, удобен для наблюдения за живым каналом во время изменений.
- -n счётчик: фиксированное число запросов, например "ping -n 50", чтобы получить чистую статистику потерь.
- -w миллисекунды: таймаут ожидания ответа, полезен на спутниковых и мобильных каналах, где 1000 мс по умолчанию - слишком мало.
- -a: обратный резолв IP-адреса в имя через PTR-запись.
- -i значение: Time To Live, позволяет ограничить дальность пакета или отловить сеть с малым TTL.
- -6: принудительный IPv6, в паре с ним меняются и размеры заголовков - полезная нагрузка при MTU 1500 становится 1452 байта из-за расширенного заголовка IPv6 в 40 байт.
В Linux эквиваленты отличаются: -M do вместо -f, -s вместо -l, -W в секундах. Принципы идентичны, синтаксис другой. Инженер держит оба набора в голове, потому что диагностика редко ведётся только с одной платформы.
Интервал и размер серии тоже инструмент. Запуск с минимальным интервалом (flood-подобный режим для администратора, ping -t в Windows хотя и без точного тайминга) наполняет очереди мгновенно и вскрывает ёмкость буферов: ровное время вдруг превращается в лес выбросов через минуту. Длинная серия на противоположном краю полезна для редких болезней: ночные провалы через триста секунд видны только на длинном логе с метками времени. Парный приём - запись в файл через перенаправление и параллельный ping до контрольной точки: куда полез трафик в момент просадки, видно по разнице серий, а не по гаданию.
Ещё один недооценённый параметр - содержимое пакета. Windows ping позволяет задать шаблон данных (ключ -l задаёт размер, содержимое фиксировано), а в инструментах посложнее полезное тело генерируется случайным. Разница не косметическая: на каналах со сжатием (старые модемные пулы, WAN-оптимизаторы) нули сжимаются идеально, а случайные данные - никак, и обнаружить компрессирующий участок можно прямо по разнице двух прогонов одного размера. Это редкая диагностика, но именно она объясняет, почему обещанная провайдером скорость держится только на тестовых зипах.
Отдельный приём - мониторинговая петля по расписанию. Скрипт с ping -n 600 >> C:\logs\wan.txt, добавленный в планировщик, даёт хронологию канала на неделю: статистика питания провайдера, часы активности соседей по WiFi, старения оптики. Когда клиент говорит «вчера вечером всё падало», такой лог отвечает цифрами, а не воспоминаниями.
Время отклика против джиттера и потерь
Среднее время пинга - один из самых обманчивых показателей в сетевой диагностике. Десять пакетов по 20 мс и один по 400 мс дают среднее около 55 мс, которое выглядит приемлемо, хотя канал в этот момент буквально захлёбывался. Минимум показывает, на что способен пустой путь; максимум и разброс показывают, как он себя ведёт под очередями. Итоговая сводка ping выводит все три числа, и смотреть надо на все три.
Процент потерь важнее времени. Один потерянный пакет из ста - это уже плохо для голоса, видеоконференций и любого чувствительного трафика: TCP воспринимает потерю как перегрузку и режет окно передачи, UDP-приложение просто теряет кадр. Потери 3-5 процента означают канал, где скорость упадёт непропорционально сильно, даже если средний пинг прекрасен. Джиттер - разброс задержки между соседними ответами - считается не по голому выводу ping, а по серии: ровные значения дают джиттер около нуля, прыжки 18, 25, 90, 22 мс говорят о переменной очереди где-то на пути.
Причина джиттера частая и бытовая: буферблоат. Когда исходящий канал забивается закачкой, роутер складывает пакеты в глубокую очередь, чтобы не терять их. ICMP-эхо ждёт в этой очереди вместе со всеми. Отсюда феномен: пинг до первого узла провайдера 8 мс в простое и 120 мс под нагрузкой. Канал не сломан - он жирный и медленно переваривается. Тест простой: запустить ping -t до шлюза, параллельно включить максимальную загрузку и посмотреть, во сколько раз выросла задержка.
WiFi против кабеля
На беспроводном линке пинг до собственного роутера - диагностический шедевр. Кабель даёт значения 1 мс с почти нулевым разбросом. WiFi в чистом эфире держит 2-4 мс, WiFi в жилом доме с соседскими сетями на том же канале прыгает от 3 до 200 мс без всякой нагрузки. Причина - механизм доступа к среде: перед каждой передачей клиент слушает эфир, ждёт случайное окно, передаёт, ждёт подтверждения. Конкуренция с соседями растягивает эти окна, и пинг первым же отражает это.
Практический вывод: любую жалобу на "медленный интернет" инженер проверяет двумя сериями пинга - одна с кабеля напрямую в роутер, вторая через WiFi с того же места, где жалуется пользователь. Различие между ними принадлежит эфиру, а не провайдеру. Смена канала, переход на 5 ГГц или перенос точки доступа решают проблему, которую иначе искали бы у магистрали.
Трассировка и чтение маршрута
tracert использует тот же принцип: пакеты с нарастающим TTL, и каждый маршрутизатор, где TTL истёк, присылает Time Exceeded. Номер строки - это номер хопа. Читается таблица слоями. Первый хоп - собственный роутер, его задержка выше 3 мс по кабелю уже подозрительна. Второй и третий хопы - оборудование провайдера, доступ и агрегация, там нормальны единицы миллисекунд в городе. Дальше идут магистральные узлы, их адреса обычно содержат имена городов в PTR-записях (ключ -a у ping делает то же для одиночного адреса), по ним видно географию пути.
Скачок задержки между соседними строками показывает, где пакет садится на длинный линк. 2 мс до третьего хопа и 40 мс до четвёртого - значит, между ними лежит межгород или транзит через границу регионов. Время от строки к строке не складывается: это полный путь от источника до данного узла, а не плечо от предыдущего.
Более полезный инструмент - mtr (или WinMTR на Windows), он совмещает трассировку и многократный пинг: каждый хоп получает серию запросов, и статистика потерь считается отдельно по каждому узлу. Классическая путаница новичков: один промежуточный хоп показывает 50% потерь, а последний - чистый ноль. Это не потери на пути: маршрутизатор занят форвардингом и отвечает на ICMP с низким приоритетом, либо вовсе лимитирует генерацию ответов. Судить о проблемах можно только по последнему хопу и по точке, после которой потери нарастают и не отпускают до конца пути.
Границы доверия к пингу
Ping - это ICMP, а ICMP на реальном железе обрабатывается не так, как полезный трафик. Маршрутизаторы генерируют эхо-ответы на контрол-плейне, процессорным путём, с низшим приоритетом. Под нагрузкой устройство честно форвардит гигабиты пользовательских данных и при этом задерживает ответы на ICMP на десятки миллисекунд, потому что процессор занят таблицами маршрутизации. Картина по пингу будет хуже реального состояния канала.
Обратная ситуация тоже встречается: провайдер ставит эхо-запросы в высокоприоритетную очередь, чтобы демонстрационный пинг блистал, а обычный трафик терпит очереди. Поэтому ни один инженер не делает серьёзных выводов по пингу в одиночку. Для оценки скорости и потерь реального трафика запускают TCP-тесты, для игрового трафика - измерение именно UDP до конкретного сервера, а ping остаётся первым дешёвым экраном: быстро, встроено в любую систему, не требует установки.
Итоговая методика выглядит так: сначала ping до локального шлюза - отсекает дом; потом ping до первого адреса провайдера - отсекает доступ; потом ping -f -l с бинарным поиском - проверяет MTU и туннели; потом mtr до целевого хоста - показывает, где на пути портится картина. Четыре шага занимают десять минут и локализуют 90% сетевых неисправностей раньше, чем успеет загрузиться тяжёлый мониторинг.