ping, TCP-пинг и MTR: что на самом деле меряют и как читать

Пинг — первое, что запускают, и первое, чему зря верят. Он честно меряет ровно одну вещь, и почти никогда не ту, о которой спрашивают.

#Что меряет ping

ping шлёт ICMP Echo Request (тип 8) и ждёт Echo Reply (тип 0): получатель меняет местами адреса и возвращает те же данные (RFC 792). Результат это RTT, время туда и обратно, плюс потери. mdev в итоговой строке iputils ping это стандартное отклонение RTT: чем он больше, тем сильнее скачет задержка (man ping).

ping -c 20 203.0.113.10

Что пинг не говорит:

• Работает ли сервис. На echo отвечает сетевой стек хоста, до nginx или Xray запрос не доходит.
• Жив ли сервер. Файрвол может резать ICMP целиком. Об этом ниже, на реальном примере.
• Задержку в одну сторону. RTT нельзя честно поделить пополам: путь туда и путь обратно в интернете часто разные (асимметричные), и очереди на них тоже разные (RFC 7679, раздел 1.1). Для настоящей односторонней задержки нужны синхронизированные часы на обоих концах.

#TCP-пинг

TCP-пинг открывает TCP-соединение на конкретный порт и засекает время до установки. По RFC 9293 клиент переходит в ESTABLISHED, как только получил SYN/ACK в ответ на свой SYN, так что это тоже один RTT, только измеренный пакетами, которые файрвол обязан пропустить, если сервис работает. Закрытый порт отвечает RST, и это тоже информация: хост жив, сервиса нет.

#Что меряет host.pink/ping

Страница /ping работает в Cloudflare Workers, а там нет ICMP. Поэтому она открывает TCP-сокет (connect()) и ждёт промис opened, который разрешается, когда соединение установлено. Четыре попытки, таймаут 3 секунды на каждую.

curl "host.pink/ping/8.8.8.8:53"

Замер 24.09.2026, запрос обслужил дата-центр PRG (Прага):

Два следствия. Во-первых, цифра зависит от того, какой эдж Cloudflare принял запрос, а не от того, где сидишь ты. Во-вторых, 1–3 мс до 8.8.8.8 не значат, что Google рядом с твоим сервером: Google Public DNS отвечает через anycast, запрос уходит на ближайший сервер (Google Public DNS FAQ). Пинг до anycast-адреса, CDN или любого фронта за Cloudflare показывает расстояние до ближайшей точки присутствия, а не до origin.

#Когда пинг врёт: реальный пример

ripe.net с 12 проб Globalping, одна и та же минута:

RU Moscow      нет ответа, потерь 3/3
DE Falkenstein нет ответа, потерь 3/3
NL Amsterdam   нет ответа, потерь 3/3
... и так все 12 проб

RU Moscow      40 мс, потерь 0/3
DE Falkenstein 12 мс, потерь 0/3
NL Amsterdam    3 мс, потерь 0/3
... все 12 проб ответили

По ICMP сервер «мёртв» из всех стран, по TCP жив из всех стран. Сайт при этом открывается. Вывод: 100% потерь в ping сами по себе ничего не доказывают, проверяй порт сервиса.

А когда ICMP не режут, ICMP и TCP дают почти одно и то же. Те же пробы, цель wikipedia.org, 24.09.2026 (измерения 2amYG2fgVWVSYSy2o00021BtD и 2szFNO7u4NXz78QVM00021BtD):

#MTR: трассировка плюс пинг

mtr шлёт пакеты с заниженным TTL. Роутер, на котором TTL обнулился, выбрасывает пакет и может (не обязан, RFC 792) прислать ICMP Time Exceeded. По этим ответам mtr строит список хопов и для каждого копит статистику, как ping (man mtr).

#Столбцы

По умолчанию mtr показывает поля LS NABWV (исходник ui/mtr.c):

Globalping (и host.pink/check/…?t=mtr) выводит другой набор: Loss% Drop Rcv Avg StDev Javg. Drop и Rcv это потерянные и полученные пакеты, Javg средний джиттер (поле M, «Jitter Mean/Avg»).

#Разбор реального MTR

host.pink/check/wikipedia.org?t=mtr, измерение 2612wDvlSIGwRBIL200021BtC, 24.09.2026. Домашняя проба МТС в Новосибирске, по 3 пакета на хоп:

Host                                                                        Loss% Drop Rcv  Avg  StDev  Javg
 1. AS8359  _gateway (5.227.161.161)                                         0.0%    0   3  5.1    4.3   5.6
 2. AS8359  bhm-cr04-eth-trunk3.nsk.mts-internet.net (212.188.52.32)         0.0%    0   3  4.2    3.3   4.3
 3. AS8359  psshag-cr01-ae12.0.chel.mts-internet.net (195.34.50.153)         0.0%    0   3 92.0    1.7  47.6
 4. AS8359  che-cr02-ae10.63.sam.mts-internet.net (212.188.42.129)           0.0%    0   3 94.1    2.6  48.9
 5. AS8359  a433-cr06-eth-trunk13.msk.mts-internet.net (212.188.1.181)       0.0%    0   3 49.4    0.1  24.7
 6. AS8359  anc-cr02-eth-trunk26.277.ff.mts-internet.net (212.188.42.122)    0.0%    0   3 86.6    3.3  45.8
 7. AS8359  tct-cr11-eth-trunk5.ams.mts-internet.net (212.188.42.16)         0.0%    0   3 91.9    0.0  45.9
 8. AS???   ae1-380.cr1-esams.wikimedia.org (80.249.209.176)                 0.0%    0   3 90.1    0.4  45.3
 9. AS???   (waiting for reply)
10. AS14907 wikipedia.org (185.15.59.224)                                    0.0%    0   3 92.0    0.0  46.0

Что тут читать:

1. Последняя строка главная. До цели 92 мс, потерь 0%.
2. Хоп 5 (msk в имени, 49 мс) «быстрее» хопов 3 и 4 (92–94 мс). RTT промежуточного хопа складывается из пути туда, времени, за которое роутер соизволил сгенерировать ICMP, и пути ответа обратно. Генерация ICMP идёт на медленном процессоре роутера, а обратный путь у каждого хопа свой (NANOG 47, Steenbergen). Поэтому RTT по хопам не обязан расти монотонно.
3. Хоп 9 молчит (waiting for reply), но хоп 10 отвечает без потерь. Этот роутер просто не присылает Time Exceeded. У пробы в Фалькенштайне в том же замере молчат хопы 3, 4, 10 и 11, а цель тоже отвечает с 0% потерь.

Как отличить настоящую проблему:

• потери начинаются на хопе N и держатся до конца, включая цель: это настоящие потери;
• 100% потерь только на последнем хопе, остальные чистые: цель не отвечает на ICMP, как ripe.net выше. Проверь TCP (mtr -T) и порт сервиса;
• всё чисто, а медленно или с потерями: проблема может быть на обратном пути, которого трассировка не видит.

#Асимметрия: обратного пути не видно

MTR показывает хопы только прямого пути, но RTT включает и обратный. Обратный путь для трассировки невидим, и он может быть разным для каждого хопа (NANOG 47). Выход один: mtr в обе стороны, с клиента на сервер и обратно.

#Команды

# отчёт: 100 циклов, ASN каждого хопа, имена и IP без обрезки
mtr -rwzb -c 100 203.0.113.10

# если ICMP режут, трассировка TCP SYN на порт сервиса
mtr -rwzb -T -P 443 -c 100 203.0.113.10

-r режим отчёта, -w широкий отчёт без обрезки имён, -z номера AS, -b имена и IP, -c число циклов, -T TCP SYN вместо ICMP Echo, -P порт (man mtr). Три пакета на хоп, как в быстрой проверке Globalping, хватит, чтобы увидеть маршрут, но мало для процента потерь: одна потеря из трёх уже 33%.

#Проверить на host.pink

• host.pink/ping/8.8.8.8:53: TCP-пинг с эджа Cloudflare, подставь свой IP и порт.
• host.pink/check/<хост>?t=ping, ?t=tcp, ?t=mtr: ICMP, TCP и MTR с проб Globalping, включая домашних провайдеров РФ. Для MTR это Россия (дом.), Германия и США.
• Сайт не открывается из РФ целиком: отдельный разбор по шагам. Пинг есть, а большие пакеты через туннель не проходят: MTU и туннели.

#Источники

• RFC 792: Echo (тип 8) и Echo Reply (тип 0); Time Exceeded, роутер «may send»
• RFC 9293, раздел 3.5: трёхстороннее рукопожатие
• RFC 1812, раздел 4.3.2.8: ограничение частоты ICMP на роутерах, в том числе Echo Reply
• RFC 7679, раздел 1.1: асимметричные пути, RTT меряет два пути сразу
• ping(8), iputils: ECHO_REQUEST, mdev
• mtr(8): принцип работы, -r -w -z -b -c -T -P, поля -o, раздел BUGS про приоритет ICMP; ui/mtr.c: заголовки столбцов и порядок по умолчанию LS NABWV
• Richard A. Steenbergen, A Practical Guide to (Correctly) Troubleshooting with Traceroute, NANOG 47: rate limiting и приоритет ICMP, «скачки задержки посередине ничего не значат, если не продолжаются», асимметричные пути
• Google Public DNS FAQ: anycast
• Cloudflare Workers, TCP sockets: connect(), opened; код /ping и /check host.pink
• Спецификация API Globalping: ping по ICMP и TCP, поля stats (min, avg, max, total, rcv, drop, loss), повторное использование проб по id измерения
• Замеры 24.09.2026: Globalping 2V7vVJ0hZm3ZeAIxB00021BtB, 2DmCvTPvdtSAqeCuv00021BtC, 2amYG2fgVWVSYSy2o00021BtD, 2szFNO7u4NXz78QVM00021BtD, 2612wDvlSIGwRBIL200021BtC; host.pink/ping из PRG
• База: ТСПУ: серверная часть, Хронология 2026-06, Хронология 2026-08