mtr против traceroute

Traceroute и mtr - это инструменты командной строки для диагностики проблем с сетевыми маршрутами. Traceroute дает единовременный снимок маршрута, по которому идут пакеты. mtr делает то же самое, но продолжает зондирование, накапливая статистику о потере пакетов, задержке и джиттере с течением времени. В этой статье мы расскажем о том, как работает каждый инструмент, как читать результаты и когда их использовать.

Как работает traceroute

Traceroute использует поле Time-to-Live (TTL) в заголовках IP-пакетов. Он отправляет пакет с TTL, установленным на 1. Первый маршрутизатор уменьшает TTL до нуля, отбрасывает пакет и отправляет обратно сообщение ICMP "Время превышено". Traceroute записывает IP маршрутизатора и время прохождения маршрута, затем отправляет еще один пакет с TTL, установленным на 2, и так далее, пока пакет не достигнет места назначения или не превысит максимальный лимит переходов (по умолчанию 30, настраивается с помощью параметра -m).

По умолчанию traceroute посылает три зонда на каждый хоп, что позволяет получить три значения задержки. Протоколы различаются в зависимости от ОС:

• Windows: Команда tracert отправляет ICMP Echo Requests.
• Linux/macOS: команда traceroute отправляет дейтаграммы UDP (порты 33434-33534). Используйте -I для ICMP или -T для TCP, если UDP заблокирован.

Добавление флага -n позволяет отказаться от обратного поиска DNS, что заметно ускоряет работу на путях с большим количеством переходов.

Как работает mtr

mtr (My Traceroute) использует тот же метод обнаружения пути на основе TTL, что и traceroute, но он продолжает посылать зонды, обычно один в секунду. Вместо трех точек данных за один переход вы получаете текущую статистику: процент потери пакетов, среднюю задержку, лучшее и худшее время отклика, а также стандартное отклонение (джиттер).

mtr поддерживает ICMP (по умолчанию), UDP и TCP SYN-зонды. Режим TCP полезен, когда брандмауэры блокируют ICMP или когда нужно протестировать определенный порт приложения:

mtr --tcp --port 443 example.com

Для получения неинтерактивного отчета, которым можно поделиться со службой поддержки, используйте режим отчета:

mtr --report --report-cycles 100 example.com

В этом режиме выполняется 100 тестов и печатается сводка. Вы также можете задать пользовательские размеры пакетов с помощью параметра --psize, чтобы проверить MTU или фрагментацию.

mtr работает в Linux и macOS. Пользователи Windows могут использовать WinMTR для эквивалента с графическим интерфейсом.

Ключевые различия

Практическая разница сводится к периодическим проблемам. Один traceroute может легко пропустить маршрутизатор, который теряет 2 % пакетов, или хоп с 15 мс джиттера. mtr улавливает их, потому что постоянно проводит измерения.

Чтение выходных данных

Самая распространенная ошибка при чтении результатов traceroute или mtr - это предположение, что проблемно выглядящий промежуточный хоп означает наличие реальной проблемы. Обычно это не так.

Звездочки (*) в traceroute означают, что маршрутизатор не ответил на запрос. Многие маршрутизаторы настроены на игнорирование или ограничение скорости ICMP. Если все последующие хопы отвечают нормально, значит, с маршрутом все в порядке.

Потеря пакетов в одном хопе в mtr следует той же логике. Если хоп 5 показывает 20 % потерь, а конечный пункт назначения - 0 %, этот маршрутизатор просто деприоритизирует ответы зонда. Реальная потеря пакетов проявляется в виде паттерна: потеря появляется в одном хопе и сохраняется во всех последующих хопах до места назначения.

Скачки задержки между хопами нормальны и ожидаемы. Скачок с 10 мс до 80 мс обычно означает, что пакет пересек океан или длинный сухопутный маршрут. Беспокоиться о задержке следует только в том случае, если она необычно высока для данного расстояния (менее 5 мс в пределах района метро, десятки миллисекунд по стране, 80-150 мс за океаном) или если задержка в конечном пункте назначения неприемлема.

Стоит обратить внимание наStDev (джиттер) в mtr. Значения выше 10 мс в любом хопе могут вызвать проблемы при VoIP, видеозвонках и играх. Если вы заметили высокий джиттер, выполните не менее 100 циклов, чтобы убедиться, что это устойчивая картина, а не кратковременный всплеск.

Когда использовать каждый инструмент

Используйте traceroute, когда вам нужен быстрый ответ: достижим ли конечный пункт, и если нет, то где обрывается путь? Это подходящая отправная точка при сбоях и для проверки базовой маршрутизации.

Используйте mtr, если проблема носит прерывистый характер или связана с производительностью. Пользователям, сообщающим о периодических обрывах связи, проблемах с качеством VoIP или скачках задержки, нужны непрерывные данные mtr. Для получения достоверной статистики проведите не менее 50-100 циклов.

Для тщательной диагностики запустите mtr в обоих направлениях: от вашего компьютера к серверу и от сервера обратно к вашему IP. Маршрутизация в Интернете асимметрична, поэтому обратный путь может иметь совершенно другие характеристики. Если вы протестируете только одно направление, вы можете не заметить, где на самом деле находится проблема.

Если у вас возникли проблемы с выделенным сервером или VPS, служба поддержки FDC Servers принимает отчеты mtr в качестве стандартного диагностического доказательства для эскалации сети.