Трассировка показывает 300 мс на пятом хопе, а сайт летает: почему промежуточные узлы врут

MAATRIX

Вы гоняете mtr до своего сервера, видите на пятом хопе скачок задержки со стандартных 15 мс до 300 мс — и тянетесь писать в поддержку хостера или провайдеру транзитной сети. А сайт при этом открывается мгновенно, приложение не тормозит, пинг до самого сервера в норме. Это не глюк мониторинга и не повод для паники: в подавляющем большинстве случаев так выглядит побочный эффект того, как маршрутизатор обрабатывает диагностические ICMP-пакеты — и это никак не связано со скоростью, с которой он пересылает ваш настоящий трафик дальше.

Почему у маршрутизатора два разных «режима работы»

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

• Data plane (он же forwarding plane) — путь, по которому идёт обычный транзитный трафик: ваши TCP-пакеты, UDP, видео, HTTP-запросы. На магистральных и корпоративных роутерах эта пересылка почти всегда реализована на специализированной микросхеме — ASIC или сетевом процессоре (NPU). Задача этой микросхемы одна: посмотреть на заголовок пакета, свериться с таблицей маршрутизации и отправить пакет дальше на скорости линии — миллионы пакетов в секунду, с задержкой в единицы микросекунд на сам акт пересылки.
• Control plane — «мозг» роутера: здесь крутится протокол маршрутизации (BGP, OSPF), считаются таблицы, обрабатываются служебные и управляющие пакеты, адресованные самому роутеру, а не транзитом через него. Control plane почти всегда работает на обычном универсальном процессоре (CPU) роутера — тому же, что считает конфигурацию, отвечает на SNMP-запросы и генерирует диагностические ICMP-ответы. Этот процессор на порядки медленнее ASIC-пути и рассчитан на совсем другие объёмы: не миллионы пакетов в секунду, а десятки-сотни.

Ваш обычный трафик — то, ради чего вообще существует сеть, — идёт по первому, быстрому пути. А вот пакет ICMP Time Exceeded, который traceroute или mtr провоцируют, отправляя пакет с истёкшим TTL, — это как раз тот случай, когда роутеру самому нужно сформировать и отправить новый пакет, а не просто переслать чужой. Формирование нового пакета — это уже не работа ASIC, это задача control plane.

Punt to CPU: почему генерация ICMP — это медленный путь

В сетевой инженерии для этого есть специальный термин — punt (иногда «trap to CPU»). Когда специализированная микросхема пересылки встречает пакет, который не может обработать сама по стандартному fast path — а истёкший TTL это ровно такой случай, — она не выбрасывает его и не обрабатывает на месте, а «пунтит» пакет на общий процессор роутера с пометкой «разберись сам». CPU должен:

1. Принять пакет из очереди punt-канала (у которой на многих платформах намеренно ограниченная и невысокая пропускная способность — это защита самого CPU от перегрузки).
2. Сформировать новый ICMP-пакет Time Exceeded с нужными полями.
3. Поставить его в очередь на отправку — с приоритетом, который на большинстве платформ ниже, чем у управляющего трафика вроде BGP-keepalive, и уж точно не выше, чем у обычной пересылки данных.
4. Отправить пакет обратно к вам.

Каждый из этих шагов — источник дополнительной задержки, которая не имеет никакого отношения к тому, насколько быстро этот же роутер пересылает ваш настоящий TCP-трафик через себя транзитом. Пока ваш пакет летит через ASIC за микросекунды, диагностический ICMP-ответ может секунды или даже больше ждать своей очереди на перегруженном CPU — особенно если оператор сети намеренно ограничивает скорость генерации таких ответов (rate limiting), чтобы шторм traceroute-запросов от тысяч пользователей интернета не положил управляющий процессор дорогого магистрального маршрутизатора.

Важно: это осознанная и распространённая практика, а не поломка. Операторы магистральных сетей прямо документируют, что control plane их оборудования приоритизирован в пользу устойчивости маршрутизации, а не в пользу красивого вывода traceroute у случайного пользователя интернета.

Как это выглядит в реальном выводе mtr

Возьмём пример трассы (цифры условные, для иллюстрации механики):

                                     Packets               Pings
Host                               Loss%   Snt   Last   Avg  Best  Wrst
1. 192.168.1.1                      0.0%   100    0.4   0.5   0.3    1.2
2. 10.0.0.1                         0.0%   100    2.1   2.3   1.9    5.4
3. core1.upstream.example.net       0.0%   100    9.8  10.1   9.2   14.0
4. core2.upstream.example.net       0.0%   100   11.2  11.6  10.8   16.5
5. peer-edge.transit.example.net    0.0%   100  298.4 301.7 295.1  310.2
6. border.destnet.example.net       0.0%   100   12.9  13.2  12.1   17.8
7. target.example.com               0.0%   100   14.0  14.3  13.5   18.9

Смотрите на хоп 5: задержка подскакивает почти в 30 раз относительно соседних хопов — с ~11 мс до ~300 мс. При этом хоп 6 и хоп 7 (то есть всё, что дальше по маршруту, включая саму цель) возвращаются к нормальным 12-14 мс. Если бы этот роутер на пятом хопе реально держал ваш трафик 300 мс перед тем как отправить дальше — эта задержка накопилась бы и осталась висеть на всех последующих строках, потому что время, которое пакет уже потратил, никуда не девается по мере продвижения дальше по маршруту. А она не остаётся. Это и есть характерный отпечаток артефакта control plane: аномалия локализована ровно на одном хопе и не тащится дальше.

Loss% в этом примере нарочно оставлен нулевым, чтобы не путать с соседней темой — про то, как отличить настоящую потерю пакетов от лимита на ICMP-ответы, подробно разобрано в статье про локализацию участка, где теряются пакеты. Здесь речь именно о задержке: пакеты доходят все, потерь нет ни на одном хопе, но время отклика на одной строке выглядит пугающе.

Правило одного хопа: как отличить артефакт от реальной проблемы

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

Это почти всегда артефакт ICMP-обработки, а не реальная проблема сети, если:

• аномальная задержка видна ровно на одном (реже — двух соседних) промежуточном хопе;
• на следующем же хопе задержка возвращается к уровню, сопоставимому с хопами до аномалии;
• задержка на конечном сервере (последняя строка трассы) в норме и не отличается от привычной вам цифры;
• реальные метрики приложения — время ответа сайта, задержка в звонке, скорость загрузки — в порядке, несмотря на страшную строку в трассировке.

Это стоит проверять как настоящую проблему на сети, если:

• задержка выросла на хопе N и остаётся такой же высокой на всех последующих хопах вплоть до конечного сервера — то есть не «просаживается» на N, а сдвигает базовый уровень для всей оставшейся части маршрута;
• вместе с ростом задержки на итоговой строке (сама цель) вы видите такой же рост относительно вашей обычной базовой линии;
• поведение подтверждается не только в трассировке, но и в реальных симптомах: сайт долго грузится, видеозвонок лагает, RDP подвисает.

Механика этого второго случая — кумулятивный RTT: если участок сети между хопом N и хопом N+1 физически или из-за перегрузки добавляет, скажем, 80 мс к времени в пути пакета, то это время добавляется один раз и дальше остаётся частью пути в оба конца для всех последующих измерений — оно никуда не исчезает по мере прохождения оставшихся хопов. Поэтому реальное увеличение задержки на участке маршрута выглядит в mtr как «ступенька», после которой все нижестоящие строки держатся на новом, более высоком уровне — в отличие от «иглы» на одном хопе, которая является признаком именно ICMP-артефакта.

Почему это не то же самое, что общие потери на ICMP

Тема «промежуточный хоп ведёт себя странно в traceroute, хотя сеть работает нормально» шире, чем только задержка, и легко перепутать её со смежным, но другим явлением — потерей пакетов на отдельном хопе. Там механика родственная (те же особенности control plane), но проявляется она иначе: не в виде аномального RTT на одной строке, а в виде Loss% или * * * на конкретном хопе при нулевых потерях дальше по маршруту. Если у вас именно такая картина — стоит смотреть отдельный разбор про то, как читать колонки Loss% в mtr и не путать диагностический шум с реальными потерями. Здесь же мы разбираем именно случай, когда пакеты не теряются вообще, но одна строка трассы показывает пугающую цифру миллисекунд — и это отдельный, хотя и близкий по происхождению эффект.

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

Как проверить на практике: несколько замеров и альтернативные протоколы пробирования

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

1. Соберите достаточно пакетов, а не один снимок. Разовый traceroute — это один пробник на хоп, слишком мало данных для выводов. Гоните mtr дольше, с отчётом и без DNS-резолвинга (он замедляет замер и добавляет шум):

mtr -rwnc 300 target.example.com

Если цифра на подозрительном хопе стабильна от замера к замеру — это постоянное локальное ограничение на ICMP-ответы конкретного роутера. Если она хаотично скачет — это тоже обычно control plane под переменной нагрузкой, а не деградация канала передачи данных.

1. Замерьте задержку до самой цели отдельно. Обычный ping до конечного сервера — самый честный источник истины про реальную задержку, потому что здесь нет посредников: цель отвечает сама, а не через punt промежуточного оператора.

ping -c 50 target.example.com

Если средний ping до цели в норме, а mtr пугает строкой посередине — вопрос закрыт, это ICMP-артефакт на промежуточном узле.

1. При сомнениях попробуйте TCP-пробники вместо ICMP. Флаг -T в mtr переключает зондирование на TCP SYN на указанный порт — иногда даёт более честную картину, если промежуточные роутеры по-разному приоритизируют ICMP и TCP-трафик:

mtr -T -P 443 -rwnc 300 target.example.com

Если аномалия ведёт себя так же локально и в этом режиме — вывод не меняется, это особенность конкретного узла, а не проблема сети.

1. Замерьте с обеих сторон, если есть такая возможность. Симметрия маршрутов не гарантирована: путь туда и обратно может идти через разные роутеры с разными приоритетами control plane. Параллельный mtr с клиента до сервера и с сервера до клиента даёт куда более полную картину, чем замер с одной стороны. Общая методика замера задержки описана в статье как измерить реальный пинг до сервера.

1. Держите базовую линию. Если вы регулярно мониторите путь до продакшн-сервера, полезно один раз в спокойный период зафиксировать «нормальную» трассу — какие хопы обычно показывают аномалию по ICMP. Тогда при следующей тревоге вы сразу сверяетесь с известной базой, а не гадаете заново.

Что не нужно делать, увидев скачок на одном хопе

• Не нужно менять маршрут вручную или переключать провайдера, если задержка до цели и поведение приложения в норме — вы решаете несуществующую проблему и рискуете получить маршрут хуже текущего.
• Не нужно писать в поддержку транзитного оператора с требованием «почините роутер номер пять» — оператор, скорее всего, ответит именно то, что описано в этой статье: control plane его оборудования намеренно не приоритизирован для диагностических ответов.
• Не нужно расценивать это как аргумент против конкретного хостинга или дата-центра при выборе локации сервера — аномалия на чужом промежуточном узле, через который идёт транзит, никак не характеризует качество сети самого хостера.
• Не нужно пытаться «полечить» это настройками на своей стороне — источник задержки на приоритезации ICMP-ответов находится на чужом оборудовании посередине маршрута, вне вашего контроля и вне контроля хостера конечного сервера.

Единственное действие, которое оправдано, — зафиксировать, что аномалия локальна и не деградирует конечную задержку, и на этом закрыть вопрос, если только реальные метрики приложения не говорят обратного.

Частые вопросы