Измерение и поиск источника сетевых задержек методом пошаговой трассировки маршрута

Скорость скачивания высокая, а отклик медленный. Видеозвонок идёт с запозданием, удалённый рабочий стол отзывается на нажатия с задержкой, в онлайн-игре персонаж реагирует с опозданием на полсекунды. Это проблема не пропускной способности, а задержки - времени, которое пакет тратит на путь туда и обратно. Толстый канал не спасает от высокой задержки, потому что это разные характеристики. Задержка набирается из времени прохождения каждого участка длинного пути от компьютера до сервера, и чтобы её снизить, надо сначала понять, на каком именно участке она набегает. Трассировка маршрута - встроенный в Windows способ разложить общую задержку по отдельным прыжкам и найти виновный участок.

Задержка измеряется в миллисекундах и означает время, за которое сигнал доходит до узла и возвращается обратно. Чем дальше узел и чем больше промежуточных устройств, тем выше задержка. Но рост не всегда плавный: иногда один перегруженный участок добавляет к задержке больше, чем все остальные вместе. Трассировка показывает время до каждого промежуточного узла, и по этим цифрам видно, где задержка набегает естественно из-за расстояния, а где аномально из-за перегрузки.

Построение карты задержек по каждому прыжку маршрута

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

tracert ya.ru

Каждая строка вывода содержит номер прыжка, три замера времени в миллисекундах и адрес узла. Три замера на строку нужны для оценки стабильности: близкие значения говорят о ровном отклике узла, разброс - о нестабильности. Читать карту задержек надо в динамике от прыжка к прыжку. Нормальная картина - плавный рост задержки по мере удаления от дома. Первый прыжок до домашнего роутера обычно даёт доли миллисекунды или единицы миллисекунд. Дальше идёт оборудование провайдера с задержкой в единицы и десятки миллисекунд. Магистральные узлы добавляют ещё, и до далёкого сервера общая задержка набирается до десятков, а до зарубежных - до сотен миллисекунд.

Ускорение измерения отключением перевода адресов в имена

При измерении задержек важно, чтобы на цифры не влияли посторонние факторы. Перевод адресов узлов в буквенные имена добавляет паузы, искажая картину и замедляя вывод. Поэтому при анализе задержек его отключают ключом:

tracert -d ya.ru

С этим ключом трассировка показывает чистые числовые адреса и работает быстрее, а главное, время каждого прыжка отражает только сетевую задержку, не смешанную с задержкой запроса имён. Это особенно важно, когда служба разрешения имён сама работает медленно: иначе долгие запросы имён маскируют истинные сетевые задержки и сбивают с толку. Для точного измерения задержек режим без перевода имён предпочтителен всегда, а имена узлов запрашивают потом отдельно, если нужно понять, чьё это оборудование, провайдера или магистрального оператора.

Чтение аномальных скачков задержки на маршруте

Главная цель анализа - найти прыжок, где задержка скачет аномально. Несколько типичных картин дают готовый диагноз. Если задержка плавно растёт и доходит до цели без резких скачков, маршрут здоров, высокая итоговая задержка объясняется просто дальностью. Если на каком-то прыжке время резко подскакивает и остаётся высоким до конца пути, найден перегруженный участок, и все узлы за ним наследуют эту задержку. Это типичная улика перегруженного маршрутизатора или насыщенного канала на стыке сетей.

Отдельный важный случай - высокая задержка на одном промежуточном узле, после которого время снова падает. Это не проблема: многие маршрутизаторы намеренно отвечают на служебные запросы медленно или с низким приоритетом, экономя ресурсы для реального трафика. Если задержка скакнула на одном узле, а на следующих вернулась к норме, перегрузки нет, просто этот конкретный узел неохотно отвечает на пробу. Тревожна именно ситуация, когда задержка подскакивает и держится высокой до самой цели, потому что тогда страдает весь трафик, проходящий через этот участок. Умение различать эти две картины отделяет настоящую перегрузку от безобидной особенности отдельного узла.

Расширенный анализ задержек и потерь по узлам

Обычная трассировка показывает задержку, но почти не считает потери на промежуточных узлах, а потери и задержка часто связаны: перегруженный узел и тормозит, и теряет пакеты. Полную картину даёт команда pathping, объединяющая измерение задержки с подсчётом потерь по каждому прыжку:

pathping ya.ru

Команда работает в две фазы. Первая за секунды строит маршрут. Вторая, долгая, опрашивает каждый узел около 25 секунд, собирая статистику. По длинной цепочке полный отчёт готов через несколько минут, зато на выходе таблица с задержкой и процентом потерь на каждом узле. Эта таблица отвечает на главный вопрос точнее обычной трассировки: она показывает не разовый замер, а усреднённую за минуты картину, где случайные всплески сглажены, а устойчивая проблема видна чётко. Часто именно расширенный анализ выявляет узел, который на быстрой трассировке выглядел нормально, а при долгом опросе показал стабильные потери и рост задержки под нагрузкой.

Многократные замеры для отсева случайных всплесков

Единичная трассировка ловит лишь мгновенный срез, а задержка - величина переменчивая. В момент замера узел мог быть случайно загружен, и разовый высокий результат введёт в заблуждение. Поэтому для надёжного вывода трассировку повторяют несколько раз и сравнивают. Сделать серию замеров с паузой помогает короткий цикл в оболочке PowerShell:

1..5 | ForEach-Object {
    Test-NetConnection ya.ru -InformationLevel Detailed | Select-Object PingReplyDetails
    Start-Sleep -Seconds 10
}

Цикл выполняет пять замеров задержки до цели с паузой в десять секунд между ними. Если высокая задержка стабильно повторяется во всех замерах, проблема реальна и постоянна. Если она мелькает лишь в одном из пяти, это случайный всплеск, не стоящий внимания. Многократность отделяет систематическую задержку, которую надо устранять, от разовой помехи, которая пройдёт сама. Особенно полезно разнести замеры по времени суток: задержка, растущая вечером в часы пик, выдаёт перегрузку на стороне провайдера, тогда как ровная круглосуточная задержка объясняется просто дальностью пути. Утренняя норма и вечерняя деградация - почерк именно перегрузки общего канала, которую разовая дневная проверка не поймает в принципе, потому что попадает в окно, когда нагрузка низкая и всё работает гладко.

Различие задержки до узла и накопленной задержки маршрута

Тонкий момент, который сбивает с толку новичков: время в каждой строке трассировки - это задержка до данного узла от компьютера, а не от предыдущего узла. То есть цифры показывают накопленную задержку с начала пути, и она по природе своей растёт от строки к строке. Чтобы понять, сколько добавляет конкретный участок между двумя соседними узлами, вычитают задержку предыдущего прыжка из задержки текущего. Если между седьмым и восьмым прыжком разница составляет десятки миллисекунд, тогда как остальные участки добавляют единицы, именно этот отрезок пути и есть слабое место.

Такой пошаговый разбор разниц важнее, чем взгляд на итоговую задержку до цели. Большая итоговая цифра сама по себе ни о чём не говорит: до сервера на другом континенте задержка в сотни миллисекунд совершенно нормальна и неустранима, потому что её диктует расстояние и скорость распространения сигнала. А вот лишние десятки миллисекунд, добавленные одним перегруженным участком в середине пути, - это уже устранимая проблема. Поэтому при анализе всегда смотрят не на финальную задержку, а на приращения между соседними узлами, выискивая участок с аномально большим скачком. Этот навык чтения разниц превращает столбец нарастающих чисел в карту вклада каждого участка в общую задержку, где сразу виден главный виновник.

Учёт обратного пути при асимметричной задержке

Трассировка измеряет время прохождения пакета туда и обратно, и в этом кроется неочевидная ловушка. Путь к серверу и путь обратно не обязаны совпадать: пакеты могут идти к цели одним маршрутом, а возвращаться другим. Поэтому высокая задержка на каком-то прыжке иногда объясняется не медленным путём к нему, а медленным обратным путём от него к компьютеру. Это явление называют асимметрией маршрута, и оно усложняет толкование цифр. Узел может выглядеть проблемным, хотя на деле тормозит не он, а обратная дорога от него.

Распознать асимметрию помогает встречная трассировка с удалённого узла к компьютеру, если к нему есть доступ. Когда такого доступа нет, на асимметрию косвенно указывает ситуация, при которой задержка скачет на одном узле, но не наследуется следующими за ним прыжками так, как наследовалась бы при настоящей перегрузке. Понимание асимметрии уберегает от ложных обвинений конкретного узла. Понимание этого ограничения уберегает от ложного вывода, будто узел сломан. Опытный администратор всегда держит в уме, что измеренная задержка отражает полный цикл туда и обратно, а не только путь в одну сторону, и не спешит назначать виновным узел только потому, что напротив него выскочила большая цифра, особенно если следующие узлы показывают нормальное время. Этот трезвый взгляд на природу замера отделяет настоящих виновников от мнимых и бережёт время, которое иначе ушло бы на жалобы оператору исправного участка.

Практические выводы и устранение найденной задержки

Когда проблемный участок найден, дальнейшие действия зависят от того, чей он. Если высокая задержка начинается уже на первом прыжке, у домашнего роутера, виновато местное оборудование: перегруженный Wi-Fi, слабый сигнал, старая прошивка. Это чинится дома сменой канала, переходом на кабель или обновлением роутера. Если задержка нормальна до дома, но скачет на оборудовании провайдера, претензию адресуют провайдеру, приложив сохранённую трассировку как доказательство:

tracert -d ya.ru > C:\zaderzhka.txt

Перенаправление в файл сохраняет результат для обращения в поддержку. Если же задержка набегает в магистральной части пути, за пределами сети провайдера, повлиять на неё почти невозможно, остаётся ждать восстановления у дальнего оператора или искать ресурс, расположенный ближе по маршруту.

Анализ задержек трассировкой превращает смутное ощущение тормозит в точную карту с цифрами по каждому участку. Вместо общего вердикта медленно появляется конкретика: задержка набегает на таком-то прыжке, принадлежащем такому-то оператору.

Полезно держать под рукой и эталонный замер, снятый в спокойное время, когда сеть работала хорошо. Сравнивая текущую трассировку с эталонной, сразу видно, какой участок просел против нормы. Без точки отсчёта высокая задержка на узле выглядит подозрительно, но непонятно, было ли так всегда или испортилось недавно. Эталонный замер снимает этот вопрос: участок, добавивший лишние миллисекунды по сравнению с собой же вчерашним, и есть свежая проблема. Поэтому разумная привычка - периодически сохранять трассировки до ключевых ресурсов в спокойные часы, чтобы при жалобах было с чем сравнить. Эта простая мера превращает диагностику из гадания в точное сопоставление до и после.

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