애니캐스트

Anycast
애니캐스트 라우팅 시각화

애니캐스트는, 1 개의 행선지 IP 주소를 복수의 로케이션의 디바이스(통상은 서버)에 의해서 공유하는 네트워크 어드레싱 및 라우팅 방식입니다.라우터는, 통상의 의사결정 알고리즘(통상은 최저의 BGP 네트워크 홉 수)을 사용하고, 이 행선지를 수신처로 하는 패킷을 송신원으로부터 가장 가까운 로케이션으로 보냅니다.애니캐스트 라우팅은 웹 호스트나 DNS 호스트 등의 콘텐츠 전송 네트워크에서 널리 사용되며 콘텐츠를 최종 사용자에게 더 가까이 보내기 위해 사용됩니다.

어드레싱 방식

라우팅 방식
유니캐스트

Unicast.svg

브로드캐스트

Broadcast.svg

멀티캐스트

Multicast.svg

애니캐스트

Anycast-BM.svg

Internet Protocol 에는, 다음의 4개의 주요한 어드레싱 방법이 있습니다.

  • 유니캐스트는, 송신자와 행선지간의 1 대 1 의 어소시에이션을 사용해, 단일의 특정 노드에 메세지를 전달합니다.각 행선지 주소는, 단일의 수신측 엔드 포인트를 일의로 식별합니다.
  • 브로드캐스트는 일대일 어소시에이션을 사용하여 네트워크 내의 모든 노드에 메시지를 전달합니다.1개의 송신원으로부터의 단일 데이터그램(또는 패킷)은 브로드캐스트주소에 관련지어져 있는 가능성이 있는 복수의 엔드 포인트 모두에 라우팅 됩니다.네트워크는 브로드캐스트 범위 내의 모든 수신자에게 도달하기 위해 필요에 따라 데이터그램을 자동으로 복제합니다.이것은 일반적으로 네트워크 서브넷 전체입니다.
  • 멀티캐스트는 1 대 다 또는 다 대 다의 어소시에이션을 사용하여 메시지 수신에 관심을 나타낸 노드 그룹에 메시지를 전달합니다.데이터그램은 단일 전송으로 동시에 다수의 수신자에게 라우팅됩니다.멀티캐스트는 수신처 주소가 액세스 가능한 노드의 서브셋(전부는 아님)을 지정하는 점에서 브로드캐스트와 다릅니다.
  • 애니캐스트는, 같은 행선지 주소로 식별되는 잠재적인 리시버 그룹의 1개의 멤버에게 데이터 그램이 라우팅 되는, 통상, 1 대 다의 어소시에이션을 사용해, 노드 그룹내의 임의의 1 개에 메세지를 전달합니다.라우팅 알고리즘은 어떤 거리 또는 비용 측도에 따라 가장 가까운 수신기를 그룹에서 선택합니다.

역사

인터넷 접속 서비스의 토폴로지 로드밸런싱을 위해 애니캐스트 루팅을 최초로 사용한 것은 [1][2]1989년이며, 이 기법은 4년 후 IETF에서 정식으로 문서화되어 있습니다. RFC 1546은 [3]2001년 I-root 네임서버 [2]애니캐스팅을 통해 중요한 인프라스트럭처에 처음 적용되었습니다.

초기 이의

장기간의 TCP 접속과 인터넷 라우팅 토폴로지의 불안정성 간의 인식된 경합을 중심으로 한 애니캐스트라우팅 배치에 대한 초기 반대.개념적으로는 네트워크토폴로지 또는 라우팅의 변경에 의해 FTP 파일 전송(이 문제가 논의되고 있던 1990년대 중반에는 완료하는데 몇 시간이 걸렸을 가능성이 있음)과 같은 긴 접속은 접속 도중에 다른 애니캐스트인스턴스로 재루팅되어 서버가 접속 도중에 변경되어 새로운 서비스가 제공될 수 있습니다.er는 접속을 인식하고 있지 않으며 이전 애니캐스트인스턴스의 TCP 접속 스테이트를 소유하고 있지 않습니다.

실제로 이러한 문제는 관찰되지 않았으며 2000년대 초반에는 이러한 반대가 사라졌습니다.많은 초기 애니캐스트 배치에서는 주로 UDP [4][2]트랜스포트를 사용하는 DNS 서버로 구성되었습니다.장기 애니캐스트플로우를 측정한 결과 미드 커넥션인스턴스위치에 의한 장애는 거의 없었습니다.다양한 소스에 따르면 다른 장애 원인에 의한 장애보다 훨씬 적은(0.017%[5] 미만, [1]즉 '1시간당 1개의 흐름' 미만)이었습니다.애니캐스트 인스턴스 [6]간에 상태를 효율적으로 공유하기 위해 수많은 메커니즘이 개발되었습니다.그리고 일부 TCP 기반 프로토콜, 특히 HTTP는 "리다이렉트" 메커니즘을 포함하며, 여기서 애니캐스트 서비스 주소는 서비스의 가장 가까운 인스턴스를 찾기 위해 사용될 수 있으며, 따라서 사용자는 긴 수명 상태 [1][7]저장 트랜잭션을 시작하기 전에 특정 인스턴스로 리디렉션됩니다.

인터넷 프로토콜 버전 4

애니캐스트는 BGP를 통해 구현할 수 있습니다.복수의 호스트(통상은 다른 지리적 영역내에 있는)에는, 같은 유니캐스트 IP 주소가 할당되어 그 주소에의 다른 루트가 BGP 를 개입시켜 방송됩니다.라우터는, 실제로는 같은 주소를 가지는 다른 행선지에의 루트인 경우에서도, 이러한 루트를 같은 행선지에의 대체 루트로 간주합니다.통상대로 라우터는 사용하고 있는 거리 메트릭(최저비용, 최저 폭주, 최단)에 따라 루트를 선택합니다.이 설정으로 루트를 선택하는 것은, 행선지를 선택하는 것과 같습니다.

인터넷 프로토콜 버전 6

Anycast 는 IPv6 로 명시적으로 서포트되고 있습니다.RFC 4291 에서는, IPv6 어드레싱 아키텍처에 대해 설명하고 있습니다.IPv6 서브넷내의 인터페이스 식별자 0 은, 「서브넷 라우터」애니캐스트주소로 예약되어 있습니다.또한 RFC 2526에서는 서브넷 내의 128개의 인터페이스 ID 블록이 애니캐스트주소로 예약되어 있습니다.

네트워크를 통과하는 애니캐스트패킷 경로상의 대부분의 IPv6 라우터는 유니캐스트패킷과 구별하지 않지만, 수신처 근처에 있는 라우터(즉, 애니캐스트주소의 범위내)에서는, 프로를 가지는 범위내의 「가장 가까운」인터페이스에 애니캐스트패킷을 라우팅 할 필요가 있기 때문에, 특별한 처리가 필요합니다.사용하고 있는 거리(홉, 비용 등)의 측정치에 따라 애니캐스트주소별로 지정합니다.

BGP에서 여러 루트를 애드버타이즈하여 여러 유니캐스트주소를 할당하는 IPv4 의 방식도 IPv6 에서도 기능합니다.또, 같은 주소를 가지는 지리적으로 분산된 복수의 호스트 중 가장 가까운 호스트에 패킷을 라우팅 하기 위해서도 사용할 수 있습니다.anycast 대응 라우터에 의존하지 않는 이 어프로치에서는, IPv4 와 같은 문제나 제한과 함께, 같은 사용 케이스가 있습니다.

적용들

인터넷의 보급에 수반해, 네트워크 서비스의 가용성의 요건이 높아지고 있습니다.그 결과, 애니캐스트 서비스(RFC 4786)의 운용이 네트워크 [8]사업자들 사이에서 인기를 끌고 있다.

도메인 네임 시스템

모든 인터넷 루트네임 서버는 애니캐스트어드레싱을 사용하여 호스트의 클러스터로 구현됩니다.13개의 루트 서버 A~M은 모두 여러 장소에 존재하며, 11개는 여러 대륙에 존재합니다.(루트 서버 B와 H는 미국 내 2개의 로케이션에 존재합니다.)[9][10][11]서버는 애니캐스트주소 방송을 사용하여 분산형 서비스를 제공합니다.이로 인해 (논리가 아닌) 물리적인 루트 서버의 미국 국외 도입이 촉진되었습니다.RFC 3258에서는 신뢰할 수 있는 DNS 서비스를 제공하기 위한 애니캐스트어드레싱의 사용에 대해 설명하고 있습니다.많은 상용 DNS 공급자가 쿼리 성능과 용장성을 향상시키고 로드 [2]밸런싱을 구현하기 위해 IP 애니캐스트 환경으로 전환했습니다.

IPv6 이행

IPv4 에서 IPv6 로의 이행에서는, IPv4 호스트에 IPv6 호환성을 제공하기 위해서 애니 캐스트 어드레싱을 배치할 수 있습니다.이 방식 6 to 4 에서는, RFC 3068 에 기재되어 있듯이, IP 주소가 192.88.99.1 인 디폴트게이트웨이를 사용합니다.이것에 의해, 복수의 프로바이더가 6 to 4 의 게이트웨이를 실장할 수 있습니다.호스트는 각 프로바이더의 게이트웨이 주소를 인식할 필요가 없습니다.이 방법은 RFC 7526에서는 권장되지 않습니다.

콘텐츠 전송 네트워크

콘텐츠 전송 네트워크는 배포 센터 또는 DNS에 대한 실제 HTTP 연결에 애니캐스트를 사용할 수 있습니다. 이러한 네트워크에 대한 대부분의 HTTP 연결은 이미지 및 스타일 시트 등의 정적 콘텐츠를 요구하기 때문에 일반적으로 이후 TCP 세션에서 수명이 짧고 상태 비저장입니다.루트의 일반적인 안정성과 접속 스테이트리스에 의해, 이 애플리케이션에서는 TCP [5][1]를 사용하고 있습니다만, 애니 캐스트는 이 애플리케이션에 적합합니다.

애니캐스트와 멀티캐스트 네트워크 간의 접속

Anycast RP는 용장성 및 로드셰어링 기능을 제공하는 도메인 내 기능이기 때문에 Anycast RP는 MSDP에서 사용할 수 있습니다.멀티 애니캐스트 랑데부포인트가 사용되고 있는 경우, IP 라우팅에 의해서, 각 송신원과 수신자의 토폴로지적으로 가장 가까운 랑데부포인트가 자동적으로 선택됩니다.멀티캐스트 네트워크에 폴트 톨러런스 [12]요건을 제공합니다.

보안.

Anycast를 사용하면 중간 라우터에 의해 라우팅 정보가 받아들여지는 오퍼레이터는 애니캐스트주소로 향하는 패킷을 모두 하이잭 할 수 있습니다.언뜻 보기에는 안전하지 않은 것처럼 보이지만, 일반 IP 패킷의 라우팅과 다르지 않고, 그 이상 또는 그 이하도 아닙니다.기존의 IP 라우팅과 마찬가지로 man-in-the-middle 공격 또는 blackhole 공격을 방지하기 위해서는 루트아나운스 전파 대상자와 전파 금지 대상자를 신중하게 필터링하는 것이 중요합니다.전자는 Transport Layer Security 사용 등 메시지를 암호화 및 인증하는 방법으로도 방지할 수 있지만 후자는 양파 라우팅으로 인해 문제가 발생할 수 있습니다.

신뢰성.

Anycast는 복잡성이나 잠재적인 장애 지점을 추가하지 않고 자동 페일오버를 제공할 수 있기 때문에 일반적으로 신뢰성이 높습니다.일반적으로 애니캐스트어플리케이션에는 서버 기능의 외부 "하트비트" 모니터링 기능이 있으며 서버에 장애가 발생했을 경우 루트 알림을 철회합니다.경우에 따라서는 OSPF 또는 다른 IGP를 통해 라우터에 애니캐스트프리픽스를 방송하는 실제 서버에 의해 이 처리가 이루어집니다.서버가 정지하면, 라우터는 자동적으로 방송을 철회합니다."하트비트" 기능은 장애가 발생한 서버에 대해 방송이 계속되면 서버가 인근 클라이언트의 "블랙홀"로 기능하기 때문에 중요합니다.이는 애니캐스트 시스템에서 가장 심각한 장애 모드입니다.이 경우에도 이런 종류의 장애는 다른 어떤 장애보다 이 서버에 가까운 클라이언트의 완전한 장애만 일으킬 뿐 글로벌 장애는 발생하지 않습니다.그러나 2021년 Facebook 운영 중단에서 보듯이 "하트비트" 라우팅 철회를 구현하기 위해 필요한 자동화도 잠재적인 장애 지점을 추가할 수 있습니다.

서비스 거부 공격 완화

서비스 거부 공격에서는 부정한 네트워크호스트가 중요한 네트워크 서비스의 애니캐스트서버로서 자신을 어드버타이즈 하고, 잘못된 정보를 제공하거나, 단순히 서비스를 차단하는 경우가 있습니다.인터넷상의 애니캐스트 방법론은 DDoS 공격을 분산하여 그 효과를 감소시키기 위해 악용될 수 있습니다.트래픽이 가장 가까운 노드(공격자가 제어할 수 없는 프로세스)로 라우팅되면 DDoS 트래픽플로우는 가장 가까운 노드간에 분산됩니다.따라서 모든 노드가 영향을 받는 것은 아닙니다.이것이 애니캐스트어드레싱을 [13]배치하는 이유일 수 있습니다.

이 기술의 유효성은 애니캐스트서비스 노드에 관련되어 있는 유니캐스트주소의 비밀 유지에 의존합니다.단, 개개의 노드의 유니캐스트주소를 소유하고 있는 공격자는, 애니캐스트어드레싱 [14]방식을 무시하고, 어느 장소로부터든 그 주소를 공격할 수 있기 때문입니다.

로컬 및 글로벌노드

인터넷상의 일부 애니캐스트 배치에서는 로컬노드와 글로벌노드를 구별하여 로컬노드를 우선적으로 어드레싱함으로써 로컬 커뮤니티에 도움이 됩니다.예를 들어 Domain Name System이 있습니다.로컬 노드는 호스트가 로컬노드를 피어에 아나운스 하는 것을 방지하기 위해 no-export BGP 커뮤니티와 함께 방송됩니다.즉, 로컬노드는 로컬영역에 보관됩니다.로컬 노드와 글로벌노드가 모두 배치되어 있는 경우 글로벌노드로부터의 아나운스먼트가 AS 프리펜드(AS가 몇 번 더 추가됨)되는 경우가 많기 때문에 로컬노드의 아나운스먼트가 글로벌노드의 아나운스먼트보다 [15]우선됩니다.

「 」를 참조해 주세요.

레퍼런스

  1. ^ a b c d Woodcock, Bill (June 1996). "Best Practices in Anycast Routing" (PDF). Packet Clearing House.
  2. ^ a b c d Hernandez, Gael (October 10, 2017). "Building and Operating a Global Anycast Network" (PDF). Eurasia Network Operators Group.
  3. ^ Partridge, C.; Mendez, T.; Milliken, W. (November 1993). "Host Anycasting Service" (PDF). RFC 1546. The IETF Trust. Retrieved August 14, 2019.
  4. ^ Woodcock, Bill (November 14, 2019). "TCP and Anycast". NANOG mailing list archive. North American Network Operators Group.
  5. ^ a b Levine, Matt; Lyon, Barrett; Underwood, Todd (June 2006). "TCP Anycast: Don't Believe the FUD - Operational experience with TCP and Anycast" (PDF). North American Network Operators Group.
  6. ^ Herrin, William. "Anycast TCP Architecture". Retrieved October 11, 2021.
  7. ^ Katz-Bassett, Ethan; Gao, Ryan (July 2019). "Impact of TCP Loss on Regional Application Performance" (PDF). Microsoft. Azure Frontdoor uses anycast redirection to direct users to a nearby edge.
  8. ^ Abley, J.; Lindqvist, K. (December 2006). "Operation of Anycast Services" (PDF). RFC 4786. The IETF Trust. Retrieved February 21, 2011.
  9. ^ 홈페이지 B-root DNS 서버, 2015년 2월 8일 방문
  10. ^ "Report on Root Nameserver Locations". Packet Clearing House. Retrieved February 21, 2011.
  11. ^ "Root Server Technical Operations Assn". root-servers.org. Retrieved February 16, 2013.
  12. ^ "Anycast Rendezvous Point". Cisco Systems. June 1, 2001.
  13. ^ "ICANN Factsheet on root server attack on 6 February 2007" (PDF). Factsheet. The Internet Corporation for Assigned Names and Numbers (ICANN). March 1, 2007. Retrieved February 21, 2011.
  14. ^ Metz, C. (2002). "IP Anycast: Point-to-(Any) Point Communication (sign-in required)". IEEE Internet Computing. IEEE. 6 (2): 94–98. doi:10.1109/4236.991450.
  15. ^ Oki, Eiji; Rojas-Cessa, Roberto; Tatipamula, Mallikarjun; Vogt, Christian (April 24, 2012). Advanced Internet Protocols, Services, and Applications. John Wiley & Sons. pp. 102 & 103. ISBN 978-0-470-49903-0. Archived from the original on January 5, 2020.

외부 링크