Anycast - Anycast

Vizualizace směrování anycast.

Anycast je metodika síťového adresování a směrování, ve které je jedna cílová IP adresa sdílena zařízeními (obecně servery) na více místech. Směrovače směrují pakety adresované tomuto cíli na místo nejblíže odesílateli pomocí jejich běžných rozhodovacích algoritmů, obvykle nejnižšího počtu skoků BGP sítě . Směrování Anycast je široce využíváno sítěmi pro doručování obsahu, jako jsou weboví a DNS hostitelé, aby se jejich obsah přiblížil koncovým uživatelům.

Způsoby adresování

Směrovací schémata
Unicast

Unicast.svg

Přenos

Broadcast.svg

Vícesměrové vysílání

Multicast.svg

Anycast

Anycast-BM.svg

V internetovém protokolu existují čtyři hlavní způsoby adresování :

  • Unicast doručuje zprávu do jednoho konkrétního uzlu pomocí asociace one-to-one mezi odesílatelem a cílem: každá cílová adresa jednoznačně identifikuje koncový bod jednoho příjemce.
  • Broadcast doručuje zprávu všem uzlům v síti pomocí asociace jeden na všechny ; jeden datagram od jednoho odesílatele je směrován do všech možných více koncových bodů spojených s adresou vysílání. Síť automaticky replikuje datagramy podle potřeby, aby dosáhla na všechny příjemce v rozsahu vysílání, což je obecně celá podsíť sítě.
  • Multicast doručuje zprávu skupině uzlů, které vyjádřily zájem o přijetí zprávy pomocí asociace one-to-many-of-many nebo many-to-many-of-many ; datagramy jsou směrovány současně v jednom přenosu mnoha příjemcům. Vícesměrové vysílání se liší od vysílání v tom, že cílová adresa označuje podmnožinu, ne nutně všechny, přístupných uzlů.
  • Anycast doručí zprávu komukoli ze skupiny uzlů, obvykle tomu, který je nejblíže ke zdroji, pomocí asociace one-to-one-of-many, kde jsou datagramy směrovány na libovolného člena skupiny potenciálních přijímačů, které jsou všechny identifikované stejnou cílovou adresou. Směrovací algoritmus vybírá jeden přijímač ze skupiny na základě toho, který je nejbližší podle nějaké vzdálenosti.

Dějiny

První zdokumentované použití směrování anycast pro topologické vyvažování zátěže služeb připojených k internetu bylo v roce 1989, tato technika byla poprvé formálně zdokumentována v IETF o čtyři roky později v RFC  1546 a poprvé byla použita na kritickou infrastrukturu v roce 2001 s funkcí anycasting jmenného serveru I-root .

Počáteční námitky

Počáteční námitky proti nasazení směrování anycast se soustředily na vnímaný konflikt mezi dlouhotrvajícími připojeními TCP a volatilitou směrované topologie internetu. Koncepčně lze dlouhotrvající připojení, například přenos souborů FTP (jehož dokončení v polovině 90. let, kdy se o tomto problému debatovalo, trvalo hodiny) přesměrovat na jinou instanci anycast v polovině připojení kvůli změnám v topologii sítě nebo směrování, což má za následek, že server změní střední připojení a nový server si není vědom připojení a nemá stav připojení TCP předchozí instance anycast.

V praxi nebyly takové problémy pozorovány a tyto námitky byly na počátku dvacátých let rozptýleny. Mnoho počátečních nasazení anycast sestávalo ze serverů DNS, využívajících zásadně přenos UDP. Měření dlouhodobých toků anycast odhalilo velmi málo poruch způsobených přepínači instance středního připojení, mnohem méně (méně než 0,017% nebo „méně než jeden tok za deset tisíc za hodinu trvání“ podle různých zdrojů), než bylo připisováno jiným příčiny selhání. Byla vyvinuta řada mechanismů pro efektivní sdílení stavu mezi instancemi anycast. A některé protokoly založené na TCP, zejména HTTP, obsahovaly mechanismy „přesměrování“, přičemž k vyhledání nejbližší instance služby bylo možné použít adresy služby anycast, přičemž uživatel by byl přesměrován na konkrétní instanci před zahájením jakékoli dlouhodobé žila stavová transakce.

Internetový protokol verze 4

Anycast lze implementovat prostřednictvím protokolu Border Gateway Protocol (BGP). Vícenásobným hostitelům (obvykle v různých geografických oblastech) je přidělena stejná unicastová IP adresa a prostřednictvím BGP jsou oznámeny různé cesty k této adrese. Směrovače je považují za alternativní trasy ke stejnému cíli, přestože se ve skutečnosti jedná o trasy do různých destinací se stejnou adresou. Směrovače jako obvykle vybírají trasu podle jakékoli používané metriky vzdálenosti (nejnižší náklady, nejméně přetížené, nejkratší). Výběr trasy v tomto nastavení znamená výběr cíle.

Internetový protokol verze 6

Anycast je v IPv6 výslovně podporován . RFC  4291 , který pokrývá architekturu adresování IPv6, rezervuje identifikátor rozhraní 0 v podsíti IPv6 jako libovolnou adresu „Router podsítě“. Kromě toho RFC  2526 rezervuje blok 128 identifikátorů rozhraní v podsíti jako anycast adresy.

Většina směrovačů IPv6 na cestě paketu anycast přes síť jej nerozezná od paketu unicast, ale vyžaduje speciální zacházení se směrovači poblíž cíle (tj. V rozsahu adresy anycast), protože směrovat paket anycast na „nejbližší“ rozhraní v rámci tohoto rozsahu, které má správnou adresu anycast, podle jakéhokoli měřítka vzdálenosti ( skoky , náklady atd.), které se používá.

Metoda používaná v IPv4 inzerce více cest v BGP k násobení přiřazených unicastových adres také stále funguje v IPv6 a může být použita pro směrování paketů k nejbližšímu z několika geograficky rozptýlených hostitelů se stejnou adresou. Tento přístup, který nezávisí na směrovačích s vědomímcastů, má stejné případy použití spolu se stejnými problémy a omezeními jako v IPv4.

Aplikace

S růstem internetu mají síťové služby stále více požadavků na vysokou dostupnost. V důsledku toho si provozování všech služeb streamování ( RFC  4786 ) získává na oblibě mezi provozovateli sítí.

Domain Name System

Všechny internetové kořenové jmenné servery jsou implementovány jako klastry hostitelů pomocí adresování anycast. Všech 13 kořenových serverů A – M existuje na více místech, z toho 11 na více kontinentech. (Kořenové servery B a H existují na dvou místech v USA.) Servery používají k poskytování decentralizované služby oznámení o jakékoli adrese. To urychlilo nasazení fyzických (spíše než logických) kořenových serverů mimo Spojené státy . RFC  3258 dokumentuje použití adresování anycast k poskytování autoritativních služeb DNS . Mnoho komerčních poskytovatelů DNS přešlo na prostředí IP anycast, aby zvýšilo výkon dotazů a redundanci a implementovalo vyvažování zátěže.

Přechod IPv6

Při převodu z IPv4 na IPv6 lze nasadit libovolné adresování, aby byla zajištěna kompatibilita IPv6 s hostiteli IPv4. Tato metoda, 6to4 , používá výchozí bránu s IP adresou 192.88.99.1, jak je popsáno v RFC  3068 . To umožňuje více poskytovatelům implementovat brány 6to4, aniž by hostitelé museli znát adresy brány jednotlivých poskytovatelů. Tato metoda byla v RFC  7526 zastaralá .

Sítě pro doručování obsahu

Sítě pro doručování obsahu mohou používat anycast pro skutečná připojení HTTP k jejich distribučním centrům nebo pro DNS . Protože většina připojení HTTP k takovým sítím vyžaduje statický obsah, jako jsou obrázky a šablony stylů , v následujících relacích TCP mají obvykle krátkou životnost a bezstavové. Obecná stabilita tras a bezstavovost připojení činí anycast vhodný pro tuto aplikaci, přestože používá TCP .

Konektivita mezi sítí Anycast a Multicast

Bod setkání Anycast lze použít v protokolu Multicast Source Discovery Protocol (MSDP) a jeho výhodná aplikace jako Anycast RP je funkce v rámci domény, která poskytuje možnosti redundance a sdílení zátěže. Pokud je použito více bodů setkání anycast, IP směrování automaticky vybere topologicky nejbližší bod setkání pro každý zdroj a přijímač. Poskytlo by to vícesměrové síti požadavky na odolnost proti chybám.

Bezpečnostní

Anycast umožňuje jakémukoli operátorovi, jehož směrovací informace jsou přijaty mezilehlým routerem, aby unesl jakékoli pakety určené pro adresu anycast. I když to na první pohled vypadá nejistě, nijak se to neliší od směrování běžných IP paketů a už vůbec ne bezpečně. Stejně jako u konvenčního směrování IP je klíčové, aby se zabránilo útokům typu man-in-the-middle nebo blackhole , pečlivé filtrování toho, kdo smí a nesmí šířit oznámení o trase . Prvnímu z nich lze také zabránit šifrováním a ověřováním zpráv, například pomocí zabezpečení Transport Layer Security , zatímco druhému může vadit směrování cibule .

Spolehlivost

Anycast je obvykle vysoce spolehlivý, protože může poskytovat automatické převzetí služeb při selhání bez přidání složitosti nebo nových potenciálních bodů selhání. Aplikace Anycast obvykle disponují externím monitorováním funkce serveru „prezenčním signálem“ a v případě selhání serveru odvolávají oznámení o trase. V některých případech to dělají skutečné servery, které oznámí předponu anycast routeru přes OSPF nebo jiný IGP . Pokud servery zemřou, router automaticky stáhne oznámení. Funkce „prezenčního signálu“ je důležitá, protože pokud bude oznámení pokračovat u nefunkčního serveru, bude server fungovat jako „černá díra“ pro blízké klienty; toto je nejvážnější způsob selhání systému Anycast. I v tomto případě způsobí tento druh selhání pouze úplné selhání pro klienty, kteří jsou k tomuto serveru blíže než kterýkoli jiný, a nezpůsobí globální selhání. Avšak i automatizace nezbytná k implementaci výběru směrování „prezenčního signálu“ může sama o sobě přidat potenciální bod selhání, jak je vidět na výpadku Facebooku v roce 2021 .

Zmírnění útoků typu odmítnutí služby

Při útocích na odepření služby se může nepoctivý síťový hostitel inzerovat jako server anycast pro životně důležitou síťovou službu, poskytovat nepravdivé informace nebo jednoduše blokovat službu. Metodiky Anycast na internetu lze využít k distribuci útoků DDoS a snížení jejich účinnosti: Jak je provoz směrován do nejbližšího uzlu, což je proces, nad nímž útočník nemá žádnou kontrolu, tok toku DDoS bude distribuován mezi nejbližší uzly. Proto nemusí být ovlivněny všechny uzly. To může být důvod k nasazení adresování anycast.

Účinnost této techniky závisí na zachování utajení všech unicastových adres spojených s uzly služby anycast, protože útočník, který vlastní unicastové adresy jednotlivých uzlů, na ně může zaútočit z jakéhokoli místa a obejít metody adresování anycast.

Místní a globální uzly

Některá nasazení anycast na internetu rozlišují mezi místními a globálními uzly, aby byla přínosem pro místní komunitu, a to přednostním adresováním místních uzlů. Příkladem je systém doménových jmen. Místní uzly jsou často ohlašovány komunitou BGP bez exportu, aby se zabránilo tomu, že je hostitelé oznámí svým vrstevníkům, tj. Oznámení je uloženo v místní oblasti. Tam, kde jsou nasazeny lokální i globální uzly, jsou oznámení z globálních uzlů často předřazena AS (tj. AS je přidán několikrát), aby byla cesta delší, takže je upřednostňováno oznámení lokálního uzlu před oznámením globálního uzlu.

Viz také

Reference

externí odkazy