{"id":88961,"date":"2020-07-16T19:42:34","date_gmt":"2020-07-16T17:42:34","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/anycast-protiv-unicast-chto-luchshe-vybirat-v-kazhdom-sluchae"},"modified":"2020-07-16T19:42:34","modified_gmt":"2020-07-16T17:42:34","slug":"anycast-protiv-unicast-chto-luchshe-vybirat-v-kazhdom-sluchae","status":"publish","type":"post","link":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/anycast-protiv-unicast-chto-luchshe-vybirat-v-kazhdom-sluchae","title":{"rendered":"Anycast vs Unicast: hvad skal man v\u00e6lge i hver enkelt situation","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>Mange har helt sikkert h\u00f8rt om Anycast. Denne metode til adresse- og routingnetv\u00e6rk tildeler \u00e9t IP-adresse til flere servere i netv\u00e6rket. Disse servere kan v\u00e6re beliggende i forskellige datacentre. Ideen med Anycast er, at data sendes til den n\u00e6rmeste server, afh\u00e6ngigt af placeringen af anmodningskilden (i henhold til netv\u00e6rkstopologi, mere pr\u00e6cist - BGP-routingprotokollen). P\u00e5 den m\u00e5de kan man reducere antallet af netv\u00e6rks-hop og latens. <\/p>\n<p>Essensen er, at den samme rute annonceres fra flere datacentre over hele verden. P\u00e5 den m\u00e5de vil kunder blive sendt til det 'bedste' og 'n\u00e6rmeste' datacenter baseret p\u00e5 BGP-ruterne. Hvorfor v\u00e6lge Anycast? Hvad er fordelene ved at bruge Anycast frem for Unicast?<\/p>\n<p><noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/ruvds\/blog\/511050\/\"><img decoding=\"async\" alt=\"Anycast vs Unicast: hvad skal man v\u00e6lge i hver enkelt situation\" src=\"\/wp-content\/uploads\/2020\/07\/6573f1e2d39d783575348734518c4bae.png\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><br \/>\nUnicast er helt sikkert velegnet til en hjemmeside med \u00e9n webserver og moderat trafik. Men hvis en tjeneste har millioner af abonnenter, anvender den normalt flere webservere, som hver har den samme IP-adresse. Disse servere er geografisk fordelt for at optimere betjeningen af anmodninger.<\/p>\n<p>I et s\u00e5dant scenarie vil Anycast forbedre ydeevnen (trafikken dirigeres til brugeren med den minimale latens), sikre servicep\u00e5lidelighed (takket v\u00e6re backupservere) og balancere belastningen - routing til flere servere vil effektivt fordele belastningen imellem dem og forbedre hastigheden p\u00e5 hjemmesiden.<\/p>\n<p>Operat\u00f8rer tilbyder kunder forskellige former for load balancing baseret p\u00e5 Anycast og DNS. Kunderne kan angive IP-adresser, hvor anmodningerne skal sendes afh\u00e6ngigt af det geografiske sted for hjemmesiden. Dette giver mulighed for en mere fleksibel distribution af brugerforesp\u00f8rgsler.<\/p>\n<p>Lad os antage, at der er flere platforme, mellem hvilke belastningen (brugerne) skal fordeles, for eksempel en online butik med 100.000 anmodninger om dagen eller en popul\u00e6r blog. For at begr\u00e6nse regionen, hvorfra brugerne tilg\u00e5r en bestemt platform, kan man benytte Geo Community-optionen. Den giver mulighed for at begr\u00e6nse den region, inden for hvilken operat\u00f8ren vil annoncere ruten.<\/p>\n<p><img decoding=\"async\" alt=\"Anycast vs Unicast: hvad skal man v\u00e6lge i hver enkelt situation\" src=\"\/wp-content\/uploads\/2020\/07\/54582f256a946a3ff557ab971cec087d.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><img decoding=\"async\" alt=\"Anycast vs Unicast: hvad skal man v\u00e6lge i hver enkelt situation\" src=\"\/wp-content\/uploads\/2020\/07\/48849a5cf65cb1c7190c1f75aa33e2d8.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Anycast og Unicast: forskelle<\/i><\/p>\n<p>Anycast bruges ofte i applikationer som DNS (dom\u00e6nenavnesystem) og CDN (content delivery networks), hvilket muligg\u00f8r rutevalg, der forbedrer netv\u00e6rkets ydeevne. Content delivery networks anvender Anycast, fordi de h\u00e5ndterer store m\u00e6ngder trafik, og Anycast giver i s\u00e5danne tilf\u00e6lde flere fordele (som beskrevet nedenfor). I DNS g\u00f8r Anycast det muligt at \u00f8ge p\u00e5lideligheden og fejlfindingskapaciteten af tjenesten markant.<\/p>\n<p><img decoding=\"async\" alt=\"Anycast vs Unicast: hvad skal man v\u00e6lge i hver enkelt situation\" src=\"\/wp-content\/uploads\/2020\/07\/8043fec22ecef8aa2b3b9c1a06e8f5f9.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>I Anycast IP, n\u00e5r BGP anvendes, er der flere ruter til en bestemt v\u00e6rt. Faktisk er dette kopier af v\u00e6rter i flere datacentre, der anvendes til at etablere forbindelser med lavere forsinkelse.<\/i><\/p>\n<p>S\u00e5ledes annonceres den samme IP-adresse i et Anycast-netv\u00e6rk fra forskellige steder, og netv\u00e6rket beslutter, hvorhen brugerens anmodning skal sendes baseret p\u00e5 ruten's \"omkostninger\". For eksempel anvendes BGP-protokollen ofte til at bestemme den korteste rute for datatransmission. N\u00e5r en bruger sender en Anycast-anmodning, bestemmer BGP den bedste rute til de tilg\u00e6ngelige servere i Anycast-netv\u00e6rket.<\/p>\n<h2>Fordele ved Anycast<\/h2>\n<p>Reducering af forsinkelse<br \/>\nSystemer med Anycast kan reducere forsinkelsen ved behandling af brugerens anmodninger, da de muligg\u00f8r datadeling fra den n\u00e6rmeste server. Det vil sige, at brugerne altid vil oprette forbindelse til den \"n\u00e6rmeste\" (set fra routingsprotokollens synspunkt) DNS-server. Som et resultat reducerer Anycast interaktionstiden ved at mindske netv\u00e6rksafstanden mellem klienten og serveren. Dette reducerer ikke kun forsinkelsen, men sikrer ogs\u00e5 load balancing.<\/p>\n<p>Hastighed<\/p>\n<p>Da trafikken sendes til den n\u00e6rmeste node og forsinkelsen ved dataoverf\u00f8rsel mellem klienten og noden reduceres, vil resultatet v\u00e6re optimering af leveringshastigheden, uanset hvor klienten anmoder om information.<\/p>\n<p>\u00d8get stabilitet og fejlfindingskapacitet<\/p>\n<p>Hvis flere servere verden over bruger den samme IP, vil trafik i tilf\u00e6lde af en fejl p\u00e5 en server eller dens deaktivering blive omdirigeret til den n\u00e6rmeste server. Dette g\u00f8r Anycast-tjenesten mere robust og sikrer bedre netv\u00e6rksadgang\/forsinkelse\/hastighed.\u00a0<\/p>\n<p>Dermed \u00f8ger Anycast stabiliteten af DNS ved at have flere servere, der altid er tilg\u00e6ngelige for brugerne. Hvis en node fejler, vil brugerforesp\u00f8rgsler blive omdirigeret til en anden DNS-server uden nogen manuel indgriben eller omkonfiguration. Anycast sikrer en n\u00e6sten usynlig omstilling til andre sider ved blot at fjernede ruter til den problematiske side.\u00a0<\/p>\n<p>Lastbalancering<\/p>\n<p>I Anycast-systemet fordeles netv\u00e6rkstrafik over forskellige servere. Det vil sige, at det fungerer som en lastbalancer, hvilket forhindrer, at en enkelt server f\u00e5r hovedparten af trafikken. Lastbalancering kan bruges, for eksempel n\u00e5r der er flere netv\u00e6rksnoder placeret p\u00e5 samme geografiske afstand fra kilden til foresp\u00f8rgsler.<\/p>\n<p>Reduceret p\u00e5virkning af DoS-angreb\u00a0<\/p>\n<p>En anden egenskab ved Anycast er modstandsdygtighed overfor DDoS. DDoS-angreb vil sandsynligvis ikke kunne lamme Anycast-systemet, da det ville kr\u00e6ve at kv\u00e6le alle servere i et s\u00e5dan netv\u00e6rk med en b\u00f8lge af anmodninger.\u00a0<\/p>\n<p>I DDoS-angreb bruges der ofte botnets, der kan generere s\u00e5 meget trafik, at det overbelaster den angrebne server. Fordelen ved at bruge Anycast i denne situation er, at hver server kan \"absorbere\" en del af angrebet, hvilket mindsker belastningen p\u00e5 den specifikke server. Et \"denial of service\"-angreb vil sandsynligvis blive lokaliseret til serveren og ikke p\u00e5virke hele tjenesten.<\/p>\n<p>H\u00f8j horisontal skalerbarhed<\/p>\n<p>Anycast-systemer er velegnede til tjenester med h\u00f8j trafik. Hvis en tjeneste, der anvender Anycast, har brug for nye servere til at h\u00e5ndtere den voksende trafik, kan nye servere tilf\u00f8jes til netv\u00e6rket for at h\u00e5ndtere dette. De kan placeres p\u00e5 nye eller allerede eksisterende lokationer.\u00a0<\/p>\n<p>Hvis der observeres en betydelig stigning i trafikken et givent sted, vil tilf\u00f8jelsen af en server hj\u00e6lpe med at fordele belastningen for det p\u00e5g\u00e6ldende sted. At tilf\u00f8je en server p\u00e5 en ny lokation vil forkorte ventetiden ved at skabe den korteste rute for nogle brugere. Begge metoder \u00f8ger ogs\u00e5 service stabiliteten, da nye servere bliver tilg\u00e6ngelige i netv\u00e6rket. Hvis en server er overbelastet, kan man ganske enkelt deployere en anden p\u00e5 det sted, der g\u00f8r det muligt for den at modtage en del af anmodningerne fra den overbelastede server. Dette kr\u00e6ver ikke nogen konfiguration fra kundernes side.\u00a0<\/p>\n<p>Kun p\u00e5 denne m\u00e5de kan man h\u00e5ndtere terabits trafik og et meget stort antal brugere, n\u00e5r serveren kun har f\u00e5 porte p\u00e5 10 eller 25 Gbit\/s. 100 v\u00e6rter med \u00e9n IP-adresse muligg\u00f8r behandling af terabit trafikm\u00e6ngder.<\/p>\n<p>Nem konfiguration af administrationen<\/p>\n<p>Som allerede n\u00e6vnt, er en interessant anvendelse af Anycast \u2014 DNS. Man kan placere flere forskellige DNS-servere i netv\u00e6rksnoderne, men bruge \u00e9n DNS-adresse. Afh\u00e6ngigt af hvor kilden befinder sig, bliver anmodninger sendt til den n\u00e6rmeste node. Dette sikrer en form for trafikbalancering og redundans i tilf\u00e6lde af en DNS-serverfejl. P\u00e5 denne m\u00e5de kan man i stedet for at konfigurere forskellige DNS-servere afh\u00e6ngigt af deres placering, anvende konfigurationen af \u00e9n DNS-server p\u00e5 alle noder.<\/p>\n<p>Anycast-netv\u00e6rk kan konfigureres til at rute anmodninger ikke kun baseret p\u00e5 afstand, men ogs\u00e5 p\u00e5 faktorer som serverens tilg\u00e6ngelighed, antal etablerede forbindelser eller svartid.<\/p>\n<p>Der kr\u00e6ves ingen specielle servere, netv\u00e6rk eller komponenter fra klientens side for at bruge Anycast-teknologien. Men Anycast har ogs\u00e5 ulemper. Implementeringen betragtes som en kompleks opgave, der kr\u00e6ver ekstra udstyr, p\u00e5lidelige udbydere og korrekt trafik-rutning.<\/p>\n<h2>Fra den rene kilde til den vidunderlige fjernhed<\/h2>\n<p>\nSelvom Anycast dirigerer brugere baseret p\u00e5 det mindste antal hop, betyder det ikke n\u00f8dvendigvis minimal forsinkelse. Forsinkelse er en mere kompleks m\u00e5ling, da den ved \u00e9t hop kan v\u00e6re h\u00f8jere end ved ti. <\/p>\n<p><img decoding=\"async\" alt=\"Anycast vs Unicast: hvad skal man v\u00e6lge i hver enkelt situation\" src=\"\/wp-content\/uploads\/2020\/07\/8fb50007806759ab243c89bb88cdeb31.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Eksempel: interkontinentale kommunikationer kan inkludere en enkelt overgang med meget h\u00f8j forsinkelse.<\/i><\/p>\n<p>Anycast anvendes prim\u00e6rt til UDP-baserede tjenester som DNS. Brugerforesp\u00f8rgsler sendes til det \"bedste\" og \"n\u00e6rmeste\" datacenter baseret p\u00e5 BGP-ruter. <\/p>\n<p><img decoding=\"async\" alt=\"Anycast vs Unicast: hvad skal man v\u00e6lge i hver enkelt situation\" src=\"\/wp-content\/uploads\/2020\/07\/05a1b75b981d55967e44e3b90cfd88b9.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Eksempel: en DNS-klientarbejdsstation med Anycast DNS-IP-adressen 123.10.10.10 foretager DNS-opslag for den n\u00e6rmeste af tre DNS-navneservere, der er implementeret med samme Anycast-IP-adresse. Hvis router R1 eller server A fejler, vil DNS-klientens pakker automatisk blive omdirigeret til den n\u00e6ste n\u00e6rmeste DNS-server via routerne R2 og R3. Desuden vil ruten til vores server A blive fjernet fra rutingtabellerne, hvilket forhindrer yderligere brug af denne navneserver.<\/i><\/p>\n<h2>Implementeringsscenarier<\/h2>\n<p>\nDer er to almindelige skemaer, der bruges til at bestemme, hvilken server brugeren opretter forbindelse til:<\/p>\n<ul>\n<li><b>Netv\u00e6rksniveau Anycast<\/b>. Forbinder brugeren med den n\u00e6rmeste server. Her er den netv\u00e6rksvej, som brugeren tager til serveren, vigtig.<\/li>\n<li><b>Applikationsniveau Anycast<\/b>. I dette skema er der flere beregnede metrikker, herunder serverens tilg\u00e6ngelighed, responstid, antal forbindelser osv. Dette afh\u00e6nger af en ekstern overv\u00e5ger, der giver netv\u00e6rksstatistik.<\/li>\n<\/ul>\n<p><\/p>\n<h2>Anycast-baseret CDN<\/h2>\n<p>\nLad os nu vende tilbage til brugen af Anycast i indholdsleveringsnetv\u00e6rk. Anycast er bestemt et interessant netv\u00e6rkskoncept og f\u00e5r stigende anerkendelse blandt n\u00e6ste generations CDN-udbydere.<\/p>\n<p>CDN er et distribueret netv\u00e6rk af servere, der leverer indhold til slutbrugere med h\u00f8j tilg\u00e6ngelighed og lav latens. Indholdsleveringsnetv\u00e6rk spiller i dag en vigtig rolle, idet de danner grundlaget for mange multimedielle onlinetjenester, og forbrugerne er i stigende grad mindre tolerante over for langsomme indl\u00e6sningstider. Video- og taleapplikationer er s\u00e6rligt f\u00f8lsomme over for jitter og forsinkelse i netv\u00e6rket. <\/p>\n<p>CDN samler alle servere i \u00e9t netv\u00e6rk og sikrer hurtigere indl\u00e6sning af indhold. Nogle gange kan det forkorte ventetiden for brugeren med 5-6 sekunder. Form\u00e5let med CDN er at optimere leveringen ved at s\u00f8rge for indhold fra den server, der er t\u00e6ttest p\u00e5 slutbrugeren. Det ligner meget Anycast, hvor den n\u00e6rmeste server v\u00e6lges baseret p\u00e5 slutbrugerens placering. Det ville synes, at enhver CDN-udbyder automatisk ville bruge Anycast, men i virkeligheden er det ikke tilf\u00e6ldet.<\/p>\n<p>Applikationer, der bruger protokoller som HTTP\/TCP, er afh\u00e6ngige af en etableret forbindelse. Hvis der v\u00e6lges en ny Anycast-node (f.eks. ved serverfejl), kan servicen blive afbrudt. Derfor blev Anycast tidligere anbefalet til forbindelsesl\u00f8se tjenester som UDP og DNS. Ikke desto mindre fungerer Anycast ogs\u00e5 godt for forbindelsesorienterede protokoller, s\u00e5som TCP, der fungerer fremragende i Anycast-tilstand.<\/p>\n<p>Nogle CDN-udbydere anvender Anycast-baseret routing, mens andre foretr\u00e6kker DNS-baseret routing: den n\u00e6rmeste server v\u00e6lges afh\u00e6ngigt af, hvor brugeren befinder sig med sin DNS-server.<\/p>\n<p>Hybridinfrastrukturer og infrastrukturer med flere datacentre er endnu et eksempel p\u00e5 anvendelsen af Anycast. Den Load Balancing IP, der modtages fra udbyderen, g\u00f8r det muligt at fordele belastningen mellem IP-adresserne for forskellige kundeservices i udbyderens datacenter. Takket v\u00e6re adresseanvendelsen til enhver enhed giver det en bedre ydeevne ved betydelig trafik, fejltolerance og hj\u00e6lper med at optimere svartiden ved et stort antal brugere.<\/p>\n<p>I hybridinfrastrukturer med flere datacentre kan trafikken fordeles mellem servere eller endda virtuelle maskiner p\u00e5 dedikerede servere.<\/p>\n<p>Derfor er der et v\u00e6ld af tekniske l\u00f8sninger til opbygning af infrastrukturen. Det er ogs\u00e5 muligt at konfigurere belastningsbalancering efter IP-adresser i flere datacentre ved hj\u00e6lp af gruppens enhedsadresse for at optimere driften af hjemmesiden.<\/p>\n<p>Det er muligt at distribuere trafik i overensstemmelse med egne regler ved at bestemme \"v\u00e6gten\" af hver af de distribuerede servere i hvert datacenter. Denne konfiguration er s\u00e6rligt nyttig, n\u00e5r der er et distribueret serverpar, og ydeevnen af tjenesterne ikke er ensartet. Dette vil g\u00f8re det muligt hyppigere at fordele trafik for at forbedre servernes ydeevne.<\/p>\n<p>For at oprette et kontrolsystem ved hj\u00e6lp af ping-kommandoen er der mulighed for at konfigurere sondem\u00e5lere. Dette giver administratoren mulighed for at bestemme egne kontrolprocedurer og f\u00e5 et klarere billede af tilstanden af hver komponent i infrastrukturen. P\u00e5 denne m\u00e5de kan der bestemmes kriterier for tilg\u00e6ngelighed.<\/p>\n<p>Der er mulighed for at bygge en hybrid infrastruktur: nogle gange er det praktisk at lade backoffice forblive i det corporate netv\u00e6rk, mens den interface-del outsources til en udbyder.<\/p>\n<p>Det er muligt at tilf\u00f8je SSL-certifikater til belastningsfordeling, kryptering af overf\u00f8rte data og sikker kommunikation mellem brugere af webstedet og den virksomhedsinfrastruktur. Ved belastningsfordeling mellem datacentre kan SSL ogs\u00e5 anvendes.<\/p>\n<p>Anycast-tjenesten med belastningsfordeling af adresser kan f\u00e5s fra udbyderen. Denne funktion vil hj\u00e6lpe med at forbedre brugerinteraktion med applikationer baseret p\u00e5 deres placering. Det er tilstr\u00e6kkeligt at annoncere, hvilke tjenester der er tilg\u00e6ngelige i datacenteret, og trafikken vil blive omdirigeret til den n\u00e6rmeste infrastruktur. Hvis der er dedikerede servere, f.eks. i Frankrig eller Nordamerika, vil kunderne blive dirigeret til den n\u00e6rmeste server i netv\u00e6rket.<\/p>\n<p>En mulighed for at bruge Anycast er det optimale valg af operat\u00f8rens point of presence (PoP). Lad os n\u00e6vne <noindex><a rel=\"nofollow\" href=\"https:\/\/engineering.linkedin.com\/network-performance\/tcp-over-ip-anycast-pipe-dream-or-reality\">eksempel<\/a><\/noindex>. LinkedIn (blokeret i Rusland) str\u00e6ber ikke kun efter at forbedre ydeevnen og hastigheden af sine produkter - mobile og webapplikationer - men ogs\u00e5 at forbedre netv\u00e6rksinfrastrukturen til hurtigere levering af indhold. Til dynamisk indholdslevering bruger LinkedIn aktivt PoP - public point of presence. For at lede brugerne til den n\u00e6rmeste PoP anvendes Anycast.<\/p>\n<p>\u00c5rsagen er, at hver PoP LinkedIn har en unik IP-adresse i tilf\u00e6lde af Unycast. Brugerne tildeles derefter PoP afh\u00e6ngigt af deres geografiske placering ved hj\u00e6lp af DNS. Problemet er, at omkring 30% af brugerne i USA blev omdirigeret til en suboptimal PoP ved brug af DNS. Gennem trinvist implementering af Anycast faldt den suboptimale tildeling af PoP fra 31% til 10%.<\/p>\n<p><img decoding=\"async\" alt=\"Anycast vs Unicast: hvad skal man v\u00e6lge i hver enkelt situation\" src=\"\/wp-content\/uploads\/2020\/07\/f1635951294bc476639ec65d175c11e0.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Resultaterne fra pilot testen vises i grafen, hvor Y-aksen er procentdelen af optimal PoP tildeling. Efterh\u00e5nden som Anycast blev 'udrullet', blev der observeret en forbedring i procentdelen af trafikken til den optimale PoP i mange stater i USA.<\/i><\/p>\n<h2>Anycast netv\u00e6rksoverv\u00e5gning<\/h2>\n<p>\nTeoretisk set er Anycast netv\u00e6rk simple: flere fysiske servere tildeles den samme IP-adresse, som BGP bruger til at bestemme ruten. Men implementeringen og designet af Anycast platforme er komplekse, is\u00e6r for de fejltolerante Anycast netv\u00e6rk. Endnu mere kompliceret er den effektive overv\u00e5gning af Anycast netv\u00e6rket for hurtigt at identificere og lokalisere fejl. <\/p>\n<p>Hvis tjenester bruger en tredjeparts CDN leverand\u00f8r til at levere deres indhold, er det meget vigtigt at overv\u00e5ge og kontrollere netv\u00e6rkets ydeevne. Ved overv\u00e5gning af Anycast-baserede CDN'er, fokuseres der prim\u00e6rt p\u00e5 at m\u00e5le end-to-end forsinkelser og dataovergangskarakteristika for at identificere, hvilket datacenter der leverer indholdet. Analyse af HTTP-serveroverskrifter er en anden m\u00e5de at bestemme, hvorfra dataene kommer.<\/p>\n<p><img decoding=\"async\" alt=\"Anycast vs Unicast: hvad skal man v\u00e6lge i hver enkelt situation\" src=\"\/wp-content\/uploads\/2020\/07\/9dfcf689c3c7a553b00de5f0dac4d0ec.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Eksempel: HTTP-svaroverskrifter, der angiver placeringen af CDN-serveren.<\/i><\/p>\n<p>For eksempel bruger CloudFlare sin egen CF-Ray-overskrift i HTTP-svar, som inkluderer angivelsen af det datacenter, hvor anmodningen blev sendt. For Zendesk er CF-Ray-overskriften for Seattle-regionen CF-RAY: 2a21675e65fd2a3d-SEA, mens den for Amsterdam er CF-RAY: 2a216896b93a0c71-AMS. HTTP-X-overskrifter fra HTTP-svaret kan ogs\u00e5 bruges til at bestemme, hvor indholdet befinder sig.<\/p>\n<h2>Andre adresseringsmetoder<\/h2>\n<p>\nDer findes ogs\u00e5 andre adresseringsmetoder til at rute brugerforesp\u00f8rgsler til en specifik netv\u00e6rks slutpunkt:<\/p>\n<p>Unicast<\/p>\n<p>En stor del af internettet i dag bruger netop denne metode. Unicast er en en-til-en overf\u00f8rsel, hvor IP-adressen kun er knyttet til en enkelt specifik node i netv\u00e6rket. Dette kaldes en entydig tildeling.\u00a0<\/p>\n<p>Multicast<\/p>\n<p>Multicast bruger forbindelsen \"\u00e9n til mange fra mange\" eller \"mange til mange\". Multicast giver mulighed for at sende en anmodning fra afsenderen samtidigt til forskellige valgte slutpunkter. Dette giver kunden mulighed for at downloade en fil i portioner fra flere v\u00e6rter samtidigt (hvilket er nyttigt til streaming af lyd eller video). Multicast forveksles ofte med Anycast, men den v\u00e6sentligste forskel er, at Anycast sender afsenderen til en bestemt node, selvom der er flere noder tilg\u00e6ngelige.<\/p>\n<p>Broadcast<\/p>\n<p>Datagrammet fra en enkelt afsender sendes til alle slutpunkter, der er tilknyttet den broadcast-adresse. Netv\u00e6rket replikerer automatisk datagrammerne for at kunne kommunikere med alle modtagere i broadcast (normalt inden for samme subnet).<\/p>\n<p>Geocast<\/p>\n<p>Geocast ligner p\u00e5 en m\u00e5de Multicast: anmodninger fra afsenderen sendes samtidigt til flere slutpunkter. Forskellen er dog, at modtageren bestemmes af hans geografiske placering. Dette er en specialiseret form for gruppedressning, der anvendes af nogle routingprotokoller til mobile peer-to-peer-netv\u00e6rk.<\/p>\n<p>Geografisk router (Geo Router) beregner sit d\u00e6kningsomr\u00e5de og approximere det. Georouters bygger routingtabeller ved at udveksle d\u00e6kningsomr\u00e5der. Systemet af georouters har en hierarkisk struktur.<\/p>\n<p><img decoding=\"async\" alt=\"Anycast vs Unicast: hvad skal man v\u00e6lge i hver enkelt situation\" src=\"\/wp-content\/uploads\/2020\/07\/fa98a1f0705bd754e1a9c8b479c834a7.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<img decoding=\"async\" alt=\"Anycast vs Unicast: hvad skal man v\u00e6lge i hver enkelt situation\" src=\"\/wp-content\/uploads\/2020\/07\/da36388f194ac565aba7b7661839ff6c.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<img decoding=\"async\" alt=\"Anycast vs Unicast: hvad skal man v\u00e6lge i hver enkelt situation\" src=\"\/wp-content\/uploads\/2020\/07\/16161b1bdc81867d8c8bba7bd084b7cf.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Unicast, Multicast og Broadcast.<\/i><\/p>\n<p>Brugen af Anycast-teknologi \u00f8ger p\u00e5lideligheden, fejltilg\u00e6ngeligheden og sikkerheden i DNS. Ved at anvende denne teknologi tilbyder operat\u00f8rer deres kunder tjenester inden for forskellige former for belastningsbalancering baseret p\u00e5 DNS. I kontrolpanelet kan IP-adresser angives, som anmodninger sendes til afh\u00e6ngigt af den geografiske lokalisering. Dette giver kunderne mulighed for mere fleksibelt at fordele brugeranmodninger.<\/p>\n<p>Nogle operat\u00f8rer anvender ruteoverv\u00e5gningsv\u00e6rkt\u00f8jer p\u00e5 hvert punkt for tilstedev\u00e6relse (POP): systemet analyserer automatisk de korteste lokale og globale ruter til punkterne og omdirigerer dem gennem geografiske placeringer med den laveste latenstid uden nedetid.<\/p>\n<p>I \u00f8jeblikket er Anycast den mest stabile og p\u00e5lidelige l\u00f8sning til opbygning af h\u00f8jt belastede DNS-tjenester, som har h\u00f8je krav til stabilitet og p\u00e5lidelighed. <\/p>\n<p>.ru dom\u00e6net underst\u00f8tter 35 Anycast DNS-servere, grupperet i 20 noder, fordelt p\u00e5 fem Anycast-skyer. Her anvendes princippet for geografisk opbygning, dvs. Geocast. Ved placeringen af DNS-noderne tages der h\u00f8jde for geografisk spredning, t\u00e6ttere p\u00e5 de mest aktive brugere, maksimal koncentration af russiske udbydere i nodens placering samt tilg\u00e6ngelig kapacitet og brugervenlighed.<\/p>\n<h2>Hvordan opbygger man en CDN?<\/h2>\n<p>\nCDN er et netv\u00e6rk af servere, der accelererer leveringen af indhold til brugerne.<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/ruvds\/blog\/503800\/\"> Indholdsleveringsnetv\u00e6rk<\/a><\/noindex> samler alle serverne i et enkelt netv\u00e6rk og sikrer hurtigere indl\u00e6sningshastighed af indhold. Afstanden fra serveren til brugeren spiller en vigtig rolle for indl\u00e6sningshastigheden.<\/p>\n<p>CDN giver mulighed for at bruge servere, der er t\u00e6ttest p\u00e5 m\u00e5lgruppen. Dette reducerer ventetiden og hj\u00e6lper med at fremskynde indl\u00e6sningen af indholdet p\u00e5 sites for alle bes\u00f8gende, hvilket er s\u00e6rligt kritisk for sites med store filer eller multimedia-tjenester. Typiske anvendelsesomr\u00e5der for CDN er e-handel og underholdning.<\/p>\n<p>Det netv\u00e6rk af ekstra servere, der oprettes i CDN-infrastrukturen og placeres s\u00e5 t\u00e6t p\u00e5 brugerne som muligt, bidrager til en mere stabil og hurtigere dataoverf\u00f8rsel. If\u00f8lge statistikker reducerer brugen af CDN ventetiden ved adgang til et site med over 70% sammenlignet med sites uden CDN.<\/p>\n<p>siger<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/ruvds\/blog\/466447\/\"> opret en CDN med DNS<\/a><\/noindex>? \u041d\u0430\u0441\u0442\u0440\u043e\u0439\u043a\u0430 CDN \u0441 \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u043d\u0438\u0435\u043c \u0441\u043e\u0431\u0441\u0442\u0432\u0435\u043d\u043d\u043e\u0433\u043e \u0440\u0435\u0448\u0435\u043d\u0438\u044f Anycast \u043c\u043e\u0436\u0435\u0442 \u0431\u044b\u0442\u044c \u0434\u043e\u0441\u0442\u0430\u0442\u043e\u0447\u043d\u043e \u0434\u043e\u0440\u043e\u0433\u0438\u043c \u043f\u0440\u043e\u0435\u043a\u0442\u043e\u043c, \u043d\u043e \u0435\u0441\u0442\u044c \u0431\u043e\u043b\u0435\u0435 \u0434\u0435\u0448\u0435\u0432\u044b\u0435 \u0432\u0430\u0440\u0438\u0430\u043d\u0442\u044b. \u041d\u0430\u043f\u0440\u0438\u043c\u0435\u0440, \u043c\u043e\u0436\u043d\u043e \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u044c GeoDNS \u0438 \u043e\u0431\u044b\u0447\u043d\u044b\u0435 \u0441\u0435\u0440\u0432\u0435\u0440\u044b \u0441 \u0443\u043d\u0438\u043a\u0430\u043b\u044c\u043d\u044b\u043c\u0438 IP-\u0430\u0434\u0440\u0435\u0441\u0430\u043c\u0438. \u0421 \u043f\u043e\u043c\u043e\u0449\u044c\u044e \u0441\u0435\u0440\u0432\u0438\u0441\u043e\u0432 GeoDNS \u043c\u043e\u0436\u043d\u043e \u0441\u043e\u0437\u0434\u0430\u0442\u044c CDN \u0441 \u0444\u0443\u043d\u043a\u0446\u0438\u044f\u043c\u0438 \u0433\u0435\u043e\u043b\u043e\u043a\u0430\u0446\u0438\u0438, \u0432 \u043a\u043e\u0442\u043e\u0440\u043e\u0439 \u0440\u0435\u0448\u0435\u043d\u0438\u044f \u043f\u0440\u0438\u043d\u0438\u043c\u0430\u044e\u0442\u0441\u044f \u043d\u0430 \u043e\u0441\u043d\u043e\u0432\u0435 \u0440\u0435\u0430\u043b\u044c\u043d\u043e\u0433\u043e \u043c\u0435\u0441\u0442\u043e\u043f\u043e\u043b\u043e\u0436\u0435\u043d\u0438\u044f \u043f\u043e\u0441\u0435\u0442\u0438\u0442\u0435\u043b\u044f, \u0430 \u043d\u0435 \u043c\u0435\u0441\u0442\u043e\u043f\u043e\u043b\u043e\u0436\u0435\u043d\u0438\u044f \u0440\u0435\u0441\u043e\u043b\u0432\u0435\u0440\u0430 DNS. \u041c\u043e\u0436\u043d\u043e \u043d\u0430\u0441\u0442\u0440\u043e\u0438\u0442\u044c \u0441\u0432\u043e\u044e DNS-\u0437\u043e\u043d\u0443 \u0442\u0430\u043a, \u0447\u0442\u043e\u0431\u044b \u043f\u043e\u043a\u0430\u0437\u044b\u0432\u0430\u0442\u044c IP-\u0430\u0434\u0440\u0435\u0441\u0430 \u0430\u043c\u0435\u0440\u0438\u043a\u0430\u043d\u0441\u043a\u0438\u0445 \u0441\u0435\u0440\u0432\u0435\u0440\u043e\u0432 \u043f\u043e\u0441\u0435\u0442\u0438\u0442\u0435\u043b\u044f\u043c \u0438\u0437 \u0421\u0428\u0410, \u0430 \u0435\u0432\u0440\u043e\u043f\u0435\u0439\u0441\u043a\u0438\u0435 \u043f\u043e\u0441\u0435\u0442\u0438\u0442\u0435\u043b\u0438 \u0431\u0443\u0434\u0443\u0442 \u0432\u0438\u0434\u0435\u0442\u044c IP-\u0430\u0434\u0440\u0435\u0441 \u0438\u0437 \u0415\u0432\u0440\u043e\u043f\u044b.<\/p>\n<p>Med GeoDNS kan forskellige DNS-svar returneres afh\u00e6ngigt af brugerens IP-adresse. For dette konfigureres DNS-serveren til at returnere forskellige IP-adresser baseret p\u00e5 den oprindelige IP-adresse i foresp\u00f8rgslen. Normalt anvendes en GeoIP-database til at bestemme den region, som foresp\u00f8rgslen stammer fra. Geolokation ved hj\u00e6lp af DNS muligg\u00f8r at sende brugerne indhold fra den n\u00e6rmeste site.<\/p>\n<p>GeoDNS bestemmer IP-adressen p\u00e5 den klient, der sender DNS-foresp\u00f8rgslen, eller IP'en p\u00e5 den rekursive DNS-server fra udbyderen, der bruges til at behandle klientforesp\u00f8rgslen. Ved hj\u00e6lp af klientens IP og GeoIP-databasen bestemmes landet\/regionen. Derefter modtager klienten IP-adressen til den n\u00e6rmeste CDN-server. Du kan l\u00e6se mere om ops\u00e6tning af GeoDNS.<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/post\/178727\/\"> her<\/a><\/noindex>.<\/p>\n<h2>Anycast eller GeoDNS?<\/h2>\n<p>\nSelvom Anycast er en fremragende metode til global indholdslevering, mangler den specifikhed. Her kommer GeoDNS ind i billedet. Denne tjeneste giver mulighed for at oprette regler, der sender brugere til unikke slutpunkter baseret p\u00e5 deres placering.<\/p>\n<p><img decoding=\"async\" alt=\"Anycast vs Unicast: hvad skal man v\u00e6lge i hver enkelt situation\" src=\"\/wp-content\/uploads\/2020\/07\/05c9d6752ba196f90bfefe6091075b23.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Eksempel: Brugere fra Europa ledes til et andet slutpunkt.<\/i><\/p>\n<p>Adgang til dom\u00e6ner kan ogs\u00e5 forhindres ved at afvise alle foresp\u00f8rgsler. Dette er blandt andet en hurtig m\u00e5de at sk\u00e6re alle angribere v\u00e6k.<\/p>\n<p>GeoDNS giver mere pr\u00e6cise svar end Anycast. Hvis det i tilf\u00e6lde af Anycast er den korteste rute bestemt af antal hop, s\u00e5 sker routingen for slutbrugere i GeoDNS baseret p\u00e5 deres fysiske placering. Dette reducerer latenstid og forbedrer pr\u00e6cisionen ved oprettelse af granulerede routingregler. <\/p>\n<p>N\u00e5r man navigerer til et dom\u00e6ne, henvender browseren sig til den n\u00e6rmeste DNS-server, som, afh\u00e6ngigt af dom\u00e6net, giver IP-adressen til at indl\u00e6se hjemmesiden. Antag, at en online butik er popul\u00e6r i USA og Europa, og at dens DNS-servere kun er i Europa. S\u00e5 vil brugere fra USA, der \u00f8nsker at benytte butikkens tjenester, v\u00e6re n\u00f8dt til at sende en foresp\u00f8rgsel til den n\u00e6rmeste server, og da den er meget langt v\u00e6k, m\u00e5 de vente l\u00e6nge p\u00e5 et svar \u2014 indl\u00e6sningstiden for hjemmesiden vil v\u00e6re lang.<\/p>\n<p>Ved at placere en GeoDNS-server i USA vil brugerne nu henvende sig til den. Svaret vil v\u00e6re hurtigt, hvilket vil p\u00e5virke indl\u00e6sningstiden for hjemmesiden.<\/p>\n<p>I situationen med en eksisterende DNS-server i USA, n\u00e5r en bruger fra USA g\u00e5r til dette dom\u00e6ne, vil han kontakte den n\u00e6rmeste server, der vil give den n\u00f8dvendige IP. Brugeren vil blive sendt til den server, der indeholder indholdet p\u00e5 hjemmesiden, men da serverne med indholdet er langt v\u00e6k, vil han ikke modtage det hurtigt.<\/p>\n<p>Hvis man placerer servere i USA og CDN-servere med cachelagrede data, vil browseren hos kunden sende en anmodning til den n\u00e6rmeste DNS-server, som returnerer den \u00f8nskede IP-adresse. Browseren kontakter den n\u00e6rmeste CDN-server og hovedserveren med den modtagne IP, og CDN-serveren sender det cachelagrede indhold til browseren. Mens det cachelagrede indhold hentes, overf\u00f8rer hovedserveren de manglende filer, der er n\u00f8dvendige for at indl\u00e6se hele webstedet. Dette reducerer indl\u00e6sningstiden for webstedet, da der sendes v\u00e6sentligt f\u00e6rre filer fra hovedserveren. <\/p>\n<p>At bestemme den pr\u00e6cise placering af en bestemt IP-adresse er ikke altid en let opgave: mange faktorer spiller ind, og ejere af IP-adresseomr\u00e5der kan beslutte at annoncere dem i den anden ende af verden (i s\u00e5 fald skal man vente p\u00e5, at databasen opdateres for at f\u00e5 den rigtige placering). Nogle gange tildeler VPS-udbydere adresser, der formodes at v\u00e6re i USA, til VPS i Singapore.<\/p>\n<p>I mods\u00e6tning til brugen af Anycast-adresser udf\u00f8res distributionen under navnegodkendelsen og ikke under forbindelsen til cache-serveren. Hvis den rekursive server ikke underst\u00f8tter klient subnet EDNS, anvendes placeringen af denne rekursive server i stedet for brugerens tilslutning til cache-serveren.<\/p>\n<p>Klient subnet i DNS er en DNS-udvidelse (RFC7871), der definerer, hvordan rekursive DNS-servere kan sende information om klienten til DNS-serveren, s\u00e6rligt information om netv\u00e6rket, som GeoDNS-serveren kan bruge til at bestemme klientens placering mere pr\u00e6cist.<\/p>\n<p>De fleste bruger DNS-servere fra deres internetudbyder eller DNS-servere, der geografisk er t\u00e6t p\u00e5 dem, men hvis nogen i USA af en eller anden grund beslutter at bruge en DNS-resolver, der er placeret i Australien, vil de sandsynligvis f\u00e5 IP-adressen p\u00e5 den server, der er t\u00e6ttest p\u00e5 Australien. <\/p>\n<p>Hvis du \u00f8nsker at bruge GeoDNS, er det vigtigt at v\u00e6re opm\u00e6rksom p\u00e5 s\u00e5danne s\u00e6regenheder, da det i nogle tilf\u00e6lde kan \u00f8ge afstanden mellem cache-serverne og klienten.<\/p>\n<p>Resum\u00e9: Hvis du \u00f8nsker at kombinere flere VPS i et CDN, er den bedste implementeringsmulighed at bruge en kombination af DNS-server med GeoDNS-funktionalitet + Anycast \"out-of-the-box\".<\/p>\n<p><noindex><a rel=\"nofollow\" href=\"http:\/\/ruvds.com\/ru-rub?utm_source=habr&amp;utm_medium=article&amp;utm_campaign=caplin&amp;utm_content=anycastvsunicast#order\"><img decoding=\"async\" alt=\"Anycast vs Unicast: hvad skal man v\u00e6lge i hver enkelt situation\" src=\"\/wp-content\/uploads\/2020\/07\/73c6b0732883a352ddd9096804f2e533.png\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><br \/>\n<br \/>Kilde: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/ruvds\/blog\/511050\/\">habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u041f\u0440\u043e Anycast \u043d\u0430\u0432\u0435\u0440\u043d\u044f\u043a\u0430 \u043c\u043d\u043e\u0433\u0438\u0435 \u0441\u043b\u044b\u0448\u0430\u043b\u0438. \u041f\u0440\u0438 \u044d\u0442\u043e\u043c \u043c\u0435\u0442\u043e\u0434\u0435 \u0441\u0435\u0442\u0435\u0432\u043e\u0439 \u0430\u0434\u0440\u0435\u0441\u0430\u0446\u0438\u0438 \u0438 \u043c\u0430\u0440\u0448\u0440\u0443\u0442\u0438\u0437\u0430\u0446\u0438\u0438 \u043e\u0434\u0438\u043d IP-\u0430\u0434\u0440\u0435\u0441 \u043f\u0440\u0438\u0441\u0432\u0430\u0438\u0432\u0430\u0435\u0442\u0441\u044f \u043d\u0435\u0441\u043a\u043e\u043b\u044c\u043a\u0438\u043c \u0441\u0435\u0440\u0432\u0435\u0440\u0430\u043c \u0432 \u0441\u0435\u0442\u0438. \u042d\u0442\u0438 \u0441\u0435\u0440\u0432\u0435\u0440\u044b \u043c\u043e\u0433\u0443\u0442 \u043d\u0430\u0445\u043e\u0434\u0438\u0442\u044c\u0441\u044f \u0434\u0430\u0436\u0435 \u0432 \u0443\u0434\u0430\u043b\u0435\u043d\u043d\u044b\u0445 \u0434\u0440\u0443\u0433 \u043e\u0442 \u0434\u0440\u0443\u0433\u0430 \u0426\u041e\u0414. \u0418\u0434\u0435\u044f Anycast \u0432 \u0442\u043e\u043c, \u0447\u0442\u043e, \u0432 \u0437\u0430\u0432\u0438\u0441\u0438\u043c\u043e\u0441\u0442\u0438 \u043e\u0442 \u043c\u0435\u0441\u0442\u043e\u043f\u043e\u043b\u043e\u0436\u0435\u043d\u0438\u044f \u0438\u0441\u0442\u043e\u0447\u043d\u0438\u043a\u0430 \u0437\u0430\u043f\u0440\u043e\u0441\u043e\u0432, \u0434\u0430\u043d\u043d\u044b\u0435 \u043e\u0442\u043f\u0440\u0430\u0432\u043b\u044f\u044e\u0442\u0441\u044f \u043d\u0430 \u0431\u043b\u0438\u0436\u0430\u0439\u0448\u0438\u0439 (\u0441\u043e\u0433\u043b\u0430\u0441\u043d\u043e \u0442\u043e\u043f\u043e\u043b\u043e\u0433\u0438\u0438 \u0441\u0435\u0442\u0438, \u0442\u043e\u0447\u043d\u0435\u0435 \u2014 \u043f\u0440\u043e\u0442\u043e\u043a\u043e\u043b\u0430 \u043c\u0430\u0440\u0448\u0440\u0443\u0442\u0438\u0437\u0430\u0446\u0438\u0438 BGP) \u0441\u0435\u0440\u0432\u0435\u0440. \u0422\u0430\u043a\u0438\u043c [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":88962,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-88961","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.3 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u041f\u0440\u043e Anycast \u043d\u0430\u0432\u0435\u0440\u043d\u044f\u043a\u0430 \u043c\u043d\u043e\u0433\u0438\u0435 \u0441\u043b\u044b\u0448\u0430\u043b\u0438. \u041f\u0440\u0438 \u044d\u0442\u043e\u043c \u043c\u0435\u0442\u043e\u0434\u0435 \u0441\u0435\u0442\u0435\u0432\u043e\u0439 \u0430\u0434\u0440\u0435\u0441\u0430\u0446\u0438\u0438 \u0438 \u043c\u0430\u0440\u0448\u0440\u0443\u0442\u0438\u0437\u0430\u0446\u0438\u0438 \u043e\u0434\u0438\u043d IP-\u0430\u0434\u0440\u0435\u0441 \u043f\u0440\u0438\u0441\u0432\u0430\u0438\u0432\u0430\u0435\u0442\u0441\u044f \u043d\u0435\u0441\u043a\u043e\u043b\u044c\u043a\u0438\u043c \u0441\u0435\u0440\u0432\u0435\u0440\u0430\u043c \u0432 \u0441\u0435\u0442\u0438. \u042d\u0442\u0438 \u0441\u0435\u0440\u0432\u0435\u0440\u044b \u043c\u043e\u0433\u0443\u0442 \u043d\u0430\u0445\u043e\u0434\u0438\u0442\u044c\u0441\u044f \u0434\u0430\u0436\u0435 \u0432 \u0443\u0434\u0430\u043b\u0435\u043d\u043d\u044b\u0445 \u0434\u0440\u0443\u0433 \u043e\u0442 \u0434\u0440\u0443\u0433\u0430 \u0426\u041e\u0414.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/anycast-protiv-unicast-chto-luchshe-vybirat-v-kazhdom-sluchae\" \/>\n\t\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.3\" \/>\n\t\t<meta property=\"og:locale\" content=\"da_DK\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47Anycast \u043f\u0440\u043e\u0442\u0438\u0432 Unicast: \u0447\u0442\u043e \u043b\u0443\u0447\u0448\u0435 \u0432\u044b\u0431\u0438\u0440\u0430\u0442\u044c \u0432 \u043a\u0430\u0436\u0434\u043e\u043c \u0441\u043b\u0443\u0447\u0430\u0435 | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u041f\u0440\u043e Anycast \u043d\u0430\u0432\u0435\u0440\u043d\u044f\u043a\u0430 \u043c\u043d\u043e\u0433\u0438\u0435 \u0441\u043b\u044b\u0448\u0430\u043b\u0438. \u041f\u0440\u0438 \u044d\u0442\u043e\u043c \u043c\u0435\u0442\u043e\u0434\u0435 \u0441\u0435\u0442\u0435\u0432\u043e\u0439 \u0430\u0434\u0440\u0435\u0441\u0430\u0446\u0438\u0438 \u0438 \u043c\u0430\u0440\u0448\u0440\u0443\u0442\u0438\u0437\u0430\u0446\u0438\u0438 \u043e\u0434\u0438\u043d IP-\u0430\u0434\u0440\u0435\u0441 \u043f\u0440\u0438\u0441\u0432\u0430\u0438\u0432\u0430\u0435\u0442\u0441\u044f \u043d\u0435\u0441\u043a\u043e\u043b\u044c\u043a\u0438\u043c \u0441\u0435\u0440\u0432\u0435\u0440\u0430\u043c \u0432 \u0441\u0435\u0442\u0438. \u042d\u0442\u0438 \u0441\u0435\u0440\u0432\u0435\u0440\u044b \u043c\u043e\u0433\u0443\u0442 \u043d\u0430\u0445\u043e\u0434\u0438\u0442\u044c\u0441\u044f \u0434\u0430\u0436\u0435 \u0432 \u0443\u0434\u0430\u043b\u0435\u043d\u043d\u044b\u0445 \u0434\u0440\u0443\u0433 \u043e\u0442 \u0434\u0440\u0443\u0433\u0430 \u0426\u041e\u0414.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/anycast-protiv-unicast-chto-luchshe-vybirat-v-kazhdom-sluchae\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2020-07-16T17:42:34+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2020-07-16T17:42:34+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Anycast vs. Unicast: hvad skal man v\u00e6lge i hvert tilf\u00e6lde | ProHoster","description":"Mange har sikkert h\u00f8rt om Anycast. Denne metode til netv\u00e6rksadressering og routing tildeler \u00e9n IP-adresse til flere servere i netv\u00e6rket. Disse servere kan ligge selv i fjerntliggende datacentre.","canonical_url":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/anycast-protiv-unicast-chto-luchshe-vybirat-v-kazhdom-sluchae","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"da_DK","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47Anycast \u043f\u0440\u043e\u0442\u0438\u0432 Unicast: \u0447\u0442\u043e \u043b\u0443\u0447\u0448\u0435 \u0432\u044b\u0431\u0438\u0440\u0430\u0442\u044c \u0432 \u043a\u0430\u0436\u0434\u043e\u043c \u0441\u043b\u0443\u0447\u0430\u0435 | ProHoster","og:description":"\u041f\u0440\u043e Anycast \u043d\u0430\u0432\u0435\u0440\u043d\u044f\u043a\u0430 \u043c\u043d\u043e\u0433\u0438\u0435 \u0441\u043b\u044b\u0448\u0430\u043b\u0438. \u041f\u0440\u0438 \u044d\u0442\u043e\u043c \u043c\u0435\u0442\u043e\u0434\u0435 \u0441\u0435\u0442\u0435\u0432\u043e\u0439 \u0430\u0434\u0440\u0435\u0441\u0430\u0446\u0438\u0438 \u0438 \u043c\u0430\u0440\u0448\u0440\u0443\u0442\u0438\u0437\u0430\u0446\u0438\u0438 \u043e\u0434\u0438\u043d IP-\u0430\u0434\u0440\u0435\u0441 \u043f\u0440\u0438\u0441\u0432\u0430\u0438\u0432\u0430\u0435\u0442\u0441\u044f \u043d\u0435\u0441\u043a\u043e\u043b\u044c\u043a\u0438\u043c \u0441\u0435\u0440\u0432\u0435\u0440\u0430\u043c \u0432 \u0441\u0435\u0442\u0438. \u042d\u0442\u0438 \u0441\u0435\u0440\u0432\u0435\u0440\u044b \u043c\u043e\u0433\u0443\u0442 \u043d\u0430\u0445\u043e\u0434\u0438\u0442\u044c\u0441\u044f \u0434\u0430\u0436\u0435 \u0432 \u0443\u0434\u0430\u043b\u0435\u043d\u043d\u044b\u0445 \u0434\u0440\u0443\u0433 \u043e\u0442 \u0434\u0440\u0443\u0433\u0430 \u0426\u041e\u0414.","og:url":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/anycast-protiv-unicast-chto-luchshe-vybirat-v-kazhdom-sluchae","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-07-16T17:42:34+00:00","article:modified_time":"2020-07-16T17:42:34+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"88961","title":null,"description":null,"keywords":null,"keyphrases":{"focus":[],"additional":[]},"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 13:19:34","updated":"2026-08-11 12:50:13","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts\/88961","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/comments?post=88961"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts\/88961\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media\/88962"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media?parent=88961"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/categories?post=88961"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/tags?post=88961"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}