Почему пакет из Москвы в Питер идёт через Стокгольм: маршрутизация против географии

MAATRIX

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

Интернет — это не одна сеть, а тысячи договорившихся сетей

Первое, что стоит понять: единой «сети интернет» не существует. Есть несколько десятков тысяч автономных систем (autonomous system, AS) — это сети отдельных провайдеров, дата-центров, крупных компаний и государственных операторов, у каждой свой номер (ASN) и свой кусок инфраструктуры. Ваш трафик до конечной точки идёт не по одному проводу от отправителя к получателю, а прыжками — от одной автономной системы к другой, пока не доберётся до сети назначения.

Между собой автономные системы не связаны как попало. Связь появляется там, где два оператора физически проложили кабель друг к другу или подключились к общей точке обмена трафиком (IX, internet exchange), и договорились передавать трафик между своими сетями. Если такого договора и физического стыка между двумя провайдерами нет — прямого пути между ними просто не существует, сколько бы километров ни было между их дата-центрами по прямой.

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

Почему трафик между близкими городами уходит в объезд

Возьмём условный пример (без привязки к реальным операторам и маршрутам — просто чтобы показать механику). Есть провайдер A в одном городе и провайдер B в соседнем, географически они в паре сотен километров друг от друга. Но исторически оба развивали связность иначе: провайдер A подключён к крупному международному узлу обмена трафиком в одной стране, провайдер B — к другому крупному узлу в соседней стране. Прямого стыка друг с другом у A и B нет — экономически им это было не нужно: основные объёмы трафика каждый гонит в сторону своих транзитных партнёров, а не друг к другу напрямую.

Что произойдёт, когда клиент A отправит пакет клиенту B? Пакет пойдёт от A к его транзитному провайдеру, а тот — к своему пиринг-партнёру, у которого уже есть стык с сетью B. Если этот пиринг-партнёр физически расположен в третьей стране, пакет сделает крюк именно туда, а потом вернётся обратно к B — визуально это будет выглядеть как нелепый зигзаг на карте, хотя по факту это просто самый короткий путь по графу связности сетей, а не по физической географии.

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

BGP: как сети договариваются о маршрутах

Протокол, который решает, по какому пути пойдёт пакет между автономными системами, называется BGP (Border Gateway Protocol) — это стандартный протокол межсетевой маршрутизации, на котором фактически держится весь современный интернет. Каждая автономная система анонсирует через BGP своим соседям, какие диапазоны IP-адресов она обслуживает и через какие сети до них можно дойти. Получив такой анонс, соседняя сеть передаёт его дальше — так информация о маршрутах распространяется по всему интернету, и в итоге у каждого провайдера строится таблица: «чтобы попасть в такую-то подсеть, нужно отправить пакет вон в ту соседнюю сеть».

Принципиально важно: BGP выбирает маршрут не по физическому расстоянию и не по задержке. У протокола нет понятия «километры» или «миллисекунды» — он оперирует длиной маршрута в количестве промежуточных автономных систем (AS-path) и локальными политиками провайдера. А политика — это уже коммерческий вопрос: с кем есть договор о бесплатном обмене трафиком (пиринг), кому платят за транзит, какой путь дешевле для конкретного оператора. Провайдер может сознательно выбрать более длинный по хопам, но более дешёвый маршрут — и вы это увидите просто как «лишний» участок пути в traceroute.

Из-за этого один и тот же адрес назначения из разных точек мира — а иногда и из соседних городов одной страны — может быть доступен совершенно разными маршрутами, потому что у каждой сети свои договоры и своя таблица BGP. Если хотите разобраться в протоколе подробнее — в статье про BGP и почему один провайдер может «уронить» половину интернета разобран сам механизм анонсов и типичные аварии, к которым он приводит.

Как это выглядит на практике: traceroute с неожиданным крюком

Самый простой способ увидеть эффект — запустить traceroute (в Linux) или tracert (в Windows) до нужного адреса и посмотреть на промежуточные узлы:

traceroute -n 203.0.113.10

или, для более информативной картины с накоплением потерь по каждому хопу:

mtr -n 203.0.113.10

В выводе вы увидите список IP-адресов промежуточных маршрутизаторов и задержку до каждого из них. По имени хоста (если он не скрыт) часто можно понять, какому провайдеру и в каком городе принадлежит узел — например, аббревиатуры аэропортов в доменных именах магистральных операторов (fra, ams, lhr и подобные) обычно указывают на город, где стоит узел. Если между двумя близкими городами задержка вдруг «прыгает» на 20-40 мс на одном из промежуточных хопов — это обычно и есть тот самый уход трафика в третью точку ради стыка сетей.

Само по себе это не проблема — если итоговая задержка вас устраивает. Проблема начинается тогда, когда такой крюк утраивает время отклика для сервиса, чувствительного к задержке (голосовая связь, торговые системы, онлайн-игры, синхронная репликация баз данных). В таких случаях единственный рабочий способ разобраться — не гадать по карте, а посмотреть в traceroute от конкретной точки до конкретной точки. Как читать вывод traceroute и mtr и отличать нормальный рост задержки от реальной проблемы, подробно разобрано в статье про traceroute и ping через VPN.

Асимметрия: маршрут туда и обратно — разные вещи

Отдельная тонкость, которая усиливает эффект «маршрут не совпадает с географией»: путь пакета от A к B и путь ответа от B к A совсем не обязаны совпадать. Каждая сторона выбирает исходящий маршрут по своим собственным BGP-политикам, независимо от того, как шёл встречный трафик. В результате пакет туда может идти через один транзитный узел, а обратно — через другой, физически расположенный в другой стране.

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

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

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

Если задача чувствительна к задержке, единственный надёжный способ — не полагаться на предположение «раз дата-центры рядом, значит и пинг будет маленький», а измерить фактическую задержку между конкретными точками ещё до того, как вы завязались на конкретную локацию сервера. Методика такого измерения — через ping, traceroute и тест под реальной нагрузкой, а не разовый пинг с ноутбука — подробно описана в статье как измерить реальный пинг до сервера.

Практический вывод: проверяйте связность, а не смотрите на карту

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

Практически это значит:

• Не выбирайте локацию сервера только по стране или городу на карте — расстояние в километрах слабо коррелирует с задержкой.
• Перед тем как завязываться на конкретный дата-центр под задачу с низкой задержкой, снимите реальный traceroute или mtr от точки, откуда будет идти основной трафик, до кандидата на размещение.
• Если между двумя вашими серверами (например, приложением и базой) неожиданно большая задержка при формально «соседних» локациях — посмотрите путь пакета, а не считайте, что это аномалия мониторинга.
• Учитывайте, что маршрут может со временем меняться: операторы перезаключают договоры о пиринге, добавляют новые точки обмена трафиком — вчерашний крюк через третью страну через полгода может исчезнуть, и наоборот.
• Для по-настоящему критичных к задержке связок закладывайте не единственный вариант локации, а два-три кандидата и сравнивайте их по факту, а не по предположению.

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

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