요약

  • RFC 1913은 Whois++ 서버가 압축된 '포워드 지식(forward knowledge)'을 광고할 수 있게 했다. 즉, 하위 서버에 매칭 레코드가 있을 수 있음을 나타내는 중복 제거 토큰이다. 이 요약은 쿼리 라우팅을 지원했을 뿐, 레코드 수준의 증거가 아니었다.
  • 복수의 색인 경로는 하나의 계층에 대한 의존을 줄였지만, 클라이언트가 탐색해야 하는 그래프를 만들었다. 신선도, 루프 제어, 엔드포인트 복구, 검색 팬아웃 및 발생 가능한 과금은 여전히 별도의 책임이었다.
  • 이 아이디어는 이후 Common Indexing Protocol로 일반화되었고, Whois++ 자체는 2006년 IETF 검토에서 '정의되었으나 사용되지 않음'으로 평가된 뒤 Historic으로 이동했다.

유용한 소실

RFC 1913의 작은 예시는 네트워크 다이어그램보다 더 많은 것을 드러낸다. 세 개의 레코드에 두 명의 사용자, 하나의 도메인과 몇몇 필드가 담겨 있다. 이들의 센트로이드(centroid)는 각 템플릿 이름, 각 속성 이름과 해당 속성 아래에서 발견된 모든 단어를 한 번씩 유지한다. "Smith"는 한 레코드에 속했든 천 개의 레코드에 속했든 요약에는 한 번만 나타난다. "Beer", "Labatt", "Molson"은 독립적인 토큰으로 남지만, 두 단어가 한 필드 값을 공유했다는 사실은 사라진다.

이것은 손상된 데이터베이스가 아니다. 의도적으로 축소된 주장이다. 색인 서버가 하위 서버에 다음 쿼리를 보낼 가치가 있는지 판단하기 위해 모든 원본 레코드를 가질 필요는 없다. 도움이 될 수 없는 가지를 가지치기할 만큼의 포워드 지식만 있으면 된다.

이 구분이 중요한 이유는 모든 압축이 증거를 삭제하기 때문이다. 센트로이드는 매칭 레코드를 식별하지 않고, 매칭 수를 세지 않고, 문구 순서를 보존하지 않고, 누가 값을 제공했는지 설명하지 않으며, 쿼리 시점에 그 값이 여전히 존재한다고 보증하지 않았다. 매칭의 의미는 이렇다: 여기서 사용 가능한 색인 상태 하에서, 이 토큰이 어딘가 하위에서 이 템플릿과 속성에 나타났다. 다음 단계는 결론이 아니라 리퍼럴이었다.

레코드 위의 메시

더 광범위한RFC 1835 — Architecture of the WHOIS++ service(1995년 8월 발행)는 구형 WHOIS의 느슨하고 사람이 읽을 수 있는 레코드에서 벗어나려 했다. 유형이 지정된 템플릿과 구조화된 속성-값 쌍을 도입했다. 또한 채워진 템플릿을 보유하는 베이스 서버와 포워드 지식과 포인터를 보유하는 색인 서버를 분리했다. 하나의 물리적 기계가 두 역할을 모두 수행할 수 있었지만, 논리적 구분은 유지되었다.

이 구분은 확장 문제에 대한 답이었다. 단일 글로벌 디렉터리는 저장, 트래픽, 장애를 한곳에 집중시킨다. 경직된 계층 구조는 정보가 어디에 속하는지 알아야 발견이 가능하게 만들고, 상위 노드에 부담을 주며, 지리적 또는 행정적 가지를 가로지르는 '옐로우 페이지' 질문에 어려움을 겪는다. 알려진 서브트리의 이름 지정된 레코드가 아니라 서비스를 찾는 사용자에게는 다른 경로가 필요했다.

RFC 1913 — Architecture of the Whois++ Index Service(1996년 2월 발행)는 레코드 위에 메시(mesh)를 놓았다. 어떤 색인 서버든 베이스 서버나 다른 색인 서버의 센트로이드를 수집하고 결합할 수 있었다. 하나의 서버는 둘 이상의 계층 구조에서 색인될 수 있었다. 지리적, 행정적 또는 위상적 경로가 겹칠 수 있었다. 레코드 식별자가 더 이상 유일한 탐색 경로를 결정하지 않았다.

이것은 간접화(indirection)를 통한 분권화였다. 권위 있는 자료는 베이스 서버에 머물렀고, 메시는 힌트를 이동시켰다. 전문 색인은 특정 템플릿이나 필드를 선택할 수 있었다. 대안 부모는 도달성과 회복력을 개선할 수 있었다. 사용자는 검색 전에 레코드의 위치를 알 필요가 없었다.

그러나 어떤 새로운 경로도 목적지에 저장된 실체를 획득하지 않았다. 메시가 안내자로서 유용해질수록, 인식론적 경계를 명명하는 것이 더 중요해졌다. 즉, 안내자는 다른 서버가 물어볼 가치가 있을 수 있는 이유를 알 뿐이다.

여러 개의 시계를 건너는 변경

포워드 지식은 유지보수 없이는 유용할 수 없었다. RFC 1913은 인증된 폴링을 명세했다. 폴러는 전체 센트로이드 또는 선택된 템플릿과 필드에 대한 변경 사항을 요청할 수 있었다. 폴링 대상 서버는 자신의 센트로이드가 변경되었음을 알리기 위해DATA-CHANGED를 보낼 수도 있었다. 수신자는 폴링할지 여부와 시점을 결정했다.

이 순서에는 여러 다른 사건이 포함되어 있었다: 베이스 레코드가 변경됨; 그 센트로이드가 변경됨; 통지가 전송됨; 통지가 수락됨; 폴링이 수행됨; 변경 보고서가 인증됨; 색인이 이를 반영함; 그리고 상위 색인이 나중에 새 상태를 학습함. 프로토콜의 응답 코드 227은 이 경계를 명시했다. 즉, 변경 전송이 수락되어 후속 조치를 위해 기록되었음을 의미했다. 모든 색인이 변경 사항을 적용하거나 전파했음을 의미하지는 않았다.

이것은 두 가지 대칭적 위험을 만든다. 오래된 긍정 지식은 매칭 토큰이 사라진 서버로 클라이언트를 보낼 수 있다. 누락되거나 지연된 신규 지식은 이제 매칭을 보유한 서버를 가지치기할 수 있다. RFC들은 어느 쪽 실패율도 정량화하지 않으며, 이 아키텍처는 그것이 제공한다고 주장한 적 없는 증거를 이유로 비난받아서는 안 된다. 운영상의 교훈은 더 좁다: 색인 타임스탬프나 업데이트 접수증은 종단간 신선도 증명을 대신할 수 없다.

클라이언트가 그래프를 물려받았다

메시는 다이어그램에서 계층적처럼 보였지만 트리가 아니었다. 동일한 서버가 복수의 부모를 가질 수 있었다. 이것은 대안 경로를 가능하게 했고, 순환을 명시적 제어가 필요할 만큼 불가피하게 만들었다. RFC 1913은 폴링 관계에 대한 홉 카운트를 제안했으며, 해당 버전에서는 최대 8로 제한했다. 쿼리 리퍼럴에 대해서는 두 번째 접근 방식을 제시했다. 클라이언트가 자신이 이미 방문한 곳을 기억하게 하는 것이다.

RFC 1914 — How to Interact with a Whois++ Mesh는 이 클라이언트 책임을 구체화했다. 클라이언트는 연결을 열고, 쿼리를 발행하고, 레코드와 리퍼럴을 수신하고, 연결을 닫은 후, 다음에 접촉할 리퍼럴 서버를 선택했다. 이 알고리즘은 이미 쿼리된 서버 집합을 유지했고, 누가 누구를 폴링하는지 물어봄으로써 외부로 확장할 수 있었다.

시작점은 여전히 중요했다. 로컬 서버는 자신이 아는 메시의 일부만 노출했다. 확장은 더 넓은 시야에 도달할 수 있었지만, 무료도 아니고 자동으로 현명하지도 않았다. RFC 1914는 맹목적 확장이 지수적으로 증가하는 자원 비용을 만들 수 있다고 경고했다. 메시의 일부는 응답에 요금을 부과할 수 있었다. 따라서 클라이언트는 비용이 많이 드는 서버를 블랙리스트에 넣거나, 가지를 거부하거나, 사용자가 검색을 중단하도록 할 수 있었다.

완전성은 더 이상 하나의 응답의 속성이 아니었다. 그것은 초기 서버, 이용 가능한 리퍼럴, 루프 감지, 확장 규칙, 시간, 예산, 블랙리스트, 그리고 각 대상의 지속적 가용성에 의존했다. 프로토콜은 도달 가능한 메시에서 모든 레코드를 찾는 알고리즘을 기술할 수 있었지만, 실무에서 '도달 가능'과 '추적할 가치가 있음'이 무엇을 의미하는지는 운영자가 선택했다.

위치 힌트는 쿼리가 도착하기 전에 늙을 수 있었다

RFC 1914는 더 소박한 실패도 노출했다. 리퍼럴의 호스트명, IP 주소, 포트는 마지막 폴링 이후, 아마도 수 주 전부터 캐시되어 있었을 수 있다. 접속 실패가 반드시 서버 식별자의 소멸을 의미하지는 않았다. 클라이언트는 안정적인 서버 핸들을 서버 디렉터리(Directory of Servers)에 가져가 최신 알려진 엔드포인트를 물을 수 있었다.

그것은 식별자를 위치로부터 분리하는 합리적 설계였다. 모든 캐시된 리퍼럴이 최신 상태를 유지하도록 요구하지 않고도 이동성을 지원했다. 그러나 '최신 알려진'에도 한계가 있었다. 두 번째 조회는 더 새로운 호스트를 반환하면서도 여전히 실패할 수 있었다. RFC 1913은 도달 불가능한 원하는 서버와 서비스가 이용 불가능한 도달 가능한 호스트를 구분했다. 핸들은 하나의 낡은 포인터를 복구할 수 있었지만, 살아있는 프로세스를 만들어낼 수는 없었다.

보안 경계 역시 마찬가지로 불완전했다. RFC 1913은 이 메모에서 보안 문제를 다루지 않는다고 밝혔다. RFC 1914는 가짜 Whois++ 서버가 나타날 수 있으므로 클라이언트가 블랙리스트를 지원하라고 했다. 이 진술들은 관찰된 공격의 역사가 아니라 설계상 한계를 문서화한 것이다. 그럼에도 리퍼럴이 결정 지점이었음을 보여준다. 포인터를 따르는 것은 클라이언트를 다른 행정 도메인, 그리고 자신이 제공하는 데이터에 대한 또 다른 주장에 노출시켰다.

아이디어는 제품을 떠났다

1999년 8월,RFC 2651 — The Architecture of the Common Indexing Protocol은 CIP를 Whois++가 도입한 분산 색인 아이디어의 진화이자 정제로 기술했다. CIP는 디렉터리 프로토콜에서 색인 전달을 추출하고, 가능한 색인 개체를 일반화했으며, 교환되는 자료를 쿼리 라우팅에 사용되는 힌트라고 불렀다. 클라이언트는 실제 결과를 얻기 위해 여전히 네이티브 데이터 접근 프로토콜이 필요했다.

이 계보는 중요하다. 하나의 프로토콜은 지속 가능한 공개 서비스가 되지 못하면서도, 그 구분 중 하나는 살아남을 수 있다. Whois++는 특정 센트로이드를 템플릿 기반 디렉터리와 결합했다. CIP는 재사용 가능한 메커니즘을 보존하려 했다. 서버들이 압축된 지식을 교환함으로써 이후의 쿼리가 데이터 보유 가능성이 높은 쪽으로 향하도록 하는 것이다.

퇴역 기록 역시 마찬가지로 정확하다.RFC 4450 — Getting Rid of the Cruft(2006년 3월 발행)는 구형 Proposed Standard에 대한 보수적 검토를 보고했다. 이 문서는 RFC 1835, 1913, 1914를 Historic으로 이동할 집합에 넣고, Whois++를 '정의되었으나 사용되지 않음' 프로토콜로 명명했다. 이것은 실험이나 소프트웨어를 지우지는 않는다. 이후 CIP RFC 자체가 Digger를 언급한다. 이것은 IETF 검토가 이 표준들이 더 이상 Proposed Standard로서 유지할 가치가 있는 현재 문서화된 실무를 대표하지 않는다고 판단했음을 기록한 것이다.

따라서 역사적 결과는 중앙화가 분권화를 물리쳤다는 도덕극이 아니다. 메시는 실재하는 발견 문제를 해결했고, 그 추상화는 계속되었다. 사라지지 않은 것은 힌트와 사실 사이의 모든 전달에 드는 비용이었다.

출처

  • RFC 1835, RFC 1913, RFC 1914, RFC 2651, RFC 4450은 위 분석에서 한 번씩 링크되어 있다.