Что делает mtr и где он доступен
Mtr многократно отправляет пробные пакеты по маршруту и на каждом узле накапливает статистику: процент потерь, последнее, среднее, лучшее и худшее время ответа. Это делает его удобнее, чем однократный traceroute, потому что одиночные всплески усредняются, а систематические проблемы проявляются в цифрах.
В Linux mtr ставится из репозитория дистрибутива, часто в двух вариантах: с графическим интерфейсом и без. В macOS его обычно устанавливают через менеджер пакетов, и запускать нужно с правами администратора. В Windows штатной версии нет, вместо неё используют отдельные программы с тем же принципом, например WinMTR, или запускают mtr внутри подсистемы Linux.
Запуск в интерактивном режиме: mtr example.com. Экран обновляется каждую секунду, выход по клавише q. Для сохранения результата есть режим отчёта, о нём подробнее на странице про отчёт для провайдера.
Обратите внимание, что mtr удобно запускать не один раз, а параллельно в разное время суток. Многие проблемы носят вечерний характер: канал перегружается только в часы пик, и утренний тест покажет идеальную картину. Чтобы сравнить, сохраните два отчёта и сопоставьте их по столбцам Loss% и Avg.
Столбцы таблицы и их смысл
Стандартная таблица содержит следующие поля.
| Столбец | Значение |
|---|---|
| Host | Адрес или имя узла на маршруте |
| Loss% | Процент пакетов, оставшихся без ответа на этом узле |
| Snt | Сколько запросов отправлено |
| Last | Время последнего ответа, мс |
| Avg | Среднее время ответа, мс |
| Best | Лучшее (минимальное) время, мс |
| Wrst | Худшее (максимальное) время, мс |
| StDev | Стандартное отклонение, показывает разброс |
Пример (пример, адреса из блока документации):
Host Loss% Snt Last Avg Best Wrst StDev 1. 192.0.2.1 0.0% 50 0.5 0.5 0.4 0.9 0.1 2. 198.51.100.1 0.0% 50 3.2 3.3 3.0 5.1 0.3 3. 203.0.113.9 30.0% 50 12.0 12.4 11.5 40.2 4.1 4. 203.0.113.50 0.0% 50 25.1 25.3 24.8 27.0 0.4
Обратите внимание на строку 3: потери 30 процентов, но следующий узел не показывает потерь. Это классический пример ложной тревоги.
Как отличить настоящую потерю от ложной
Главное правило чтения: смотрите не на один узел, а на то, что происходит дальше по маршруту. Многие маршрутизаторы обрабатывают транзитный трафик быстро, а на служебные запросы, которыми пользуется mtr, отвечают в последнюю очередь и с ограничением скорости. В таблице это выглядит как потери на промежуточном узле.
- Если потери есть на узле, но конечный узел показывает 0 процентов, реальной проблемы нет: транзитные пакеты проходят.
- Если потери начались на некотором узле и сохраняются на всех следующих вплоть до цели, проблема именно с этого места.
- Если потери только на последнем узле, вероятно, цель ограничивает ответы на ICMP, либо потери настоящие и возникают на последнем участке. Сравните с реальной работой приложения.
- Если время ответа скачет на одном узле (большой Wrst, высокий StDev), но на следующих спокойно, это тоже особенность обработки служебных запросов.
Так что сначала посмотрите на строку цели, затем ищите первый узел, начиная с которого проблема не пропадает. Именно его и надо называть в обращении к провайдеру.
Полезно обращать внимание и на столбец Best: он показывает минимально достижимое время на этом узле, то есть примерно физическую задержку линии без очередей. Большая разница между Best и Avg указывает на очереди и перегрузку, а высокий StDev на нестабильность. Для домашнего канала с хорошим качеством разброс должен быть небольшим.
Полезные ключи и режимы зондирования
По умолчанию mtr использует ICMP, но при необходимости режим меняют. Приведём ключи, в которых мы уверены.
- -n не разыскивает имена узлов и ускоряет работу.
- -c число завершает работу после заданного числа отправленных запросов, что удобно для отчётов.
- -r включает режим отчёта: mtr выполняет заданное число циклов и печатает итоговую таблицу без интерактивного экрана.
- -w выводит имена узлов полностью, без сокращения.
- -b показывает и имена, и адреса.
- -i секунды меняет интервал между запросами.
- -u использует UDP вместо ICMP, а -T включает TCP, порт задаётся ключом -P.
Режим TCP пригоден, когда ICMP отфильтрован, а нужный порт (например 443) открыт. Не задавайте слишком малый интервал: частые запросы создают лишнюю нагрузку и могут привести к искусственным потерям из-за ограничений узлов. Сканирование и зондирование чужих узлов с высокой частотой недопустимо, диагностируйте только свои маршруты.
Отдельное замечание про безопасность: mtr отправляет запросы, которые могут восприниматься как сканирование, если запускать его с очень малым интервалом или массово. Оставляйте интервал по умолчанию и запускайте диагностику только для своих маршрутов.
Порядок диагностики с mtr
Работайте последовательно, чтобы результат можно было повторить.
- Запустите mtr -n -c 100 -r к проблемному узлу и сохраните итог. Сто циклов дают минимальную устойчивость статистики.
- Найдите первый узел, с которого потери сохраняются до цели.
- Определите, чей это узел: ваш роутер, оборудование провайдера или внешняя сеть. Первые один-два перехода обычно ваши.
- Повторите измерение в другое время суток и при проводном подключении, чтобы исключить влияние Wi-Fi.
- При необходимости смените режим на TCP и сравните.
Учитывайте, что mtr показывает только прямой путь. Потери на обратном пути видны косвенно, поэтому идеально снять данные и с другой стороны, если это возможно. Общее знакомство с идеей трассировки полезно начать со страниц про tracert и traceroute.