Утилита tracert, встроенная в Windows, позволяет увидеть каждый промежуточный узел, через который проходят данные на пути к серверу, и измерить задержку на каждом из них. В отличие от команды ping, которая показывает только итоговое время отклика, tracert раскладывает маршрут по шагам и помогает определить, на каком именно участке возникает замедление. Проблема может оказаться в домашнем роутере, на стороне провайдера или в перегруженном узле за тысячи километров — tracert покажет это за считанные секунды. Разбираемся, как работает трассировка, как читать её результаты, почему провайдеры просят её при обращении в техподдержку и что она даёт при диагностике онлайн-игр.
Как работает tracert
Когда вы вводите в Командной строке или Терминале Windows команду вида:
tracert google.com
утилита начинает отправлять серию ICMP-пакетов с последовательно увеличивающимся значением TTL (Time to Live — время жизни пакета). Первый пакет уходит с TTL = 1. Ближайший маршрутизатор уменьшает значение на единицу, видит, что оно стало равно нулю, отбрасывает пакет и отправляет обратно ICMP-сообщение «Превышено время». Из этого ответа tracert узнаёт IP-адрес первого маршрутизатора и время прохождения пакета туда и обратно.
TTL (Time to Live) — поле в заголовке IP-пакета, которое определяет максимальное число маршрутизаторов, через которые пакет может пройти. Каждый маршрутизатор уменьшает TTL на 1. Когда значение достигает нуля, пакет отбрасывается, а отправитель получает ICMP-уведомление.
Следующий пакет уходит с TTL = 2 — он проходит первый маршрутизатор, но «умирает» на втором. И так далее, пока пакет не достигнет конечного сервера или пока не будет пройдено 30 хопов (значение по умолчанию). На каждый узел отправляются три пробы — это позволяет отличить реальную проблему от случайной аномалии.
ICMP (Internet Control Message Protocol) — служебный сетевой протокол для обмена диагностическими сообщениями между устройствами. Именно его используют утилиты ping и tracert для отправки эхо-запросов и получения ответов от промежуточных узлов.
Как читать результаты: пример здоровой трассировки
Вот как выглядит трассировка до google.com при обычном соединении без использования частных виртуальных сетей (пример выполнен из Индии):
| Хоп | RTT 1 | RTT 2 | RTT 3 | Адрес | Что это |
|---|---|---|---|---|---|
| 1 | 2 мс | 1 мс | 1 мс | 192.168.1.1 | Домашний роутер |
| 2 | 6 мс | 3 мс | 4 мс | 223.190.228.1 | Шлюз провайдера |
| 3 | 3 мс | 4 мс | 4 мс | 152.52.122.45 | Маршрутизатор провайдера |
| 4 | 27 мс | 23 мс | 23 мс | 116.119.161.147 | Внешний интернет |
| 5 | 23 мс | 23 мс | 22 мс | 72.14.205.196 | Сеть Google |
| 6 | 24 мс | 22 мс | 23 мс | 142.251.227.211 | Сеть Google |
| 7 | 22 мс | 21 мс | 24 мс | 209.85.247.229 | Сеть Google |
| 8 | 22 мс | 22 мс | 28 мс | pnmaaa-at-in-f14.1e100.net | Google (конечный узел) |
Хоп 1 — домашний роутер, задержка 1-2 мс. Хопы 2 и 3 — инфраструктура провайдера, менее 6 мс. На четвёртом хопе RTT ожидаемо вырастает до 23-27 мс: трафик вышел в «большой интернет». Дальше значения стабильны по всему маршруту через сеть Google — никаких скачков и таймаутов. Такой маршрут не вызывает вопросов.
RTT (Round-Trip Time) — время прохождения пакета от отправителя до узла и обратно, измеряемое в миллисекундах. Именно этот показатель обычно называют «пингом».
Скачок RTT: как найти узкое место
Трассировка становится по-настоящему полезной, когда соединение «тормозит». Рассмотрим пример — трассировку до yahoo.co.jp из Индии:
| Хоп | RTT 1 | RTT 2 | RTT 3 | Адрес | Что это |
|---|---|---|---|---|---|
| 1 | 2 мс | 1 мс | 1 мс | 192.168.1.1 | Домашний роутер |
| 2 | 3 мс | 3 мс | 4 мс | 223.190.228.1 | Шлюз провайдера |
| 3 | 3 мс | 4 мс | 4 мс | 152.52.122.45 | Маршрутизатор провайдера |
| 4 | 66 мс | 66 мс | 66 мс | 116.119.161.147 | Внешний интернет |
| 5 | 77 мс | 77 мс | 76 мс | 15.230.56.106 | Точка обмена трафиком Equinix |
| 6 | 132 мс | 132 мс | 132 мс | 210.130.180.133 | IIJ.Net (Токио) |
| 7 | 133 мс | 133 мс | 133 мс | 210.130.134.30 | Маршрутизатор IIJ.Net |
| 8 | 134 мс | 134 мс | 133 мс | 210.130.134.78 | Маршрутизатор IIJ.Net |
| 9 | 144 мс | 144 мс | 144 мс | 124.83.228.217 | Сеть Yahoo Japan |
| 10 | * | * | * | Превышен интервал ожидания | |
| 11 | 160 мс | 205 мс | 161 мс | 183.79.135.206 | Yahoo Japan (конечный узел) |
Первые три хопа — менее 4 мс. Локальная сеть и провайдер работают нормально. На четвёртом хопе задержка резко подскакивает до 66 мс — трафик вышел за пределы провайдера. На пятом — 77 мс (точка обмена трафиком Equinix). А на шестом — скачок почти вдвое, до 132 мс: пакет попал на маршрутизаторы IIJ.Net в Токио, скорее всего пройдя по подводному кабелю из Индии в Японию.
Главное правило чтения трассировки: если задержка резко выросла на определённом хопе и остаётся высокой на всех последующих — замедление начинается именно на этом участке. Все дальнейшие узлы просто «наследуют» задержку.
В приведённом примере скачок на шестом хопе — не поломка и не перегрузка. Это физическое расстояние между Индией и Японией. Никакие настройки на стороне пользователя его не уменьшат. Зато если бы скачок произошёл на хопе 2 или 3 — это был бы повод обращаться к провайдеру. А скачок на хопе 1 указал бы на проблему с домашним роутером.
Почему высокий RTT на хопе не всегда означает реальную задержку
Это один из самых частых источников путаницы при чтении трассировки. RTT на промежуточном хопе может быть сильно завышен, хотя реальный трафик проходит через этот узел без задержек.
Причина в том, что маршрутизаторы обрабатывают диагностические ICMP-пакеты с пониженным приоритетом. Основная задача маршрутизатора — как можно быстрее пересылать пользовательский трафик: веб-страницы, видео, игровые данные. Ответ на служебный ICMP-запрос от tracert — второстепенная задача. Маршрутизатор может отложить ответ на несколько миллисекунд или даже десятков миллисекунд, пока обрабатывает основной поток данных.
Ключевой признак ложного скачка: RTT резко вырастает на одном конкретном хопе, но на следующих хопах возвращается к нормальным значениям. Например, если хоп 5 показывает 120 мс, а хопы 6, 7 и 8 — снова 25-30 мс, значит, маршрутизатор на хопе 5 просто медленно отвечает на ICMP-запросы, но пропускает реальный трафик без задержек.
Признак настоящей проблемы: задержка вырастает на определённом хопе и остаётся высокой на всех последующих вплоть до конечного узла. Именно такую картину стоит воспринимать как реальное узкое место.
Звёздочки и таймауты: когда не стоит паниковать
В трассировке до yahoo.co.jp хоп 10 показал звёздочки (*) по всем трём пробам — «Превышен интервал ожидания для запроса». Выглядит тревожно, но трассировка успешно завершилась на хопе 11, достигнув конечного сервера. Маршрутизатор на хопе 10 просто не отвечает на диагностические пакеты. Многие маршрутизаторы настроены таким образом из соображений безопасности или для снижения нагрузки. Обычный пользовательский трафик они продолжают пропускать без проблем.
Ещё одна типичная ситуация — цепочка таймаутов ближе к концу трассировки. Если конечный узел не достигнут в пределах 30 хопов (максимум по умолчанию), появляются строки с таймаутами для каждого оставшегося хопа. Чаще всего это означает, что несколько промежуточных маршрутизаторов блокируют диагностические пакеты, но реальный трафик проходит нормально.
Три пробы на каждый хоп помогают убедиться в достоверности результата. Если все три значения RTT стабильно выше, чем на предыдущем хопе, — это реальное увеличение задержки. Если только одно значение выбивается — скорее всего, кратковременная аномалия.
Аномалии, на которые стоит обращать внимание, — те, у которых нет логичного объяснения. Скачок с 20 мс до 200 мс между двумя маршрутизаторами в одном городе — это проблема. Стабильно повышенные RTT, начиная с определённого хопа провайдера, — тоже повод для обращения в техподдержку.
Почему трассировка может показывать только один хоп
Иногда tracert выводит всего одну строку и сразу сообщает «Трассировка завершена». Например:
| Хоп | RTT 1 | RTT 2 | RTT 3 | Адрес |
|---|---|---|---|---|
| 1 | 68 мс | 68 мс | 68 мс | lcsofa-au-in-f14.1e100.net [192.178.24.14] |
Один хоп — и сразу конечный сервер. Это не ошибка и не особенность конкретного сайта. Такая картина возникает, когда соединение проходит через частный виртуальный туннель, корпоративную сеть или виртуальную машину. Весь трафик уходит в зашифрованный канал, и tracert не видит промежуточных маршрутизаторов — для утилиты путь выглядит как один «прыжок» напрямую к серверу.
Косвенным признаком служит IP-адрес компьютера из частного диапазона 10.0.0.0/8 (например, 10.0.2.15) — такие адреса назначают адаптеры и гипервизоры виртуальных машин. В частности, VirtualBox по умолчанию выдаёт адреса 10.0.2.x в режиме NAT.
Для полноценной трассировки с видимыми промежуточными узлами нужно отключить VPN и повторить команду, либо выполнить tracert на устройстве с прямым подключением к провайдеру.
Зачем провайдеры и хостеры просят трассировку
При обращении в техподдержку провайдера или хостинга с жалобой на медленное соединение часто просят прислать результат трассировки. Причина проста: tracert показывает, на чьей стороне проблема.
Если задержка нарастает на хопах 2-3, провайдер видит, что узкое место — в его собственной инфраструктуре. Если скачок происходит на стыке с вышестоящим оператором — провайдер может перенаправить трафик через другой маршрут. А если маршрут чист до самого сервера, но сайт всё равно тормозит, — проблема на стороне хостинга или самого веб-приложения.
Без трассировки техподдержка вынуждена гадать. С трассировкой — сразу сужает область поиска. Поэтому при жалобе на качество соединения полезно заранее выполнить трассировку до проблемного ресурса и приложить результат к обращению.
Что tracert показывает для онлайн-игр
В онлайн-играх задержка (пинг) критичнее, чем скорость канала. Подключение на 500 Мбит/с с пингом 150 мс будет играть хуже, чем канал на 50 Мбит/с с пингом 20 мс. Утилита tracert помогает разобраться, где именно нарастает задержка до игрового сервера.
Чтобы выполнить трассировку, нужно узнать IP-адрес сервера (обычно указан в настройках игры или на сайте проекта) и ввести команду:
tracert IP_сервера
Ориентиры по задержке для онлайн-игр: до 50 мс — отличный результат, действия отзываются мгновенно. От 50 до 100 мс — приемлемо для большинства жанров. Выше 150 мс — ощутимые задержки; в шутерах и файтингах это критично.
Результат трассировки покажет, где именно накапливается задержка. Скачок на первом хопе — проблема в домашней сети; стоит попробовать подключение по кабелю вместо Wi-Fi. Скачок на хопах 2-3 — узкое место у провайдера; есть смысл обратиться в техподдержку, приложив результат трассировки. Скачок далеко по маршруту — задержка связана с маршрутизацией через интернет; может помочь выбор другого игрового сервера, ближе к вашему региону.
Важный нюанс: tracert не показывает потерю пакетов и джиттер. Именно джиттер вызывает характерные микрофризы и «телепортации» персонажей в онлайн-играх, даже когда средний пинг выглядит нормально. Для измерения потерь пакетов в Windows есть утилита pathping, а для непрерывного мониторинга в реальном времени — сторонняя программа WinMTR.
Джиттер — разброс задержки между последовательными пакетами данных. Если пинг стабильно 40 мс — джиттер низкий и игра идёт плавно. Если пинг скачет от 20 до 120 мс — джиттер высокий, и картинка будет «дёргаться» даже при формально приемлемом среднем значении.
pathping: расширенная диагностика в Windows
Для более глубокого анализа в Windows есть утилита pathping. Она сочетает функции tracert и ping: сначала строит маршрут, а затем в течение нескольких минут отправляет множество пакетов на каждый узел и подсчитывает процент потерь.
pathping google.com
После построения маршрута pathping выводит сообщение о сборе статистики — это занимает от 25 до 250 секунд в зависимости от числа хопов. По завершении утилита показывает RTT для каждого хопа, а также процент потерянных пакетов на каждом маршрутизаторе и на каждом соединении между ними.
Если tracert показал подозрительный участок, pathping поможет подтвердить или опровергнуть проблему. Потеря 1-2% пакетов на промежуточном узле — нормальная ситуация. Стабильная потеря 10-15% и выше — признак перегрузки или неисправности на этом участке.
Ограничения tracert
Утилита tracert показывает только прямой путь от вашего компьютера к серверу. Обратный путь может проходить через другие узлы, и задержка на нём может отличаться. Некоторые сети обрабатывают диагностические ICMP-пакеты иначе, чем обычный трафик — с пониженным приоритетом или через другой маршрут. Из-за этого RTT в трассировке может не совпадать с реальной задержкой для пользовательских данных.
Потерю пакетов и джиттер tracert не измеряет — для этого есть pathping (встроена в Windows) и сторонняя утилита WinMTR, которая совмещает трассировку с непрерывным мониторингом в реальном времени.
При использовании VPN, корпоративных туннелей или виртуальных машин tracert не покажет промежуточные узлы — весь маршрут будет выглядеть как один хоп. Для полноценной диагностики в таких случаях нужно прямое подключение к провайдеру.
При всех ограничениях tracert остаётся самым быстрым способом определить, чья именно это проблема — ваша, провайдера или удалённого сервера. Результат готов за несколько секунд, и для запуска не нужны ни установка дополнительного софта, ни права администратора.
Аналог tracert в Linux и macOS
В Linux и macOS для трассировки маршрута используется утилита traceroute. Принцип работы тот же: отправка пакетов с последовательно увеличивающимся TTL, получение ICMP-ответов от каждого промежуточного узла, измерение RTT. Запуск аналогичен:
traceroute google.com
Главное отличие — в протоколе. Утилита tracert в Windows по умолчанию отправляет ICMP-пакеты (эхо-запросы), а traceroute в Linux — UDP-пакеты на порты 33434-33534. Из-за этого результаты могут различаться: некоторые маршрутизаторы и межсетевые экраны блокируют UDP, но пропускают ICMP, и наоборот. Чтобы поведение traceroute совпадало с Windows-версией, достаточно добавить ключ -I:
traceroute -I google.com
Аналогом pathping в Linux служит утилита mtr (My Traceroute). Она совмещает трассировку маршрута с непрерывным мониторингом задержки и потерь пакетов в реальном времени — по сути, делает то же, что pathping, но обновляет результаты постоянно, а не один раз после ожидания. Для Windows существует порт этой утилиты — WinMTR.