Как работает anycast и почему один IP отвечает из разных стран

MAATRIX

Наберите 1.1.1.1 с сервера в Москве, потом с сервера в Нью-Йорке и в Сингапуре — и в каждом случае получите быстрый ответ, будто этот адрес стоит прямо в соседней стойке. IP-адрес при этом один и тот же, физического сервера с таким адресом «на всех» не существует, и никакой магии тут нет — есть механизм маршрутизации anycast, который использует обычную логику BGP так, что один адрес одновременно «живёт» в десятках точек планеты. Разберёмся, как это устроено технически, почему «ближайшая точка» — понятие сетевое, а не географическое, и где вы сталкиваетесь с anycast каждый день, даже не замечая этого.

Unicast и anycast: что в действительности отличается

В привычной схеме — unicast — один IP-адрес принадлежит одному физическому узлу в одном дата-центре. Арендуете VPS в Лондоне — его адрес ведёт ровно на этот сервер, и запрос из любой точки мира летит именно туда: у пакета один пункт назначения, и точка.

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

Важная деталь: anycast — не отдельный протокол и не какая-то надстройка поверх IP. Это просто способ анонсировать существующий IP-префикс в BGP — тот же механизм, которым любой провайдер объявляет свои сети, только один и тот же блок адресов анонсируется не из одного места, а сразу из нескольких. Работает и для IPv4, и для IPv6, и исторически первым массовым применением как раз стали DNS-серверы — потому что для короткого UDP-запроса схема подходит почти идеально (об этом ниже).

Как один IP объявляется одновременно из нескольких стран

Чтобы один префикс «жил» в разных странах, нужны три вещи:

1. Собственный блок IP-адресов (PI, provider-independent), который можно анонсировать независимо от того, кто предоставляет транзит — такие блоки выделяют региональные интернет-регистратуры (RIPE, ARIN, APNIC и другие).
2. Собственный номер автономной системы (AS) — идентификатор, под которым эта сеть представлена в глобальной таблице маршрутизации.
3. Точки присутствия в нескольких дата-центрах, в каждой из которых стоит маршрутизатор, устанавливающий BGP-сессии с локальными провайдерами или точками обмена трафиком (IX) и анонсирующий один и тот же префикс.

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

# фрагмент таблицы маршрутов на транзитном роутере
# префикс 198.51.100.0/24 анонсируется из двух точек одной сетью

198.51.100.0/24  next-hop: 203.0.113.1   as-path: 64496            (анонс из Роттердама)
198.51.100.0/24  next-hop: 203.0.113.9   as-path: 64496 64511 65000 (анонс из Сингапура)

Роутер видит два пути к одному и тому же префиксу и по своим правилам выбирает один — обычно тот, у которого короче as-path (меньше промежуточных автономных систем) и который пришёл с более высоким локальным приоритетом. Дальше пакет от конкретного клиента идёт именно по выбранному маршруту, а клиент из другой части света на другом транзитном роутере получит другое решение — и уедет во вторую точку. Никакого центрального «диспетчера», который бы явно направлял трафик, нет: маршрутизация происходит децентрализованно, каждый роутер решает сам за себя на основе того, что видит в своей таблице.

Если один узел падает — физически или из-за перегрузки, — анонс с него просто снимается (BGP withdrawal), и трафик автоматически перетекает на оставшиеся точки без вмешательства человека. Это и даёт anycast-сетям устойчивость к отказу отдельного узла: с точки зрения внешнего мира адрес продолжает отвечать, просто теперь отовсюду отвечает уже оставшийся набор точек.

Почему «ближайшая точка» — это ближайшая по BGP, а не на карте

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

• локальный приоритет (local preference), который сеть-получатель настраивает сама, часто исходя из коммерческих договорённостей с провайдером маршрута;
• длина as-path — количество автономных систем, через которые нужно пройти;
• происхождение маршрута и MED (multi-exit discriminator);
• при полном равенстве — более старый маршрут или наименьший router ID как формальный тай-брейк.

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

Наглядный пример: провайдер в Казахстане может не иметь прямого пиринга с anycast-оператором в точке присутствия в Москве, зато имеет прямой транзит через европейского оператора — и тогда пользовательский трафик из Алма-Аты физически уедет во Франкфурт, хотя географически Москва ближе. С точки зрения BGP-алгоритма выбранный маршрут при этом абсолютно корректен — он просто «предпочтительный», а не «самый близкий по карте». Такие несовпадения называют аномалиями catchment-области (зоны обслуживания конкретной точки anycast), и крупные операторы их отслеживают через измерительные платформы вроде RIPE Atlas, постоянно донастраивая пиринг и local preference, чтобы подтянуть фактическое распределение трафика ближе к географически логичному.

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

Anycast и TCP: где это работает идеально, а где есть нюанс

Anycast изначально и лучше всего подходит для запросов без состояния — классический пример это DNS по UDP. Каждый пакет-запрос маршрутизируется независимо от предыдущего: клиент отправил один UDP-пакет, получил один UDP-пакет в ответ, и совершенно не важно, обработал ли этот запрос тот же самый физический сервер, что и предыдущий. Именно поэтому корневая DNS-инфраструктура и публичные резолверы стали первыми и самыми массовыми пользователями технологии.

С TCP-сессиями (а поверх TCP работают HTTP/HTTPS, то есть большая часть веб-трафика через CDN) ситуация тоньше. TCP-соединение — это состояние: номера последовательности, таймауты, установленное на конкретном сервере соединение. Если посреди активной TCP-сессии BGP-маршрут вдруг «перескочит» на другую anycast-точку (route flap — например, из-за изменения пиринга или временной нестабильности апстрима), последующие пакеты той же сессии могут прилететь на физически другой сервер, который ничего не знает об уже установленном соединении. Формально TCP-стек примет такие пакеты за ошибку и, скорее всего, сессия оборвётся — клиенту придётся переустанавливать соединение заново.

На практике BGP-маршруты в стабильной сети меняются не поминутно, а редко, так что для большинства коротких HTTP-запросов проблема почти никогда не проявляется — соединение успевает завершиться раньше, чем случится флап. Для по-настоящему долгоживущих соединений (потоковое видео, WebSocket, долгие файловые передачи) риск выше, и именно поэтому крупные CDN не полагаются на голый anycast как на единственный механизм: конкретные технические решения у каждого провайдера свои и не публикуются полностью, но общий принцип — anycast используется на уровне «доставить клиента до ближайшего фронта», а дальше подключается прикладная логика (устойчивые сессии, дополнительная маршрутизация на уровне приложения), которая старается не терять состояние даже при изменении сетевого пути. Знать этот нюанс полезно: если вы сами проектируете сервис поверх anycast-адреса (например, арендуете точку у anycast-провайдера защиты от DDoS), закладывайте reconnect-логику на клиенте, а не полагайтесь на то, что TCP-сессия проживёт вечно без единого сбоя маршрута.

Anycast в том, чем вы пользуетесь каждый день

Технология выглядит абстрактно, пока не разложить её на знакомые вещи:

Если вы арендуете обычный VPS с unicast-адресом и думаете о защите от нагрузки или атак, разумный путь — не пытаться повторить anycast самостоятельно (это инфраструктура уровня сетевого оператора со своим AS и десятками пиринговых договорённостей), а подключить готовый anti-DDoS сервис, который anycast использует «под капотом» на своей стороне. Практические шаги для сервера уже описаны в статье про защиту от DDoS на выделенном сервере. А если задача — просто снизить задержку для аудитории из разных регионов без собственной AS-инфраструктуры, рабочая и куда более доступная альтернатива — несколько unicast-серверов в разных локациях плюс GeoDNS, который отвечает разным IP в зависимости от региона запроса; подробный разбор разницы между двумя подходами есть в статье Anycast и обычный сервер: разница.

Как самому увидеть anycast в деле

Проверить, что перед вами именно anycast-адрес, а не обычный unicast-сервер, можно без специальных инструментов оператора:

1. Сравните трассировку из разных точек. Запустите mtr или traceroute до одного и того же IP с серверов в разных странах — например, если у вас есть VPS в России, США и Великобритании, самое время ими воспользоваться. Для unicast-адреса пути из разных стран будут сходиться к одному и тому же финальному хопу и одному дата-центру. Для anycast-адреса маршруты из разных регионов часто вообще не пересекаются в последних хопах — это разные физические сети.

   # с сервера в РФ
   mtr -rw -c 20 1.1.1.1

   # с сервера в США
   mtr -rw -c 20 1.1.1.1

   # сравните финальные хопы — для anycast они будут отличаться

1. Сравните задержку. У unicast-сервера один регион всегда покажет заметно бóльший пинг, чем «домашний» для этого сервера — запрос физически летит дальше. У anycast-адреса задержка из разных регионов держится в похожем, стабильно невысоком диапазоне — потому что каждый регион фактически бьёт в свою локальную точку.
2. Посмотрите на анонсы префикса через looking glass. Публичные инструменты вроде bgp.he.net или stat.ripe.net позволяют увидеть, из скольких разных мест (и разными путями) в глобальной таблице маршрутизации виден один и тот же префикс. Если один и тот же блок адресов анонсируется несколькими AS-путями с существенно разной географией транзита — это характерный признак anycast-развёртывания.
3. Проверьте DNS-резолверы. Отправьте DNS-запрос на 1.1.1.1 с серверов в разных странах и сравните время ответа — оно будет низким и похожим везде, что и есть практический смысл anycast для этого конкретного применения.

Если вы вообще ищете, как устроен путь DNS-запроса от клиента до ответа, — механику разбирали отдельно в статье как DNS-запрос обходит полмира; anycast — как раз одна из причин, почему на практике этот путь оказывается короче, чем кажется по глобусу.

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