Сервер во Франкфурте оказался быстрее московского для клиентов из Москвы: разбираем маршрут

MAATRIX

Команда переносит сервис в Москву, потому что «аудитория в России — сервер должен быть в России», а после переезда задержка у части пользователей не падает, а растёт. Замеряют — и оказывается, что тестовый сервер во Франкфурте, за две тысячи километров, отвечает быстрее московского. Это не глюк измерений и не совпадение: расстояние на карте и задержка в сети — разные величины, и путать их — частая и дорогостоящая ошибка при выборе локации.

Почему «ближе» на карте не значит «быстрее» в сети

Задержка (latency, обычно измеряется как RTT — round-trip time, время туда-обратно) зависит не от километров по прямой, а от конкретного маршрута, по которому пакет реально идёт между вашим провайдером и сетью сервера. Пакет не летит по геодезической линии — он проходит через цепочку автономных систем (AS), и каждая AS решает, куда передать пакет дальше, основываясь на BGP-маршрутах, которые ей известны. Итоговый путь — это сумма локальных решений множества независимых операторов, а не оптимизация по расстоянию.

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

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

Из чего складывается задержка на самом деле

Полезно разложить итоговый RTT на компоненты, чтобы видеть, где действительно теряется время:

1. Физическая длина маршрута — не по прямой, а по фактически проложенным волоконно-оптическим линиям и подводным кабелям, которые сами по себе редко идут по кратчайшей траектории.
2. Количество хопов (промежуточных маршрутизаторов и AS) — на каждом хопе пакет обрабатывается, ставится в очередь, иногда буферизуется; это доли миллисекунды на хоп, но при десятке-полутора хопов набегает заметная величина.
3. Тип стыка между сетями на каждом хопе — прямой пиринг между двумя AS обычно даёт минимальную задержку и предсказуемую нагрузку; транзит через третью, а тем более четвёртую сеть добавляет и задержку, и риск затора в часы пик у транзитного оператора.
4. Загрузка канала на узких местах маршрута — даже хороший маршрут может «затыкаться» в конкретной точке обмена трафиком в пиковые часы, если там недостаточно ёмкости.
5. Асимметрия маршрута — путь «туда» и путь «обратно» между одними и теми же точками нередко идут по разным цепочкам AS и с разной задержкой; итоговый RTT — это сумма обоих направлений, и одно из них может быть заметно хуже другого.

Ни расстояние по прямой, ни название города дата-центра не говорят вам напрямую ни про один из этих пяти пунктов. Узнать их можно только измерив маршрут по факту.

Пиринг и транзит: почему это решает больше, чем километры

Ключевое понятие здесь — разница между пирингом и транзитом.

Пиринг (peering) — это прямое соединение между двумя сетями, обычно на нейтральной площадке — точке обмена трафиком (IX, Internet Exchange), где десятки и сотни операторов подключены к общей коммутационной инфраструктуре и обмениваются трафиком напрямую, без посредников. Если сеть вашего провайдера и сеть дата-центра пиринговались напрямую (или через одного общего партнёра) на такой площадке, пакет идёт по короткому пути буквально в один-два хопа между границами сетей.

Транзит (transit) — это ситуация, когда прямого стыка нет, и одна сеть покупает доступ к остальному интернету у вышестоящего провайдера (upstream). Пакет в этом случае проходит не только через сети отправителя и получателя, но и через одного или нескольких транзитных операторов между ними — у каждого свои маршрутизаторы, своя загрузка, свои внутренние приоритеты.

Практический вывод из этой разницы: у крупных дата-центровых хабов — Франкфурта, Амстердама, Лондона — исторически огромная плотность пиринга. Там расположены одни из крупнейших точек обмена трафиком в мире, и через них проходят прямые стыки с сетями провайдеров по всему миру, включая российских операторов, у которых там есть точки присутствия именно ради качественной связности на запад. Московский дата-центр, если оператор конкретного провайдера физически не пирингуется с ним напрямую (а держит трафик через транзитного оператора с недостаточно оптимальной внутренней маршрутизацией или временной перегрузкой), может проигрывать по факту, даже находясь в том же городе, что и клиент.

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

Как выглядит «плохой» маршрут до близкого сервера

Чтобы это не звучало абстрактно, разберём иллюстративный (не измеренный, а типовой) сценарий — он собран из логики того, как обычно ломается маршрутизация, без привязки к конкретным реальным цифрам:

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

Условно маршрут может выглядеть так (иллюстрация структуры, не реальный трейс):

1  домашний роутер
2  граница сети провайдера (Москва)
3  магистральный узел провайдера
4  транзитный оператор, узел A
5  транзитный оператор, узел B (может быть в другом городе или даже стране —
   транзитные сети не обязаны прокладывать маршрут кратчайшим путём)
6  стык транзитного оператора с сетью дата-центра
7  граница сети дата-центра (Москва)
8  сервер

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

1  домашний роутер
2  граница сети провайдера (Москва)
3  магистральный узел провайдера
4  выход на международный аплинк
5  точка обмена трафиком, прямой пиринг с сетью дата-центра
6  граница сети дата-центра (Франкфурт)
7  сервер

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

Как проверить маршрут и задержку самостоятельно

Единственный надёжный способ узнать, какая ситуация у вас — не гадать по карте, а измерить. Базовый инструмент — traceroute (в Linux) или tracert (в Windows), но для нормального анализа лучше mtr, который совмещает трассировку маршрута с непрерывным замером задержки и потерь на каждом хопе:

mtr -rwzbc 100 target-server-ip

Флаги: -r — отчётный (report) режим вместо интерактивного, -w — не сокращать длинные имена хостов, -z — показывать номера AS на каждом хопе (когда доступно), -b — показывать и имя, и IP, -c 100 — сделать 100 циклов замеров для статистически осмысленной картины, а не одного случайного пинга.

В выводе mtr смотрите на три вещи:

• Число хопов до цели. Если хопов заметно больше, чем ожидалось бы для формально близкого сервера — вероятно, трафик идёт транзитом, а не по прямому пирингу.
• Скачок задержки на конкретном хопе. Если между двумя соседними хопами задержка резко прыгает на существенную величину — именно там находится узкое место маршрута; часто это граница между провайдером и транзитным оператором.
• Потери пакетов (Loss%) на промежуточных хопах. Небольшие потери на одном хопе, которые не повторяются дальше по маршруту, обычно не страшны (транзитные роутеры иногда сами игнорируют часть ICMP-пакетов) — тревожный сигнал, когда потери держатся стабильно и до самого целевого сервера.

Дополнительно полезно посмотреть, через какие AS реально идёт маршрут — mtr -z показывает ASN на каждом хопе, а онлайн-инструменты вроде RIPEstat (stat.ripe.net) или looking-glass серверов крупных операторов позволяют посмотреть BGP-таблицу и понять, транзит это или прямой пиринг между конкретными сетями. Если у провайдера или дата-центра есть свой looking glass (веб-интерфейс для запуска traceroute и BGP-запросов прямо из их сети) — это ещё один источник данных, причём измеренный уже с их стороны, а не только с вашей.

Для веб-сервисов дополнительно стоит замерить не только сетевой RTT, но и время до первого байта ответа:

curl -o /dev/null -s -w "DNS: %{time_namelookup}s\nTCP connect: %{time_connect}s\nTLS: %{time_appconnect}s\nTTFB: %{time_starttransfer}s\nTotal: %{time_total}s\n" https://target-host.example

Это разделяет сетевую составляющую (connect, TLS handshake) и серверную (TTFB) — если проблема не в маршруте, а в бэкенде, эта команда покажет это сразу, и вы не будете чинить маршрутизацию там, где на самом деле тормозит база данных.

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

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

1. Не выбирайте локацию только по физической близости к аудитории. Это разумная отправная точка, но не финальное решение — она задаёт короткий список кандидатов, а не готовый ответ.
2. Тестируйте задержку с точки зрения реальной аудитории, а не абстрактно. Идеально — попросить нескольких реальных пользователей из целевого региона прогнать mtr или ping до тестовых серверов в нескольких локациях-кандидатах и прислать результат. Если такой возможности нет, используйте распределённые измерительные сети вроде RIPE Atlas (у неё тысячи зондов, установленных у операторов и в дата-центрах по всему миру) или сервисы сетевого мониторинга с точками измерения в нужном регионе.
3. Проверяйте несколько локаций-кандидатов параллельно, а не одну «очевидную». Если аудитория в Москве, не поленитесь замерить не только московский дата-центр, но и один-два зарубежных хаба с плотным пирингом — Франкфурт, Амстердам — прежде чем принимать решение. Иногда выигрывает ожидаемый вариант, иногда — нет; узнать заранее без измерения нельзя.
4. Смотрите не только на средний RTT, но и на стабильность. Маршрут с чуть большей средней задержкой, но без скачков и потерь, часто даёт лучший пользовательский опыт, чем маршрут с меньшим средним, но нестабильный в часы пиковой нагрузки. Мерьте не один раз, а в течение нескольких дней и в разное время суток.
5. Проверяйте маршрут периодически, а не только один раз при выборе. Пиринговые отношения между операторами меняются: сеть может пересмотреть договор о прямом пиринге, перегрузить транзитный канал новым трафиком или, наоборот, наладить прямой стык там, где раньше был долгий транзит. Маршрут, оптимальный сегодня, не гарантированно останется таким через год.
6. Не путайте это с более широким мифом «чем ближе, тем быстрее». Разница между расстоянием и задержкой — лишь часть картины: даже при идеальном маршруте на итоговое время ответа сайта сильно влияют бэкенд, кэширование и CDN — это разобрано отдельно в статье про миф «чем ближе сервер, тем быстрее».

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

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