Почему обычный tracert работает так долго
По умолчанию tracert для каждого узла на пути отправляет три запроса и ждёт ответ до четырёх секунд. Затем он пытается определить имя узла обратным DNS-запросом. Если узел молчит, вы получаете строку со звёздочками и ждёте 12 секунд на каждый такой переход. При 30 переходах в худшем случае трассировка тянется несколько минут.
Три ключа решают эту проблему. Ключ -d отключает поиск имён, -h задаёт предельное число переходов, а -w сокращает время ожидания. Вместе они превращают неторопливую проверку в быструю, которую можно повторять несколько раз подряд и сравнивать результаты.
Сама идея трассировки проста: программа отправляет пакеты с растущим значением TTL, и каждый узел, где TTL заканчивается, сообщает о себе. Так вы получаете список узлов между вами и целью. Общее понятие описано в словаре на странице про traceroute.
Отдельное удобство ключей в том, что они не меняют смысла результата. Вы получаете тот же маршрут, только быстрее, и можете спокойно повторить проверку несколько раз подряд, чтобы убедиться в устойчивости картины. Одиночный запуск на нестабильном канале нередко показывает случайную картину, а серия из трёх запусков уже позволяет говорить о закономерности.
Что делают ключи и какие значения по умолчанию
Ниже собраны ключи, которые нужны в повседневной работе. Значения приведены для стандартной утилиты tracert в Windows.
| Ключ | Что делает | По умолчанию |
|---|---|---|
| -d | Не преобразует адреса узлов в имена | выключен, имена запрашиваются |
| -h число | Максимальное число переходов до цели | 30 |
| -w миллисекунды | Время ожидания ответа на каждый запрос | 4000 мс |
| -4 | Принудительно использует IPv4 | по ответу DNS |
| -6 | Принудительно использует IPv6 | по ответу DNS |
| -j список | Задаёт нестрогий маршрут через перечисленные узлы (только IPv4) | не используется |
Ключи -4 и -6 полезны, когда имя имеет и IPv4-, и IPv6-адрес, и вы хотите сравнить маршруты двух протоколов. Ключ -j применяют редко, он больше нужен для специальных экспериментов, и многие сети отбрасывают пакеты с такими параметрами.
Порядок написания ключей не важен: главное, чтобы адрес или имя цели стояли в конце команды.
Быстрая трассировка: пример команды и вывод
Практичный вариант для повседневной диагностики выглядит так: tracert -d -h 20 -w 1000 example.com. Отключение поиска имён убирает задержки на обратных DNS-запросах, лимит в 20 переходов достаточен для большинства маршрутов, а секундного ожидания хватает: узел, не ответивший за секунду, всё равно отображается как «медленный» и ненадёжный.
Пример вывода (пример, адреса из блока документации):
1 <1 мс <1 мс <1 мс 192.0.2.1 2 4 мс 3 мс 4 мс 198.51.100.1 3 * * * Превышен интервал ожидания для запроса. 4 12 мс 11 мс 13 мс 203.0.113.9 5 25 мс 24 мс 26 мс 203.0.113.50
Каждая строка это один переход. Три числа показывают время ответа на три запроса, справа адрес узла. Звёздочки в строке 3 вовсе не значат обрыв: следующие строки показывают, что пакеты идут дальше, значит, узел лишь не отвечает на служебные запросы.
Если цель находится в вашей локальной сети, лимит переходов можно уменьшить до 5 или 8: путь внутри квартиры или офиса короткий. Для быстрой проверки, дошёл ли пакет до шлюза и какой первый внешний узел следует за ним, хватает и ключа -h 4. Так вы сразу видите границу между своей сетью и сетью провайдера.
Как читать вывод: звёздочки, скачки времени и остановка
Чтобы не делать ложных выводов, важно различать типичные картины. Одна строка со звёздочками, за которой идут нормальные строки, это обычная защита узла. Вывод строится по-иному, если звёздочки идут до самого конца.
- Звёздочки до конца трассировки означают, что дальше некоторого узла пакеты не проходят или ответы до вас не возвращаются. Это может быть и фильтр на конечном узле, у которого просто закрыт ICMP.
- Резкий рост времени на одном узле, после которого значения возвращаются к норме, говорит о том, что сам узел медленно обрабатывает служебные запросы. Это не проблема канала.
- Рост времени, который сохраняется на всех следующих узлах, указывает на реальный медленный участок или перегрузку начиная с этого места.
- Цель, недоступная для ping, но достигнутая при трассировке, бывает, если ICMP запрещён, а другие пакеты проходят.
Одного запуска для выводов мало. Повторите tracert два-три раза и сравните: картина, которая держится, заслуживает внимания.
Обратите внимание, что при равных условиях время на первом переходе должно быть минимальным (доли миллисекунды по кабелю, несколько миллисекунд по Wi-Fi). Если уже первый узел отвечает десятками миллисекунд, проблема в вашей локальной сети или радиоканале, а не у провайдера. Так проще всего отделить домашние причины от внешних.
Ограничения tracert и когда брать другие инструменты
Утилита показывает моментальный снимок, а не динамику. Она отправляет всего три запроса на переход, поэтому не отличает случайный сбой от стабильных потерь. Для наблюдения во времени лучше подходит mtr, а в Windows его аналоги, например WinMTR, или встроенная команда pathping, которая собирает статистику по каждому узлу в течение нескольких минут.
Кроме того, tracert использует ICMP, тогда как реальный трафик идёт по TCP или UDP, и промежуточные устройства могут обращаться с ними по-разному. Поэтому при отчёте провайдеру прикладывайте трассировку вместе с описанием проблемы и результатами ping.
Не запускайте трассировку по чужим узлам с высокой частотой в цикле. Запускайте её для собственной диагностики или по договорённости. Обзор аналогов для других систем есть на страницах про traceroute для Linux и macOS и про tracepath.