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

> Пинг не проходит, а сайт работает. В MTR потери на середине маршрута, а до сервера ноль. Разбираем, что меряет каждый инструмент и какие цифры можно выбросить.

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

## Что меряет ping

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

```bash
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 секунды на каждую.

**Схема:** Ты → (HTTPS) Cloudflare, напр. PRG → (SYN → SYN/ACK) Цель :порт

*Что меряет host.pink/ping: TCP-рукопожатие из дата-центра Cloudflare, который принял твой запрос, а не с твоего компьютера*


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

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

| Цель | min / avg / max | Потери |
|---|---|---|
| `8.8.8.8:53` | 1 / 2 / 3 мс | 0 из 4 |
| `193.0.11.51:443` (ripe.net) | 18 / 19 / 20 мс | 0 из 4 |

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

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

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

**ICMP ping (измерение 2V7vVJ0hZm3ZeAIxB00021BtB):**

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

**TCP-пинг :443 (измерение 2DmCvTPvdtSAqeCuv00021BtC):**

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



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

| | мс |
|---|---:|
| Амстердам, LeaseWeb | 3 |
| Фалькенштайн, Hetzner | 12 |
| Хельсинки, Hetzner | 32 |
| Москва, Timeweb (дом.) | 40 |
| Санкт-Петербург, Selectel | 42 |
| Москва, Yandex.Cloud | 48 |
| Нижний Новгород, Ростелеком (дом.) | 51 |
| Новосибирск, МТС (дом.) | 93 |
| Томск (дом.) | 93 |
| Алматы, G-Core | 97 |
| Сингапур, LeaseWeb | 162 |

*TCP-пинг ripe.net:443 (193.0.11.51), среднее из 3 попыток, пробы Globalping, измерение 2DmCvTPvdtSAqeCuv00021BtC, 24.09.2026. «дом.» означает домашнего провайдера*


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

| Проба | ICMP avg | TCP :443 avg |
|---|---|---|
| Москва, Timeweb (дом.) | 38,2 мс | 40,3 мс |
| Санкт-Петербург, Selectel | 38,1 мс | 38,9 мс |
| Нижний Новгород, Ростелеком (дом.) | 49,2 мс | 55,8 мс |
| Новосибирск, МТС (дом.) | 91,9 мс | 91,9 мс |
| Фалькенштайн, Hetzner | 10,7 мс | 11,0 мс |

> [!WARNING]
> В России обратная ситуация тоже частая. По опыту сообщества, ТСПУ режет трафик выборочно: ICMP проходит 3/3, а TCP 0/3 ([хронология, июнь 2026](/baza/hronologiya/2026-06/)), или наоборот, живо только TCP ([август 2026](/baza/hronologiya/2026-08/)). И даже живой TCP-пинг не значит, что работает протокол поверх него: «TCP-пинг ≠ ворк» ([ТСПУ: серверная часть](/baza/set/tspu-servernoe/)). Для VPN-ноды единственная честная проверка это настоящее подключение клиентом.

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

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

### Столбцы

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

| Столбец | Что это |
|---|---|
| `Loss%` | доля пакетов без ответа от этого хопа |
| `Snt` | сколько отправлено |
| `Last` | RTT последнего ответа |
| `Avg` | средний RTT |
| `Best` / `Wrst` | минимальный и максимальный RTT |
| `StDev` | стандартное отклонение RTT |

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 пакета на хоп:

```text
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% потерь.

> [!IMPORTANT]
> Потери или скачок задержки на промежуточном хопе, которые **не продолжаются** на следующих хопах, не проблема. Если бы роутер правда терял транзитные пакеты, потери были бы видны на всех хопах после него, включая цель. Роутеры ограничивают частоту генерации ICMP (RFC 1812, раздел 4.3.2.8) и отдают ему низкий приоритет; раздел BUGS в man mtr прямо говорит, что из-за этого mtr показывает надёжность таких роутеров значительно хуже реальной.

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

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

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

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

### Команды

```bash
# отчёт: 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](https://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 это Россия (дом.), Германия и США.
- Сайт не открывается из РФ целиком: [отдельный разбор по шагам](/gaidy/sayt-ne-otkryvaetsya-iz-rf/). Пинг есть, а большие пакеты через туннель не проходят: [MTU и туннели](/gaidy/mtu-i-tunneli/).

## Источники

- [RFC 792](https://www.rfc-editor.org/rfc/rfc792): Echo (тип 8) и Echo Reply (тип 0); Time Exceeded, роутер «may send»
- [RFC 9293](https://www.rfc-editor.org/rfc/rfc9293), раздел 3.5: трёхстороннее рукопожатие
- [RFC 1812](https://www.rfc-editor.org/rfc/rfc1812), раздел 4.3.2.8: ограничение частоты ICMP на роутерах, в том числе Echo Reply
- [RFC 7679](https://www.rfc-editor.org/rfc/rfc7679), раздел 1.1: асимметричные пути, RTT меряет два пути сразу
- [ping(8), iputils](https://manpages.debian.org/bookworm/iputils-ping/ping.8.en.html): ECHO_REQUEST, mdev
- [mtr(8)](https://github.com/traviscross/mtr/blob/master/man/mtr.8.in): принцип работы, `-r -w -z -b -c -T -P`, поля `-o`, раздел BUGS про приоритет ICMP; [ui/mtr.c](https://github.com/traviscross/mtr/blob/master/ui/mtr.c): заголовки столбцов и порядок по умолчанию `LS NABWV`
- Richard A. Steenbergen, [A Practical Guide to (Correctly) Troubleshooting with Traceroute](https://archive.nanog.org/meetings/nanog47/presentations/Sunday/RAS_Traceroute_N47_Sun.pdf), NANOG 47: rate limiting и приоритет ICMP, «скачки задержки посередине ничего не значат, если не продолжаются», асимметричные пути
- [Google Public DNS FAQ](https://developers.google.com/speed/public-dns/faq): anycast
- [Cloudflare Workers, TCP sockets](https://developers.cloudflare.com/workers/runtime-apis/tcp-sockets/): `connect()`, `opened`; код `/ping` и `/check` host.pink
- [Спецификация API Globalping](https://api.globalping.io/v1/spec.yaml): 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
- База: [ТСПУ: серверная часть](/baza/set/tspu-servernoe/), [Хронология 2026-06](/baza/hronologiya/2026-06/), [Хронология 2026-08](/baza/hronologiya/2026-08/)

---
Источник: https://host.pink/gaidy/ping-tcp-ping-mtr/
Лицензия: CC BY-SA 4.0