Traceroute: Почему промежуточные узлы показывают более высокую задержку

Когда вы наблюдаете более высокую задержку на промежуточном хопе (17-й хоп с задержкой 210 мс) по сравнению с конечным пунктом назначения (85 мс), это распространенное и часто нормальное явление, вызванное тем, как traceroute измеряет время кругового пути (round-trip time) в сочетании с асимметричными маршрутами. Ключевое объяснение заключается в том, что traceroute измеряет полное время кругового пути до каждого хопа - включая как путь к этому маршрутизатору, так и обратный путь для сообщения ICMP “Time Exceeded” обратно к источнику. Эти пути могут быть совершенно разными, особенно когда существует асимметричная маршрутизация между прямым и обратным путями.

Содержание

• Как traceroute на самом деле измеряет задержку
• Асимметричная маршрутизация и её влияние
• Обработка сообщений ICMP и обратные пути
• Эффекты сетевой инфраструктуры
• Когда это нормально, а когда вызывает беспокойство
• Устранение этого явления

Как traceroute на самом деле измеряет задержку

Traceroute измеряет не только одностороннюю задержку - он измеряет полное время кругового пути (RTT) до каждого хопа на пути. Это фундаментальное понятие, которое объясняет кажущееся парадоксом явление, с которым вы столкнулись.

Вот как работает этот процесс:

1. Увеличение TTL: Traceroute отправляет пакеты с возрастающими значениями TTL (Time To Live), начиная с TTL=1
2. Превышение TTL: Когда маршрутизатор получает пакет с TTL=1, он уменьшает TTL до 0, отбрасывает пакет и отправляет обратно сообщение ICMP “Time Exceeded”
3. Измерение кругового пути: Задержка, которую вы видите, включает в себя:
   • Время для достижения этим маршрутизатором пакета-зонда
   • Время для возврата сообщения ICMP “Time Exceeded” к вашему источнику

Как объясняет SanchitGurukul, “Увеличивая значение TTL пакетов и записывая ответы ICMP Time Exceeded от каждого маршрутизатора на пути, traceroute предоставляет подробную карту сетевого пути и измеряет время кругового пути для каждого хопа.”

Это означает, что когда вы видите 210 мс на 17-м хопе, вы измеряете:

• Время для вашего пакета, чтобы достичь маршрутизатора №17
• ПЛЮС время для ответа ICMP от маршрутизатора №17, чтобы вернуться к вам

Но когда вы видите 85 мс до конечного пункта назначения, вы измеряете:

• Время для вашего пакета, чтобы достичь сервера GCP
• ПЛЮС время для ответа от сервера GCP, чтобы вернуться к вам

Асимметричная маршрутизация и её влияние

Асимметричная маршрутизация является основной причиной этого явления. Она возникает, когда путь от источника к пункту назначения отличается от пути от пункта назначения обратно к источнику.

Согласно технической документации Lumen, “В обратном пути сообщения о превышении TTL могут следовать по другим путям, чем зонды в средах с асимметричной маршрутизацией (например, в интернете).”

Вот что это означает в вашем сценарии:

• Прямой путь к хопу №17: Ваши пакеты могут следовать относительно прямым или быстрым маршрутом
• Обратный путь от хопа №17: Сообщения ICMP “Time Exceeded” могут следовать совершенно другим, более длинным маршрутом обратно к вам
• Прямой путь к конечному пункту назначения: Ваши пакеты к GCP могут следовать одному оптимальному маршруту
• Обратный путь от конечного пункта назначения: Ответы от GCP могут следовать другому, но все еще эффективному маршруту обратно

Руководство NANOG подчеркивает этот момент: “Не только обратный путь скрыт, но он может быть совершенно другим на каждом хопе в прямом пути.”

Обработка сообщений ICMP и обратные пути

Сообщения ICMP “Time Exceeded” сами по себе могут испытывать задержки, которые не влияют на ваш фактический трафик данных:

1. Приоритетная обработка: Некоторые маршрутизаторы понижают приоритет ICMP-трафика по сравнению с обычными пакетами данных, как отмечено в обсуждении Reddit HomeNetworking

2. Затраты на обработку: Генерация и отправка ICMP-сообщений добавляет время обработки на каждом маршрутизаторе

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

Согласно Baeldung on Computer Science, “Когда первый маршрутизатор получает его, TTL достигает 0, и маршрутизатор отбрасывает пакет и отправляет обратно сообщение ICMP ‘Time Exceeded’ источнику.”

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

Эффекты сетевой инфраструктуры

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

MPLS и туннелирование

MPLS-сети часто создают неожиданное поведение traceroute, потому что:

• Пакеты могут быть туннелированы через сеть
• ICMP-ответы могут приходить с дальнего конца туннелей, а не с промежуточных маршрутизаторов
• Это может создать впечатление, что задержка “скачет” через несколько хопов

Как объясняется в блоге School SysAdmin, “Маршрутизаторы MPLS-туннелей (P LSR) с настроенным ICMP-туннелированием в итоге будут ‘сообщать’ о многих RTT с дальнего конца туннеля.”

Балансировка нагрузки и мультипутевая маршрутизация

Когда сети используют балансировку нагрузки или мультипутевую маршрутизацию:

• Разные traceroute-зонды могут следовать по разным путям
• В документации Lumen отмечается, что “для traceroute возможно, что каждый пакет, будь то зонды или сообщение о превышении TTL, следует по пути, уникальному для других traceroute-пакетов”

Это изменение пути может вызывать непоследовательные показания задержки на разных хопах.

Различия в конфигурации маршрутизаторов

Разные маршрутизаторы могут иметь:

• Различные возможности обработки ICMP
• Разные политики управления очередями
• Асимметричное распределение пропускной способности в разных направлениях

Когда это нормально, а когда вызывает беспокойство

Не все случаи высокой задержки на промежуточных хопах указывают на проблемы. Вот как отличить нормальные ситуации от вызывающих беспокойство:

Нормальные ситуации

• Асимметричная маршрутизация распространена в интернете и облачных средах
• Периодическая высокая задержка на определенных хопах, которая не влияет на фактическую производительность приложений
• Последовательные паттерны, где одни и те же хопы показывают высокую задержку при множественных тестах
• Задержка до конечного пункта назначения остается низкой и стабильной

Ситуации, вызывающие беспокойство

• Последовательно высокая задержка на одном и том же хопе при множественных traceroute
• Потеря пакетов appearing на промежуточных хопах
• Паттерны нарастания задержки, которые указывают на перегрузку
• Деградация фактической производительности приложений несмотря на “хорошую” задержку до конечного пункта назначения

Согласно TelcoNotes, “если в этом звене не обнаружено проблем, то это может быть сложный случай асимметричной маршрутизации, где путь маршрутизации от источника к пункту назначения отличается от обратного пути (от пункта назначения обратно к источнику).”

Устранение этого явления

Если вы хотите провести дальнейшее расследование или подтвердить, влияет ли эта асимметричная маршрутизация на ваш фактический трафик:

Альтернативные методы тестирования

1. Тесты ping: Запустите ping как к промежуточным хопам, так и к конечному пункту назначения для сравнения односторонней задержки
2. MTR (My TraceRoute): Используйте mtr, который обеспечивает непрерывное тестирование и лучший статистический анализ
3. Двунаправленное тестирование: Выполните traceroute с обоих концов соединения

Анализ сети

1. Проверка на асимметрию: Сравните прямые и обратные traceroute
2. Мониторинг производительности приложений: Если ваши фактические приложения работают нормально, аномалия traceroute, вероятно, является лишь артефактом измерения
3. Использование нескольких путей: Тестируйте в разное время и из разных мест

Как предлагается на ServerFault, “Инструменты вроде mtr и traceroute измеряют только (обратную) задержку для конкретного зонда, который был отправлен к каждому промежуточному хопу в момент отправки - они не могут дать точную задержку для каждого такого пути.”

Заключение

Явление, которое вы наблюдаете - более высокая задержка на промежуточном хопе по сравнению с конечным пунктом назначения - обычно вызывается:

1. Круговой природой traceroute: Он измеряет как прямой, так и обратный пути, которые могут быть совершенно разными
2. Асимметричной маршрутизацией: Путь к промежуточным хопам может значительно отличаться от обратного пути
3. Обработкой сообщений ICMP: Ответы ICMP “Time Exceeded” могут следовать по разным маршрутам и испытывать разные задержки
4. Эффектами сетевой инфраструктуры: MPLS-туннели, балансировка нагрузки и конфигурации маршрутизаторов могут создавать эти различия

В большинстве случаев, особенно когда фактическая производительность вашего приложения к серверу GCP хороша, это является нормальным артефактом измерения, а не проблемой сети. Ключевым является сосредоточение на метриках фактической производительности вашего приложения, а не слишком беспокоиться о задержках на промежуточных хопах в выводе traceroute.

Источники

1. How traceroute works | Lumen
2. A Practical Guide to (Correctly) Troubleshooting with Traceroute | NANOG
3. How to Troubleshoot High Latency with Traceroute Command | TelcoNotes
4. Traceroute Operation: A Detailed Analysis of Path and Transit Delays | SanchitGurukul
5. The Limitations of Traceroute/Tracert | Baeldung on Computer Science
6. MPLS causes some weird effects - aka Why is traceroute so much slower than ping for some hops? | School SysAdmin
7. Can someone help me in understanding traceroute hops and why some routers in the middle have longer ms than the destination? | Reddit r/HomeNetworking
8. Does traceroute/MTR results in the same overall latency from src and dest direction and vice versa? | Server Fault