Клиенты из Азии: почему до Европы у них иногда быстрее, чем до США

MAATRIX

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

Здравый смысл по карте и почему он подводит

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

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

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

Откуда берётся неравномерность связности

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

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

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

Добавьте к этому, что у каждого провайдера в конкретной стране Азии — свои договорённости о пиринге и транзите, свои арендованные каналы на конкретных кабельных системах, свои точки выхода в магистральный интернет. Разбор устройства этого рынка есть в статье про пиринг и транзит простыми словами — там объясняется, почему скорость сети сильнее зависит от договорённостей оператора, чем от железа в дата-центре.

Почему маршрут — это не прямая линия

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

Если у оператора клиента в Азии есть прямой качественный пиринг с крупным европейским хабом (например, через одну из международных точек обмена трафиком) — трафик до Европы может идти всего через 2-4 сетевых перехода (hop) по хорошо загруженным, малозагруженным магистральным каналам. А трафик до США у того же оператора может идти через больше промежуточных сетей, с транзитом через посредников, каждый из которых добавляет и задержку, и потенциальные точки перегрузки в часы пик.

Практически это можно увидеть самому — командой traceroute или mtr с точки, близкой к целевой аудитории (или через сервис вроде globalping), сравнив путь до IP в европейском дата-центре и до IP в американском:

mtr --report --report-cycles 50 <IP-сервера-в-Европе>
mtr --report --report-cycles 50 <IP-сервера-в-США>

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

Разница между "ближе на карте" и "ближе по сети"

Стоит явно развести два разных понятия расстояния, которые интуитивно сливаются в одно:

• Географическое расстояние — то, что вы видите на карте или гуглите как расстояние между городами по прямой (great circle distance). Задаёт теоретический физический минимум задержки (скорость света в оптоволокне конечна), но на практике почти никогда не совпадает с фактическим маршрутом.
• Сетевое расстояние — количество хопов, качество каналов на каждом участке, загруженность транзитных сетей и наличие прямого пиринга между операторами клиента и сервера. Именно это определяет реальную задержку, которую увидит пользователь.

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

Для азиатско-американского и азиатско-европейского направлений эта разница усугубляется ещё и тем, что часть трафика из Азии до США физически идёт через Тихий океан, а часть — в обход, через Европу или Ближний Восток, в зависимости от того, где у конкретного оператора есть ёмкость и договорённости. Какой из этих путей окажется быстрее для конкретного клиента — заранее по карте не предскажешь.

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

Важная оговорка, которую нельзя пропустить: эффект «Европа быстрее США из Азии» не universal и не постоянен. Он проявляется:

• По-разному в разных странах региона. Условия связности сильно отличаются между, скажем, Юго-Восточной Азией, Южной Азией и Восточной Азией — в каждом регионе своя история прокладки кабелей и своя структура рынка интернет-провайдеров.
• По-разному у разных провайдеров внутри одной страны. Крупный национальный оператор и небольшой региональный ISP могут иметь совершенно разные договорённости о пиринге и, соответственно, разные оптимальные маршруты — даже находясь в одном городе.
• По-разному в зависимости от типа трафика и времени суток. Магистральные каналы могут быть перегружены в часы пик на одном направлении и свободны на другом; маршрут, который был оптимален полгода назад, может измениться из-за нового пирингового соглашения, аварии на кабеле или перебалансировки трафика оператором.
• Меняется во времени. Новые кабельные системы вводятся в строй, старые модернизируются или выводятся из эксплуатации, операторы меняют пиринговые стратегии — картина сетевой связности не статична.

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

Что с этим делать на практике

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

Практический план:

1. Определите, откуда реально приходит аудитория. Не «Азия» вообще, а конкретные страны и, по возможности, конкретные операторы связи (по ASN в аналитике или логах).
2. Замерьте задержку до кандидатов-локаций с точек, близких к аудитории. Используйте распределённые сервисы измерения (например, globalping или аналогичные) или RUM-метрики (Real User Monitoring) с реальных пользователей, если у вас уже есть трафик.
3. Сравните не только среднюю задержку, но и перцентили. Средняя может выглядеть неплохо, а p95/p99 — выдавать периодические скачки, которые как раз и укажут на нестабильный транзитный участок маршрута.
4. Перепроверяйте периодически. Раз в несколько месяцев или при заметном росте/смене аудитории — сеть меняется, и однажды сделанный вывод может устареть.

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

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

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