MTR
Сочетание traceroute и ping — непрерывная статистика по хопам с потерями пакетов.
О инструменте «MTR»
Объединяет traceroute и ping в один непрерывный тест, отправляя повторные пробы к каждому хопу на пути и агрегируя статистику потерь и задержки (среднее, лучшее, худшее, джиттер) по хопам, а не разовый снимок. Одиночный traceroute показывает лишь один момент времени — именно непрерывная выборка MTR фиксирует периодические потери пакетов на конкретном хопе, которые разовый ping или traceroute никогда не покажут. Джиттер часто информативнее для приложений реального времени вроде VoIP или игр, где стабильность важнее скорости.
Потери пакетов на промежуточном узле не обязательно означают реальные потери на этом участке пути — многие маршрутизаторы понижают приоритет собственных ICMP-ответов, используемых для traceroute/MTR, поэтому потери, исчезающие к финальному узлу, обычно являются артефактом обработки именно этого узла, а не реальной проблемой.
Описание столбцов
Avg Среднее RTT (мс)
Best Лучшее зафиксированное RTT
Worst Худшее зафиксированное RTT
StDev Джиттер / стабильность
Похожие инструменты
Как читать результаты
Каждая строка — один промежуточный узел (хоп) между нашим сервером и целью. Для каждого хопа показаны потери пакетов и задержка (средняя, лучшая, худшая), а также джиттер — разброс между пробами. Реальную проблему от шума отличают два признака:
- Потери, которые сохраняются до конца, реальны. Если потери начинаются на каком-то хопе и такие же потери видны на всех следующих, включая цель, пакеты действительно теряются там.
- Потери только на одном хопе — нет. Если промежуточный хоп показывает потери, а у цели 0%, этот маршрутизатор просто ограничивает частоту ответов на пробы.
- С задержкой то же самое: скачок, который держится на всех следующих хопах, реален (часто это дальний канал связи). Скачок только на одном хопе — медленный ответ самого маршрутизатора.
Хопы без ответа
Некоторые маршрутизаторы никогда не отвечают на пробы и отображаются пустыми или как ???. Это не страшно, если следующие хопы и цель отвечают.
Направление имеет значение
Тест идёт с нашего сервера к цели. Обратный путь может быть другим (асимметричная маршрутизация), поэтому проблема может проявляться только в одну сторону. Сообщая о проблеме провайдеру или хостингу, запустите MTR с обеих сторон и приложите отчёты:
- Linux / macOS:
mtr -rwbzc 100 example.com(режим отчёта, широкий вывод, IP и имена, номера AS, 100 проб). - Windows:
pathping example.comили WinMTR.
Чтобы узнать, какой сети принадлежит проблемный хоп, найдите его IP в поиске ASN.