요약

  • RFC 1546은 애니캐스트 주소를 서비스에 대해 최소한 하나의 서버에 도달하는 방법으로 정의했으며, 응답한 서버의 지속적 신원으로 정의하지 않았다.
  • 동일한 목적지가 다음 데이터그램에서 다른 호스트를 선택할 수 있으므로, 상태, 인스턴스 신원, 복제본 일관성 및 인증에는 주소 이상의 근거가 필요했다.
  • 이후의 RFC들이 어휘와 운영 관행을 다듬었지만, 서비스 로케이터와 책임 있는 응답자 사이의 원래 경계는 그대로 유지되었다.

봉투에 적힌 주소

익숙한 인터넷 이야기는 패킷이 어디로 가야 하는지를 식별하는 주소에서 시작한다. RFC 1546은 다른 질문에서 출발했다. 사용자가 서비스가 필요하지만 그룹의 어느 구성원이 그것을 제공하는지는 신경 쓰지 않는다고 가정해 보자. 사용자는 먼저 특정 호스트를 찾아야 하는가, 아니면 인터네트워크가 서비스에 대한 주소를 받아 적절한 서버를 선택할 수 있는가?

Craig Partridge, Trevor Mendez, Walter Milliken이 1993년 11월에 그 답을 발표했다. 이 메모는 Informational 문서로, IRTF에서 시작되었고 인터넷 표준이 아니라 실험적 서비스를 기술했다. 이 지위는 중요하다. 그것은 하나의 아키텍처 제안과 그 의미론을 기록하는 것이며, 보편적 구현, 운영 성공 또는 특정 네트워크의 배포를 증명하지 않는다.

제안된 목표는 의도적으로 한정되어 있었다. 애니캐스트 주소를 수용하는 호스트 중 최소 하나, 바람직하게는 단 하나에 데이터그램을 전달하는 것이다. “바람직하게는”이라는 표현에 이 역사의 많은 부분이 담겨 있다. 일반적인 IP는 데이터그램을 복제하거나 잘못 라우팅할 수 있다. 이 서비스는 한 명의 수신자를 지향할 수 있지만, 그 지향을 정확히 한 번의 수신으로 만들지는 않았다.

이것은 좁은 공통 계약이었다. 그 주소는 사실상 “이 서비스의 수용 가능한 제공자 하나”를 말했다. 어느 기계가 패킷을 수신할지, 그 기계가 어떤 데이터를 보유하는지, 그것이 정상인지, 그리고 그것이 서비스를 대변할 자격이 있는지는 말하지 않았다. 라우팅은 선택을 제공했지, 신원을 제공하지 않았다.

두 번째 데이터그램이 환상을 깬다

RFC 1546은 간단한 순서로 이 추상을 시험했다. 애니캐스트 주소로 보낸 첫 번째 데이터그램은 서버 X에 도달할 수 있다. 동일한 목적지를 가진 두 번째 데이터그램은 다시 X에 도달할 수도, 서버 Y에 도달할 수도 있다. IP는 X가 이전에 선택되었다는 기억을 갖지 않는다.

이 예는 근처 복제본의 지도보다 훨씬 많은 것을 보여준다. 그것은 일정하게 남는 레이블과, 패킷 사이에서 변할 수 있는 관계를 분리한다. 애플리케이션이 요청 사이에 상태를 가지고 들고 가는 순간, 이 구분은 운영 문제가 된다. X가 저장한 챌린지는 응답이 Y에 도달하면 아무 소용이 없다. 한 복제본이 부분적으로 기록한 트랜잭션이 다른 복제본에도 존재한다고 가정할 수 없다. 멱등하지 않은 재시도는 첫 결과가 실제로 부재한 것이 아니라 단지 보이지 않았던 경우 효과를 두 번 만들어낼 수 있다.

패킷 경로는 단일 전달을 보장하지도 않는다. 데이터그램이 둘 이상의 서버에 도달할 수 있다면, “요청을 하나 보냈다”는 말은 하나의 서버가 한 번 작동했다는 근거가 아니다. 따라서 주소는 근거 사슬의 한 항목일 뿐이며, 전달·친화성·효과를 압축한 증명이 아니다.

TCP는 지시 대상을 바꿔야 했다

연결 지향 전송은 같은 문제를 날카롭게 드러냈다. RFC 1546은 애니캐스트 주소가 ACK 없는 초기 TCP SYN에 한해서만 원격 주소로 허용될 수 있다고 제안했다. 서버가 자신의 유니캐스트 주소에서 SYN-ACK로 응답하면, 발기자는 애니캐스트 피어를 그 유니캐스트 주소로 교체한다. 대화는 임의의 적절한 서비스 인스턴스를 요청하는 것으로 시작해, 하나의 호스트를 지시하는 것으로 이어진다.

이 우아함은 전환에 있다. 첫 주소는 발견을 수행하고, 응답이 더 구체적인 지시 대상을 확립한다. 연속성은 애니캐스트 주소가 호스트 식별자가 되었기 때문에 생기는 것이 아니다. 연결이 그것을 그런 것으로 더 이상 사용하지 않기 때문에 생긴다.

역사적 원문은 이 특수 동작이 보편적으로 구현되었음을 확립하지 않는다. 이후 RFC 7094의 분석은 그것을 원래 제안으로 기술하면서 더 넓은 전송 계층 위험도 짚었다. 라우팅이 진행 중인 트랜잭션의 패킷을 트랜잭션 상태가 없는 종단 시스템으로 옮긴다면 세션이 리셋될 수 있다. 경로가 안정적으로 유지되는 실험실 토폴로지가, 서로 다른 글로벌 라우팅 조건에서도 동일한 애플리케이션이 친화성을 유지할 것이라는 근거는 아니다.

RFC 1546은 UDP나 복수의 TCP 연결을 사용하는 애플리케이션에도 비슷한 조언을 주었다. 이후 교환이 동일한 피어를 필요로 한다면, 애플리케이션은 첫 교환에서 유니캐스트 주소를 학습할 수 있다. 이 설계 역시 서비스 주소에 대한 믿음이 아니라 명시적인 인스턴스 참조를 통해 연속성을 얻었다.

로케이터, 노드, 그리고 응답하는 인스턴스

RFC 2101은 이후 이 구분을 식별자와 로케이터의 언어로 옮겼다. 애니캐스트 주소는 기능적으로 동등한 그룹의 한 구성원을 위치시킬 수 있지만, 호스트를 고유하게 식별할 수는 없다. 그 유용한 시간적 고유성은 TCP 연결을 확립하는 데 필요한 시간보다 짧을 수 있다.

이후 운영 관행은 “애니캐스트 서버” 뒤에 숨어 있던 각각의 것에 이름을 붙여야 했다. RFC 4786은 공유 IP를 서비스 주소(Service Address)라고 불렀다. 애니캐스트 노드(Anycast Node)는 그것에 대한 경로를 제시하는, 개별 위치에 있는 하나 이상의 호스트와 라우터였다. 캐처먼트(catchment)는 특정 조건에서 라우팅이 어떤 노드로 보낼 트래픽의 출발지 범위를 기술했다. 이 개체들은 서로 관련은 있지만 서로 교환 가능한 것은 아니었다.

라우팅 시스템은 토폴로지와 요청의 출발지를 이용해 경로를 선택했다. 그것은 지리적 근접성, 최저 지연 또는 서비스 품질을 인증하지 않았다. 동일 비용 포워딩은 하나의 트랜잭션에 속한 패킷을 서로 다른 노드로 이어지는 경로들에 흩어놓을 수도 있었다. 안정된 목적지 필드는 계속 보이는 반면, 상태를 갖는 서비스에 필요한 배치성은 사라질 수 있었다.

건강 상태는 또 하나의 독립된 계층이었다. RFC 4786은 실용적인 범위에서 서비스 건강과 경로 광고 사이의 긴밀한 결합을 바람직하다고 기술했다. 그러나 광고된 경로 자체가 애플리케이션이 올바른 데이터를 제공하고 있음을 증명하지는 않는다. RFC 3258의 공유 유니캐스트 DNS 지침은 이 절충을 보여준다. 운영자는 존 배포와 스위치오버를 조율해야 했고, 나쁜 데이터를 받은 서버는 응답을 멈춰야 했다. 그러나 하나의 DNS 프로세스가 실패할 때마다 경로를 철회하는 것은 거기서 일반적으로 권장되지 않았다. 신뢰할 수 있는 결합은 복잡성을 더했고, DNS는 다른 주소들 사이에서 페일오버할 수 있었기 때문이다. 도달 가능성, 프로세스 건강, 복제본 정확성은 운영자가 정렬하려 노력하더라도 별개의 제어였다.

나중에 찍은 프로브는 다른 영수증이다

애니캐스트는 전달만이 아니라 관찰도 복잡하게 만든다. RFC 4892는 ping, TCP 연결, traceroute 또는 나중의 DNS 질의가 조사 대상인 요청에 응답한 DNS 서버에 도달하지 않을 수 있음을 지적했다. 이후에 수행된 진단은 그 이후 시점의 네트워크를 기술할 수는 있지만, 이전의 응답자를 식별해 주지는 않는다.

RFC 5001은 이 더 좁은 필요를 EDNS 네임서버 식별자(Name Server Identifier) 옵션으로 다루었다. 리졸버는 불투명한 값을 요청할 수 있고, 서버는 자신이 선택한 식별자를 같은 DNS 응답 안에 담을 수 있다. 인스턴스 근거가 검토 중인 응답과 함께 이동하므로 귀속이 개선된다. 그 권한의 범위는 여전히 한정된다. NSID는 서버가 정의하며 전이적이지 않다. 그것은 운영자를 인증하거나, 위치를 확립하거나, 데이터셋을 보증하거나, 다운스트림에서 무슨 일이 있었는지 증명하지 않는다.

가장 방어 가능한 기록은 따라서 여러 영수증을 보존한다. 구성된 서비스 주소, 출발지가 본 경로, 특정 시점에 관찰된 응답, 가능한 경우 응답에 담긴 인스턴스 식별자, 전송 결과, 데이터 버전 또는 검증 결과, 인증 근거, 그리고 애플리케이션의 외부에서 관찰 가능한 효과. 이 구분들을 생략하면 페일오버가 연속성처럼 보이고, 로케이터가 책임 있는 신원처럼 보이게 만든다.

보안 경고는 처음부터 있었다

RFC 1546은 애니캐스트 집합의 구성원 자격을 스스로 인증되는 것으로 보지 않았다. 악의적인 호스트가 그 주소를 서비스하겠다고 자원하여 트래픽을 돌릴 수 있고, 엿듣는 자가 부정확한 정보로 응답할 수 있다고 경고했다. 라우팅 또는 로컬 전달 메커니즘은 응답자를 선택할 수 있으면서도 그 응답자의 권한을 증명하지 못할 수 있다.

이것이 인프라 자동화가 여전히 필요로 하는 경계다. 경로는 패킷이 어디로 갈지 선택할 수 있다. 그 사실 자체만으로 프로세스를 승인하거나, 복제본 상태를 증명하거나, 애플리케이션 결과가 성공적이라고 선언할 수는 없다. 그러한 주장에는 각자의 메커니즘이 필요하다. 인증된 프로토콜, 서명된 데이터, 일관성 제어, 트랜잭션 식별자, 로그, 독립된 관찰.

RFC 7094는 이 실용적 결과를 보존했다. 애플리케이션은 동일한 애니캐스트 목적지로 보낸 패킷이 서로 다른 인스턴스에 도달할 수 있다고 가정해야 한다. 가장 안전한 패턴은 상태 없는 전송 위에서의 자립적인 단일 패킷 요청, 유니캐스트 출발지로의 응답, 요청 사이의 서버 하드 상태 없음, 그리고 멱등한 재시도이다. 복수 패킷 호출이 필요하다면, 하나의 애니캐스트 교환으로 유니캐스트 인스턴스를 발견할 수 있다. 공유 주소는 선택을 시작할 뿐, 귀속을 마무리하지 않는다.

1993년 메모가 실제로 바꾼 것

RFC 7094는 이후 RFC 1546을 애니캐스트의 첫 공식 명세라고 부르며, 그 저자들이 이후에도 지속된 문제 대부분을 포착했다고 평가했다. 성취는 하나의 마법 주소가 항상 가장 빠르고, 가장 안전하고, 가장 건강한 복제본을 찾아줄 것이라는 약속이 아니었다. 그것은 신중한 최소 명세였다. 여러 구현이 서비스 수준 주소 지정을 중심으로 조율하는 동안, 전송과 애플리케이션이 연속성에 대한 책임을 유지하는 구조였다.

이 경제성은 로컬 라우팅 시스템, 서버 설계, 배포 모델에 여지를 만들었다. 동시에 근거 부담을 보이게 만들었다. 서비스 주소는 동일하게 유지될 수 있지만, 선택된 경로, 노드, 프로세스, 데이터셋, 운영자는 바뀔 수 있다. 역사적 기록은 그 아키텍처와 그 경고를 증명한다. 그것은 특정 배포, 취약점, 장애, 채택률, 제안된 TCP 전환의 보편적 사용 또는 정량화된 사용자 영향을 증명하지 않는다.

지속되는 통찰은 거의 문법적이다. “이 패킷은 동일한 주소로 보내졌다”와 “이 패킷은 동일한 서버에 도달했다”는 서로 다른 문장이다. RFC 1546은 첫 문장이 참으로 남아 있는 동안, 두 번째 문장이 다른 영수증 없이는 알 수 없게 만들 수 있음을 가능하게 했다.

출처