Из Википедии, бесплатной энциклопедии
Перейти к навигации Перейти к поиску
Визуализация маршрутизации Anycast.

Anycast - это методология сетевой адресации и маршрутизации, в которой один адрес назначения имеет несколько путей маршрутизации к двум или более конечным пунктам назначения. Маршрутизаторы выберут желаемый путь на основе количества переходов, расстояния, наименьшей стоимости, измерений задержки или на основе наименее загруженного маршрута. Сети Anycast широко используются для продуктов сети доставки контента (CDN), чтобы приблизить их контент к конечному пользователю.

Методы адресации [ править ]

Схемы маршрутизации
Одноадресный

Unicast.svg

Транслировать

Broadcast.svg

Многоадресная рассылка

Multicast.svg

Anycast

Anycast-BM.svg

Геокаст

Geocast.svg

Internet Protocol и другие сетевые решения системы распознают пять основных способов адресации:

  • При одноадресной адресации используется однозначная связь между отправителем и получателем: каждый адрес назначения однозначно идентифицирует отдельную конечную точку получателя.
  • Широковещательная передача использует универсальную ассоциацию; одна дейтаграмма от одного отправителя направляется ко всем, возможно, нескольким конечным точкам, связанным с широковещательным адресом. Сеть автоматически реплицирует дейтаграммы по мере необходимости, чтобы достичь всех получателей в рамках широковещательной рассылки, которая обычно представляет собой всю сетевую подсеть.
  • При многоадресной адресации используется ассоциация « один ко многим из многих» или « многие ко многим из многих» ; дейтаграммы направляются одновременно за одну передачу многим получателям. Он отличается от широковещательной передачи тем, что адрес назначения обозначает подмножество, а не обязательно все доступные узлы.
  • Адресация Anycast - это ассоциация « один-к-одному из многих», при которой дейтаграммы направляются любому отдельному члену группы потенциальных получателей, которые все идентифицированы одним и тем же адресом назначения. Алгоритм маршрутизации выбирает одного получателя из группы на основе наименее затратной метрики маршрутизации. На практике это означает, что пакеты направляются топологически ближайшему члену группы произвольного доступа. Anycasting в архитектуре Интернета был впервые описан в RFC  1546 [1]
  • Geocast относится к доставке информации группе пунктов назначения в сети, определенных их географическим местоположением. Это специализированная форма многоадресной адресации, используемая некоторыми протоколами маршрутизации для мобильных одноранговых сетей.

Интернет-протокол версии 4 [ править ]

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

Ошибка этого подхода заключается в том, что соединение с произвольным адресом может завершиться неудачно, потому что сеть может изменить маршрутизацию пакетов в середине соединения из-за перегрузки или изменений в сети, в результате чего пункт назначения изменится в середине соединения, хотя новый пункт назначения не знает о соединении и не поддерживает его состояние. Эти условия обычно называют « переключателем PoP ». С обычным одноадресным адресом изменение маршрутизации не будет проблемой, так как это просто приведет к другому маршруту к тому же конечному пункту назначения. Все пакеты в рамках соединения обычно не обязательно должны следовать по одному и тому же пути. Но когда адрес на самом деле является произвольным адресом, маскирующимся под одноадресный адрес (как в этом проекте), изменение маршрутизации может быть изменением пункта назначения.

Из-за возможности «переключателя PoP» в IPv4, anycast обычно используется с протоколами без установления соединения на основе UDP , как способ обеспечения высокой доступности и балансировки нагрузки для служб без отслеживания состояния. Например, одним из хорошо известных приложений Anycast IPv4 является система доменных имен (DNS). Это хорошо подходит для anycast, поскольку это служба на основе UDP, обеспечивающая доступ без установления соединения к данным доменного имени, которые реплицируются на нескольких географически разнесенных серверах без сохранения состояния, с жесткими требованиями к доступности и масштабируемости .

Поскольку Anycast более подвержен ошибкам с протоколами, ориентированными на соединение, такими как TCP, где пункт назначения поддерживает состояние , он реже используется с этими протоколами. Некоторые настраиваемые IP-стеки используют собственные методы для обеспечения восстановления протоколов с отслеживанием состояния, когда это необходимо, [2] смягчая проблемы, связанные с переключателями Anycast PoP. Эти методы обычно включают в себя некоторую форму виртуализации сетевых функций [3] в форме перезаписи пакетов, как было продемонстрировано AWS HyperPlane, [4] [5] и Google Maglev [6], и / или инкапсуляцию пакетов в соответствии с такими протоколами, как Generic. Инкапсуляция маршрутизации , IPOP.

Интернет-протокол версии 6 [ править ]

Anycast явно поддерживается в IPv6 . RFC 4291 , охватывающий архитектуру адресации IPv6, резервирует идентификатор интерфейса 0 в подсети IPv6 как произвольный адрес «маршрутизатора подсети». Кроме того, RFC 2526 резервирует блок из 128 идентификаторов интерфейсов в подсети как произвольные адреса.  

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

Используемый в IPv4 метод объявления нескольких маршрутов в BGP для множественно назначенных одноадресных адресов также по-прежнему работает в IPv6 и может использоваться для маршрутизации пакетов на ближайший из нескольких географически разнесенных хостов с тем же адресом. Этот подход, не зависящий от маршрутизаторов с поддержкой Anycast, имеет те же сценарии использования вместе с теми же проблемами и ограничениями, что и в IPv4.

Приложения [ править ]

С развитием Интернета сетевые службы все чаще требуют высокой доступности. В результате использование сервисов anycast ( RFC 4786 ) стало популярнее среди сетевых операторов. [7] 

Система доменных имен [ править ]

Все корневые серверы имен Интернета реализованы как кластеры хостов с произвольной адресацией. Все тринадцать корневых серверов A – M существуют в нескольких местах, из них одиннадцать - на разных континентах. (Корневые серверы B и H существуют в двух местах в США. [8] [9] [10] ) Серверы используют объявления с произвольным адресом для предоставления децентрализованной услуги. Это ускорило развертывание физических (а не логических) корневых серверов за пределами США . RFC 3258 документирует использование произвольной адресации для обеспечения авторитетного DNS. Сервисы. Многие коммерческие поставщики DNS перешли на среду Anycast IP, чтобы повысить производительность и избыточность запросов, а также реализовать балансировку нагрузки. [ необходима цитата ]

Переход IPv6 [ править ]

При переходе с IPv4 на IPv6 может быть развернута произвольная адресация для обеспечения совместимости IPv6 с хостами IPv4. В этом методе 6to4 используется шлюз по умолчанию с IP-адресом 192.88.99.1, как описано в RFC 3068 . Это позволяет нескольким поставщикам внедрять шлюзы 6to4, при этом хостам не нужно знать адреса шлюзов каждого отдельного поставщика. 

Сети доставки контента [ править ]

Сети доставки контента могут использовать anycast для фактических HTTP- соединений со своими центрами распространения или для DNS . Поскольку большинство HTTP-подключений к таким сетям запрашивают статический контент, такой как изображения и таблицы стилей , они обычно недолговечны и не сохраняют состояния в последующих сеансах TCP. Общая стабильность маршрутов и отсутствие состояния соединений делают anycast подходящим для этого приложения, даже если оно использует TCP . [ необходима цитата ]

Связь между Anycast и Multicast сетью [ править ]

Точка рандеву Anycast может использоваться в протоколе обнаружения источника многоадресной рассылки (MSDP) и его выгодном применении, поскольку Anycast RP - это внутридоменная функция, которая обеспечивает возможности резервирования и распределения нагрузки. Если используется несколько точек рандеву Anycast, IP-маршрутизация автоматически выберет топологически ближайшую точку встречи для каждого источника и приемника. Это обеспечит многоадресную сеть с требованиями отказоустойчивости. [11]

Безопасность [ править ]

Anycast позволяет любому оператору, маршрутная информация которого принимается промежуточным маршрутизатором, перехватывать любые пакеты, предназначенные для произвольного адреса. Хотя это на первый взгляд кажется небезопасным, он ничем не отличается от маршрутизации обычных IP-пакетов и не является более или менее безопасным. Как и в случае с обычной IP-маршрутизацией, тщательная фильтрация того, кому разрешено и не разрешено распространять объявления о маршруте, имеет решающее значение для предотвращения атак типа «злоумышленник в середине» или « черной дыры» . Первое также можно предотвратить с помощью шифрования и аутентификации сообщений, например, с помощью Transport Layer Security , в то время как второе может быть нарушено луковой маршрутизацией .

Надежность [ править ]

Anycast обычно очень надежен, так как может обеспечить автоматическое переключение при отказе . Приложения Anycast обычно имеют внешний "контрольный" мониторинг функции сервера и отменяют объявление маршрута, если сервер выходит из строя. В некоторых случаях это делается фактическими серверами, которые объявляют маршрутизатору префикс anycast через OSPF или другой IGP . Если серверы умирают, маршрутизатор автоматически снимает объявление.

Функциональность «Heartbeat» важна, потому что, если объявление для отказавшего сервера продолжается, сервер будет действовать как «черная дыра» для ближайших клиентов; этот режим отказа является наиболее серьезным режимом отказа для системы Anycast. Даже в этом случае такой сбой приведет только к полному отказу клиентов, которые находятся ближе к этому серверу, чем к любому другому, и не вызовет глобального отказа.

Смягчение атак типа «отказ в обслуживании» [ править ]

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

Методологии Anycast в Интернете могут использоваться для распространения DDoS- атак и снижения их эффективности: поскольку трафик направляется на ближайший узел, процесс, над которым злоумышленник не может контролировать, поток трафика DDoS будет распределяться между ближайшими узлами. Таким образом, не все узлы могут быть затронуты. Это может быть причиной для развертывания произвольной адресации. [12]

Однако эффективность этого метода для отражения атак сомнительна, поскольку одноадресные адреса (используемые для обслуживания) могут быть легко получены, по крайней мере, на IPv6 . В устаревшем RFC 2373 определено, что «произвольный адрес не должен использоваться в качестве адреса источника пакета IPv6». Следовательно, проверка связи с произвольным адресом вернет одноадресный адрес ближайшего узла, поскольку ответ должен поступать с одноадресного адреса. Затем злоумышленник может атаковать отдельные узлы из любого места, минуя любые методы адресации. Этот же метод работает с некоторыми, но не со всеми произвольными адресами IPv4. [13] RFC 2373   также ограничивал произвольные IPv6-адреса только маршрутизаторами. Однако оба эти ограничения были сняты в RFC 4291 . 

Аутентификация любых передач может решить эту проблему. [14]

Локальные и глобальные узлы [ править ]

Некоторые развертывания Anycast в Интернете различают локальные и глобальные узлы в интересах местного сообщества, обращаясь преимущественно к локальным узлам. Примером может служить система доменных имен. Локальные узлы часто объявляются сообществом неэкспортируемого BGP, чтобы узлы не сообщали о них своим партнерам, т. Е. Объявление хранится в локальной области. Если развернуты как локальные, так и глобальные узлы, объявления от глобальных узлов часто добавляются в начале AS (т. Е. AS добавляется еще несколько раз), чтобы сделать путь длиннее, так что объявление локального узла предпочтительнее объявления глобального узла. [15]

См. Также [ править ]

  • Множественная адресация
  • Поиск линии для эквивалентной системы для телефонов

Ссылки [ править ]

  1. ^ Куропатка, C .; Mendez, T .; Милликен, В. (ноябрь 1993 г.). «Хостинг Anycasting Service» (PDF) . RFC 1546 . IETF Trust . Проверено 14 августа 2019 .
  2. ^ Принц, Мэтью. «Комментарий генерального директора в блоге CloudFlare» . Блог CloudFlare . Проверено 12 августа 2014 .
  3. ^ Примеры использования виртуализации сетевых функций (NFV), ETSI GS NFV 001 v1.1.1 (2013-10)
  4. ^ MacCarthaigh, Colm. «Гиперплан» . YouTube . Проверено 27 февраля 2019 .
  5. ^ MacCarthaigh, Colm. «Балансировка нагрузки при гипермасштабировании» . AtScaleConference . Проверено 27 февраля 2019 .
  6. ^ Эйзенбад, Даниэль. «Быстрый и надежный программный балансировщик сетевой нагрузки» . Google . Проверено 27 февраля 2019 .
  7. ^ Abley, J .; Линдквист, К. (декабрь 2006 г.). «Работа с Anycast Services» (PDF) . RFC 4786 . IETF Trust . Проверено 21 февраля 2011 года .
  8. ^ Домашняя страница DNS-сервера B-root , посещено 8 февраля 2015 г.
  9. ^ «Отчет о расположении корневого сервера имен» . Центр обмена пакетами . Проверено 21 февраля 2011 года .
  10. ^ "Assn технических операций корневого сервера" . root-servers.org . Проверено 16 февраля 2013 .
  11. ^ https://www.cisco.com/c/en/us/td/docs/ios/solutions_docs/ip_multicast/White_papers/anycast.html
  12. ^ «Информационный бюллетень ICANN об атаке на корневой сервер 6 февраля 2007 г.» (PDF) . Информационный бюллетень . Интернет-корпорация по присвоению имен и номеров (ICANN). 1 марта 2007 . Проверено 21 февраля 2011 года .
  13. Перейти ↑ Metz, C. (2002). «IP Anycast: соединение точка-точка (любая) (требуется вход в систему)». IEEE Internet Computing . IEEE . 6 (2): 94–98. DOI : 10.1109 / 4236.991450 .
  14. ↑ Аль-Ибрагим, Мохамед; Черны, Антон (2003). Городецкий, В .; и другие. (ред.). «Аутентификация Anycast-коммуникации». Конспект лекций по информатике . Компьютерное сетевое общество. 2776 : 419–423. DOI : 10.1007 / 978-3-540-45215-7_36 . ISBN 978-3-540-40797-3.
  15. ↑ Оки, Эйдзи; Рохас-Сесса, Роберто; Татипамула, Малликарджун; Фогт, Кристиан (24 апреля 2012 г.). Расширенные интернет-протоколы, службы и приложения . Джон Вили и сыновья. стр. 102 и 103. ISBN 978-0-470-49903-0. Архивировано 5 января 2020 года.

Внешние ссылки [ править ]

  • Передовой опыт в руководстве по произвольной маршрутизации IPv4 по настройке произвольной маршрутизации.