Anycast
Anycast — это метод сетевой адресации и маршрутизации , при котором один IP-адрес используется устройствами (обычно серверами) в нескольких местах. Маршрутизаторы направляют пакеты, адресованные этому пункту назначения, в ближайшее к отправителю местоположение, используя свои обычные алгоритмы принятия решений , обычно наименьшее количество BGP сетевых переходов . Маршрутизация Anycast широко используется сетями доставки контента, такими как веб-серверы и серверы имен , чтобы приблизить контент к конечным пользователям.
Методы адресации
[ редактировать ]| Схемы маршрутизации |
|---|
| Одноадресная рассылка
|
| Транслировать
|
| Многоадресная рассылка
|
| Anycast
|
существует четыре основных метода адресации В Интернет-протоколе :
- Одноадресная рассылка доставляет сообщение одному конкретному узлу, используя связь «один к одному» между отправителем и пунктом назначения: каждый адрес назначения уникально идентифицирует одну конечную точку получателя.
- Широковещательная рассылка доставляет сообщение всем узлам сети, используя связь «один ко всем» ; одна дейтаграмма (или пакет ) от одного отправителя маршрутизируется ко всем возможным нескольким конечным точкам, связанным с широковещательным адресом . Сеть автоматически реплицирует дейтаграммы по мере необходимости, чтобы охватить всех получателей в пределах широковещательной рассылки, которая обычно представляет собой всю подсеть сети .
- Многоадресная рассылка доставляет сообщение группе узлов, которые выразили заинтересованность в получении сообщения, используя ассоциацию «один ко многим из многих» или «многие ко многим из многих» ; дейтаграммы маршрутизируются одновременно за одну передачу многим получателям. Многоадресная рассылка отличается от широковещательной передачи тем, что адрес назначения обозначает подмножество, а не обязательно все доступные узлы.
- Anycast доставляет сообщение любому из группы узлов, обычно ближайшему к источнику, используя метод « один к одному из многих». [1] ассоциация, при которой дейтаграммы направляются любому члену группы потенциальных получателей, которые идентифицируются одним и тем же адресом назначения. Алгоритм маршрутизации выбирает одиночный приемник из группы на основе того, который является ближайшим по некоторому расстоянию или показателю стоимости.
История
[ редактировать ]Первое задокументированное использование произвольной маршрутизации для топологической балансировки нагрузки подключенных к Интернету служб было в 1989 году; [2] [3] Впервые этот метод был официально задокументирован в IETF четыре года спустя. [4] Впервые он был применен к критической инфраструктуре в 2001 году с помощью произвольной рассылки имен I. корневого сервера [3]
Ранние возражения
[ редактировать ]Ранние возражения против развертывания произвольной маршрутизации были связаны с предполагаемым конфликтом между долгоживущими TCP- соединениями и нестабильностью маршрутизируемой топологии Интернета. Теоретически, долгоживущее соединение, такое как передача файлов по FTP (для больших файлов это может занять несколько часов), может быть перенаправлено на другой экземпляр Anycast в середине соединения из-за изменений в топологии сети или маршрутизации. в результате сервер меняет промежуточное соединение, а новый сервер не знает о соединении и не имеет состояния TCP-соединения предыдущего экземпляра произвольной рассылки.
На практике подобных проблем не наблюдалось, и к началу 2000-х годов эти возражения рассеялись. Многие первоначальные развертывания произвольной рассылки состояли из DNS-серверов, использующих преимущественно транспорт UDP. [5] [3] Измерения долгосрочных потоков произвольной рассылки выявили очень мало сбоев из-за коммутаторов экземпляров в середине соединения, гораздо меньше (менее 0,017 %) [6] или «менее одного потока на десять тысяч в час продолжительности» [2] по разным данным), чем были отнесены к другим причинам неудачи. Было разработано множество механизмов для эффективного обмена состоянием между экземплярами Anycast. [7] А некоторые протоколы на основе TCP, в частности HTTP, включали механизмы «перенаправления», посредством которых адреса служб произвольной рассылки могли использоваться для поиска ближайшего экземпляра службы, после чего пользователь был перенаправлен на этот конкретный экземпляр до начала любого долгосрочного запроса. жила транзакция с состоянием. [2] [8]
Интернет-протокол версии 4
[ редактировать ]Anycast может быть реализован через протокол пограничного шлюза (BGP). Многим хостам (обычно в разных географических регионах) предоставляется один и тот же одноадресный IP-адрес, и через BGP объявляются разные маршруты к этому адресу. Маршрутизаторы считают, что это альтернативные маршруты к одному и тому же пункту назначения, хотя на самом деле это маршруты к разным пунктам назначения с одним и тем же адресом. Как обычно, маршрутизаторы выбирают маршрут по используемому показателю расстояния (наименьшая стоимость, наименьшая перегруженность, кратчайший). Выбор маршрута в этой настройке равнозначен выбору пункта назначения.
Интернет-протокол версии 6
[ редактировать ]Anycast явно поддерживается в архитектуре адресации IPv6 . [9] Самый низкий адрес в подсети IPv6 (идентификатор интерфейса 0) зарезервирован как произвольный адрес «Маршрутизатор подсети». Кроме того, самые высокие 128 идентификаторов интерфейса в подсети также зарезервированы как адреса произвольной рассылки. [10]
Большинство маршрутизаторов IPv6 на пути произвольного пакета через сеть не отличят его от одноадресного пакета, но требуется специальная обработка со стороны маршрутизаторов рядом с пунктом назначения (то есть в пределах диапазона произвольного адреса), поскольку они должны направить пакет произвольной рассылки на «ближайший» интерфейс в этой области, который имеет правильный адрес произвольной рассылки, в соответствии с мерой расстояния ( прыжки используемой , стоимость и т. д.).
Используемый в IPv4 метод объявления нескольких маршрутов в BGP для одноадресных адресов с множественным назначением также все еще работает в IPv6 и может использоваться для маршрутизации пакетов к ближайшему из нескольких географически разнесенных хостов с одним и тем же адресом. Этот подход, который не зависит от маршрутизаторов с поддержкой Anycast, имеет те же варианты использования, а также те же проблемы и ограничения, что и IPv4.
Приложения
[ редактировать ]С развитием Интернета к сетевым сервисам предъявляются все более высокие требования к доступности. В результате популярность услуг Anycast среди сетевых операторов возросла. [11]
Система доменных имен
[ редактировать ]Все корневые серверы имен Интернета реализованы как кластеры хостов с использованием произвольной адресации. [12] Все 13 корневых серверов A–M существуют в разных местах, из них 11 — на разных континентах. (Корневые серверы B и H существуют в двух местах в США.) [13] [14] [15] Серверы используют объявления произвольных адресов для предоставления децентрализованных услуг. Это ускорило развертывание физических (а не логических) корневых серверов за пределами США . Многие коммерческие поставщики DNS перешли на среду произвольной рассылки IP, чтобы повысить производительность и избыточность запросов, а также реализовать балансировку нагрузки. [3]
Переход на IPv6
[ редактировать ]При переходе с IPv4 на IPv6 может быть развернута произвольная адресация для обеспечения совместимости IPv6 с хостами IPv4. Этот метод 6to4 использует шлюз по умолчанию с IP-адресом 192.88.99.1 . [16] Это позволяет нескольким провайдерам реализовать шлюзы 6to4 , при этом хостам не нужно знать адреса шлюзов каждого отдельного провайдера. 6to4 устарел [17] в ответ на распространение собственного IPv6.
Сети доставки контента
[ редактировать ]Сети доставки контента могут использовать Anycast для реальных HTTP- соединений со своими центрами распространения или для DNS . Поскольку большинство HTTP-соединений к таким сетям запрашивают статический контент, такой как изображения и таблицы стилей , они, как правило, недолговечны и не сохраняют состояние в последующих сеансах TCP. Общая стабильность маршрутов и отсутствие состояния соединений делают Anycast подходящим для этого приложения, даже несмотря на то, что оно использует TCP . [6] [2]
Связь между сетью Anycast и Multicast
[ редактировать ]Точку встречи Anycast можно использовать в протоколе обнаружения источника многоадресной рассылки (MSDP) и его выгодном применении, поскольку Anycast RP — это внутридоменная функция, обеспечивающая возможности резервирования и распределения нагрузки. Если используется несколько точек встречи Anycast, IP-маршрутизация автоматически выберет топологически ближайшую точку встречи для каждого источника и получателя. Это обеспечит многоадресную сеть с требованиями отказоустойчивости. [18]
Безопасность
[ редактировать ]Anycast позволяет любому оператору, чья информация о маршрутизации принимается промежуточным маршрутизатором, перехватывать любые пакеты, предназначенные для адреса Anycast. Хотя на первый взгляд это кажется небезопасным, оно ничем не отличается от маршрутизации обычных IP-пакетов и не является более или менее безопасным. Как и в случае с традиционной IP-маршрутизацией, тщательная фильтрация того, кому разрешено и кому не разрешено распространять объявления о маршрутах, имеет решающее значение для предотвращения «человек посередине» или атак «черная дыра» . Первое также можно предотвратить путем шифрования и аутентификации сообщений, например, с помощью Transport Layer Security , тогда как второе можно предотвратить с помощью луковой маршрутизации .
Надежность
[ редактировать ]Anycast обычно отличается высокой надежностью, поскольку может обеспечить автоматическое переключение при сбое без усложнения или появления новых потенциальных точек отказа. Приложения Anycast обычно имеют внешний «пульсирующий» мониторинг работы сервера и отменяют объявление маршрута в случае сбоя сервера. В некоторых случаях это делается реальными серверами, объявляющими префикс Anycast маршрутизатору через OSPF или другой IGP . Если серверы умрут, маршрутизатор автоматически отзовет объявление. Функциональность «Heartbeat» важна, поскольку, если объявление о неисправном сервере продолжится, сервер будет действовать как «черная дыра» для ближайших клиентов; это наиболее серьезный вид сбоя для системы произвольной рассылки. Даже в этом случае такой сбой приведет только к полному сбою для клиентов, которые находятся ближе к этому серверу, чем к любому другому, и не вызовет глобального сбоя. Однако даже автоматизация, необходимая для реализации отмены «пульсовой» маршрутизации, сама по себе может добавить потенциальную точку отказа, как показано на примере Отключение Facebook в 2021 году .
Смягчение атак типа «отказ в обслуживании»
[ редактировать ]При атаках типа «отказ в обслуживании» мошеннический сетевой узел может рекламировать себя как сервер произвольной рассылки для жизненно важной сетевой службы, предоставлять ложную информацию или просто блокировать службу.
Методологии Anycast в Интернете могут использоваться для распространения DDoS- атак и снижения их эффективности: поскольку трафик направляется на ближайший узел (процесс, над которым злоумышленник не имеет контроля), поток DDoS-трафика будет распределяться между ближайшими узлами. Таким образом, не все узлы могут быть затронуты. Это может быть причиной для развертывания произвольной адресации. [19] Однако эффективность этого метода зависит от сохранения секретности любых одноадресных адресов, связанных с узлами службы произвольной рассылки, поскольку злоумышленник, владеющий одноадресными адресами отдельных узлов, может атаковать их из любого места, минуя методы произвольной адресации. [20]
Локальные и глобальные узлы
[ редактировать ]Некоторые развертывания произвольной рассылки в Интернете различают локальные и глобальные узлы, чтобы принести пользу местному сообществу, отдавая предпочтение локальным узлам. Примером является система доменных имен. Локальные узлы часто объявляются в сообществе BGP без экспорта , чтобы хосты не объявляли о них своим одноранговым узлам, т. е. объявление хранится в локальной области. Когда развернуты как локальные, так и глобальные узлы, объявления от глобальных узлов часто добавляются в начало AS (т. е. AS добавляется еще несколько раз), чтобы сделать путь длиннее, чтобы объявление локального узла было предпочтительнее объявления глобального узла. [21]
См. также
[ редактировать ]
- Многосетевая адресация
- Поиск линии для эквивалентной системы для телефонов.
Ссылки
[ редактировать ]- ^ Госцень, Ружа; Валковяк, Кшиштоф; Клинковский, Мирослав (14 марта 2015 г.). «Алгоритм поиска табу для маршрутизации, модуляции и распределения спектра в эластичной оптической сети с произвольным и одноадресным трафиком» . Компьютерные сети . 79 : 148–165. дои : 10.1016/j.comnet.2014.12.004 . ISSN 1389-1286 .
- ^ Jump up to: а б с д Вудкок, Билл (июнь 1996 г.). «Лучшие практики произвольной маршрутизации» (PDF) . Информационная палата пакетов.
- ^ Jump up to: а б с д Эрнандес, Гаэль (10 октября 2017 г.). «Создание и эксплуатация глобальной сети Anycast» (PDF) . Группа сетевых операторов Евразии.
- ^ К. Партридж ; Т. Мендес; В. Милликен (ноябрь 1993 г.). Хостинг службы Anycasting . Сетевая рабочая группа. дои : 10.17487/RFC1546 . РФК 1546 . Информационный.
- ^ Вудкок, Билл (14 ноября 2019 г.). «TCP и Anycast» . Архив списка рассылки NANOG . Группа сетевых операторов Северной Америки.
- ^ Jump up to: а б Левин, Мэтт; Лион, Барретт; Андервуд, Тодд (июнь 2006 г.). «TCP Anycast: не верьте FUD — опыт работы с TCP и Anycast» (PDF) . Группа сетевых операторов Северной Америки.
- ^ Херрин, Уильям. «Архитектура Anycast TCP» . Проверено 11 октября 2021 г.
- ^ Кац-Бассетт, Итан; Гао, Райан (июль 2019 г.). «Влияние потери TCP на производительность региональных приложений» (PDF) . Майкрософт.
Azure Frontdoor использует произвольное перенаправление, чтобы перенаправлять пользователей на ближайший край.
- ^ Р. Хинден; С. Диринг (февраль 2006 г.). Архитектура IP-адресации версии 6 . Сетевая рабочая группа. дои : 10.17487/RFC4291 . РФК 4291 . Проект стандарта. Устаревшие RFC 3513. Updated by RFC 5952 , 6052 , 7136 , 7346 , 7371 и 8064 .
- ^ Д. Джонсон; С. Диринг (март 1999 г.). Зарезервированные произвольные адреса подсети IPv6 . Сетевая рабочая группа. дои : 10.17487/RFC2526 . РФК 2526 . Предлагаемый стандарт.
- ^ Дж. Эбли; К. Линдквист (декабрь 2006 г.). Эксплуатация служб Anycast . Сетевая рабочая группа. дои : 10.17487/RFC4786 . BCP 126. RFC 4786 . Лучшая общая практика.
- ^ Т. Харди (апрель 2002 г.). Распространение авторитетных серверов имен через общие одноадресные адреса . Сетевая рабочая группа. дои : 10.17487/RFC3258 . РФК 3258 . Информационный.
- ^ Домашняя страница корневого DNS-сервера B , посещение 8 февраля 2015 г.
- ^ «Отчет о расположении корневых серверов имен» . Информационная палата пакетов . Проверено 21 февраля 2011 г.
- ^ «Ассоциация по технической эксплуатации корневого сервера» . root-servers.org . Проверено 16 февраля 2013 г.
- ^ К. Уитема (июнь 2001 г.). Префикс Anycast для релейных маршрутизаторов 6to4 . Сетевая рабочая группа. дои : 10.17487/RFC3068 . РФК 3068 . Информационный. Устарело РФК 7526 .
- ^ О. Троан (май 2015 г.). Б. Карпентер (ред.). Устаревший префикс Anycast для ретрансляционных маршрутизаторов 6to4 . Рабочая группа по интернет-инжинирингу . дои : 10.17487/RFC7526 . BCP 196. RFC 7526 . Лучшая современная практика. Устаревшие RFC 3068 и 6732 .
- ^ «Точка встречи Anycast» . Сиско Системс. 1 июня 2001 г.
- ^ «Информационный бюллетень ICANN об атаке на корневой сервер 6 февраля 2007 г.» (PDF) . Информационный бюллетень . Интернет-корпорация по присвоению имен и номеров (ICANN). 1 марта 2007 года . Проверено 21 февраля 2011 г.
- ^ Мец, К. (2002). «IP Anycast: связь «точка-(любая) точка» (требуется вход в систему)». IEEE Интернет-вычисления . 6 (2). IEEE : 94–98. дои : 10.1109/4236.991450 .
- ^ Оки, Эйдзи; Рохас-Сесса, Роберто; Татипамула, Малликарджун; Фогт, Кристиан (24 апреля 2012 г.). Расширенные интернет-протоколы, службы и приложения . Джон Уайли и сыновья. стр. 102 и 103. ISBN. 978-0-470-49903-0 . Архивировано из оригинала 5 января 2020 года.
Внешние ссылки
[ редактировать ]- Рекомендации по произвольной маршрутизации IPv4. Учебное пособие по настройке произвольной маршрутизации.