Что такое ICMP и как устроен ping
Ping отправляет узлу назначения пакет ICMP Echo Request — эхо-запрос — и ждёт в ответ Echo Reply. Пришёл ответ, значит узел доступен на сетевом уровне и обратный маршрут до вас тоже существует. Это важная деталь: ping проверяет дорогу в обе стороны сразу, и молчание может означать проблему как туда, так и обратно.
ICMP — отдельный протокол, работающий поверх IP, но не поверх TCP или UDP. Портов у него нет, поэтому «закрыть ICMP на порту» невозможно в принципе: блокировка делается отдельным правилом фаервола по типу протокола.
ICMP занимается не только пингом
Эхо-запросы — лишь один из типов сообщений. Тем же протоколом сеть сообщает об ошибках: «узел недоступен», «сеть недоступна», «превышено время жизни пакета», «нужна фрагментация». Последнее сообщение особенно важно — именно им определяется рабочий размер пакета на маршруте, и когда ICMP режут полностью, ломается механизм определения MTU. Симптом тот самый: мелкие пакеты ходят, крупные пропадают, сайты открываются наполовину.
Как читать вывод
В строке ответа четыре полезных числа: размер пакета, адрес, TTL и время. Время ответа (RTT) показывает, сколько заняла дорога туда и обратно. Для локальной сети это доли миллисекунды, для сервера в том же городе — единицы, для другого континента — сотни.
Что видим | О чём говорит |
|---|---|
Стабильные 0,2–1 мс в локальной сети | Норма |
Время скачет от 2 до 300 мс | Перегрузка канала или проблемы с Wi-Fi |
Потери 1–2% на Wi-Fi | Обычно терпимо |
Любые стабильные потери на проводе | Ищите проблему на L1/L2 |
Destination host unreachable | Ответил маршрутизатор: он не знает, куда дальше |
Request timed out | Ответа нет вовсе — узел молчит или фильтрует |
Разница между двумя последними строчками принципиальна. «Host unreachable» — это ответ от кого-то по пути, то есть сеть до этого места работает. «Timed out» — полная тишина, и причина может быть где угодно, включая обратный маршрут.
Полезные ключи
Непрерывный пинг для наблюдения за нестабильной линией: ping -t в Windows, в Linux он такой по умолчанию. Проверка прохождения крупных пакетов без фрагментации: ping -f -l 1472 адрес в Windows или ping -M do -s 1472 адрес в Linux — если такие пакеты не проходят, а мелкие идут, вы нашли проблему с MTU.
Почему ping не проходит
ICMP заблокирован. Узел жив и прекрасно работает, просто не отвечает на эхо-запросы. Windows-машины по умолчанию так себя и ведут: фаервол блокирует пинг из чужой сети.
Узел действительно недоступен. Выключен, обрыв, неверный адрес.
Проблема с маршрутом. Узел в другой сети, а шлюз не настроен или сам не знает дороги.
Обратный маршрут. Ваш запрос дошёл, ответ вернуться не может — типично для неправильно настроенных VPN.
Не тот интерфейс. На машине несколько сетевых карт, и пакет уходит не туда, куда вы думаете.
Главный вывод отсюда: отсутствие ответа на ping — не доказательство того, что узел мёртв. Проверять доступность сервиса надёжнее подключением к его порту: telnet host 443 или curl -v. Сервер может молчать на пинг и при этом прекрасно отдавать сайт.
Чем ping отличается от traceroute и mtr
Ping отвечает на один вопрос: доступен ли узел и с какой задержкой. Где именно по пути возникает проблема, он не показывает. Для этого есть traceroute — он использует тот же ICMP, но хитрее: отправляет пакеты с постепенно растущим TTL и по сообщениям «время жизни истекло» выстраивает список промежуточных узлов.
Ещё удобнее mtr (в Windows — WinMTR): он совмещает оба инструмента, непрерывно пингуя каждый узел маршрута и показывая потери по каждому переходу в реальном времени. Именно им ловят плавающие проблемы, которые за один прогон traceroute не видны.
Как не ошибиться при чтении traceroute
Две типичные ошибки интерпретации. Первая: звёздочки в середине маршрута не означают обрыв — многие маршрутизаторы просто не отвечают на служебные пакеты, продолжая передавать транзитный трафик. Обрыв — это когда звёздочки идут до самого конца.
Вторая: всплеск задержки на промежуточном узле сам по себе ни о чём не говорит. Генерация ответа для маршрутизатора — низкоприоритетная задача, и он вполне может отвечать вам за 200 мс, передавая чужие пакеты за микросекунды. Смотреть нужно на то, растёт ли задержка на всех последующих переходах.
Когда одного ping недостаточно
Ping работает поверх IP, то есть на третьем уровне. Всё, что происходит ниже, он видит только косвенно — по потерям. Обрыв в кабеле, плохой патч-корд, реальная длина линии, перепутанные пары — для этого нужны отдельные приборы: кабельные тестеры и другие инструменты.
Сверху ограничение такое же. Успешный пинг ничего не говорит о том, работает ли на сервере нужная служба. Сервер может отвечать на эхо-запросы, пока база данных лежит, а веб-сервер не запущен. Поэтому цепочка проверки обычно такая: ping — есть ли сеть, проверка порта — слушает ли служба, запрос curl или логи — отвечает ли приложение и что именно.
И последнее наблюдение из практики: пинговать имеет смысл не только конечный узел, но и свой шлюз. Если до шлюза потери есть, дальше можно не искать — проблема в вашем сегменте, и виновата почти наверняка физика.
Почему ping ничего не говорит о скорости
Распространённое заблуждение: чем меньше пинг, тем быстрее интернет. Это разные характеристики. Задержка — время, за которое маленький пакет добирается туда и обратно. Пропускная способность — сколько данных помещается в канал за секунду. Спутниковый канал может давать сотню мегабит при задержке в 600 мс, а мобильный интернет — отвечать за 30 мс и не вытягивать видеозвонок.
Для интерактивных вещей — игр, голоса, удалённого рабочего стола — важнее именно задержка и её стабильность. Разброс задержки называют джиттером, и в звуке он слышен лучше любых цифр: голос начинает «плыть» и заикаться, хотя средний пинг выглядит приличным.
Как увидеть джиттер
Запустите непрерывный пинг на пару минут и посмотрите не на среднее значение, а на разброс между минимумом и максимумом. Ровные 25–28 мс — здоровый канал. Скачки от 20 до 400 при том же среднем — канал перегружен, и первым делом стоит посмотреть, не качает ли кто-нибудь в сети что-то тяжёлое.
