요약

  • RFC 1498은 서비스 또는 사용자, 노드, 네트워크 연결 지점, 경로라는 네 가지 이름 붙은 대상을 구분하고, 서비스에 도달하기 위해 필요한 세 단계의 연속적인 바인딩을 설명했다.
  • Lockheed DIALOG 서비스가 노드 5에서 실행된다는 테이블 행은 하나의 변경 가능한 서비스-노드 관계를 표현했다. 그 행을 편집해 서비스를 노드 6으로 옮길 수는 있었지만, 서비스나 노드의 이름을 바꾸지는 않았다.
  • 따라서 리졸버의 답이나 주소는 더 긴 체인 안의 현재 바인딩에 대한 증거일 뿐이다. 인증, 권한, 경로 가용성, 전달, 응용 결과는 각자 고유의 영수증을 요구한다.

이름은 그대로 둔 채 바뀐 행

단순한 한 문장을 담은 네트워크 테이블을 상상해 보자. Lockheed DIALOG 서비스가 노드 5에서 실행 중이다. 이후 운영자가 그 행을 편집해 DIALOG가 노드 6에서 실행되도록 바꾼다. 무엇이 바뀌었는가?

“Lockheed DIALOG 서비스”의 의미는 바뀌지 않았다. 그 이름은 특정 서비스, 그 관리, 그 저장된 자료와 계속 연결되어 있었다. 노드 5나 노드 6의 신원도 바뀌지 않았다. 테이블이 바꾼 것은 서비스와 노드 사이의 현재 연결뿐이었다.

바로 이 구분이RFC 1498, 즉 Jerome Saltzer의On the Naming and Binding of Network Destinations에서 가장 많은 것을 말해주는 대목이다. 1993년 8월에 Informational RFC로 발표된 이 논문은 처음에 1982년 지역 컴퓨터 네트워크 단행본에 실렸었다. 논문의 나이 자체가 핵심의 일부다. 오늘날의 서비스 디스커버리, 클라우드 스케줄링, 모바일 네트워킹이 지금의 이름을 갖기 전에 이미 개념적 오류는 드러나 있었다. 무언가가 어디서 실행되고 있다는 기록을 마치 그 기록이 그 대상이 무엇인지를 재정의할 수 있는 것처럼 다루는 오류였다.

Saltzer는 실제 이름 변경이 더 어려운 이유를 설명했다. 서비스 이름과 서비스 사이의 연결은 그 편리한 테이블 하나에만 담겨 있지 않았다. 프로그램, 문서, 손으로 적은 메모, 광고에도 살아 있었다. 서비스-노드 행을 바꾸는 것은 실행 위치를 옮긴다. 서비스의 이름을 바꾸려면 훨씬 넓은 참조의 세계를 바꿔야 한다.

테이블은 강력했지만, 자신의 계층 안에서만 그러했다.

익숙한 세 단어보다 앞선 네 가지 대상

네트워크 어휘는 흔히 간결한 세 항목으로 시작했다. 이름은 무엇이 원하는지 말하고, 주소는 그것이 어디 있는지 말하고, 경로는 어떻게 도달하는지 말한다. RFC 1498은 이 정식화를 거부하지 않았다. 다만 세 개의 꼬리표는 너무 많은 해석의 여지를 남긴다고 주장했다.

대신 논문은 대상에서 출발했다. 첫째는 서비스와 사용자였다. 시각, 회계, 패킷 포워딩 같은 기능과 그것을 사용하는 클라이언트다. 둘째는 노드였다. 서비스나 사용자 프로그램을 실행하는 컴퓨터다. 셋째는 네트워크 연결 지점이었다. 노드가 네트워크에 연결되는 포트나 장소다. 넷째는 경로였다. 연결 지점 사이에서 링크와 포워딩 노드를 지나는 진행 경로다.

이 목록은 흔한 문장을 덜 무해하게 만든다. “서비스의 주소”는 현재 그 서비스를 실행 중인 노드, 현재 그 노드에 도달하는 연결 지점, 또는 경로를 선택하는 데 쓰이는 값을 가리킬 수 있다. 화자가 대상과 바인딩 맥락을 밝히지 않으면주소라는 단어 하나에 여러 주장이 한 음절 안에 압축된다.

RFC 1498은 표기 형식에서 대상 유형을 읽어내는 것도 경계했다. 인쇄 가능한 문자열이 본질적으로 서비스 이름인 것은 아니다. 이진 값이 본질적으로 노드 이름인 것도 아니다. 계층적 형식이 본질적으로 연결 지점의 이름인 것도 아니다. 네 가지 대상 유형은 어떤 유용한 형식으로든 이름을 가질 수 있고, 하나의 대상이 여러 형식의 이름을 가질 수도 있다.

의미의 질문은 글자보다 앞선다. 이 값은 어떤 대상을 이름 짓는가, 그리고 그 바인딩은 어떤 맥락에서 유지되는가?

서비스에 도달하는 것은 세 단계의 탐색이었다

대상이 구분되면 이동을 설명하기가 쉬워진다. 서비스는 하나 이상의 노드에서 실행되며 노드들 사이를 옮겨도 자신의 신원을 잃지 않는다. 노드는 하나 이상의 연결 지점을 사용하며 그들 사이를 옮겨도 다른 노드가 되지 않는다. 한 쌍의 연결 지점 사이의 경로는 양쪽 끝점을 바꾸지 않은 채 변할 수 있다.

따라서 서비스로 패킷을 보내려면 이 모델은 세 번의 연속적인 탐색이 필요하다.

  1. 서비스가 동작하는 노드를 찾는다;
  2. 그 노드에 도달할 수 있는 연결 지점을 찾는다;
  3. 발신자의 연결 지점에서 선택된 목적지 연결 지점까지의 경로를 찾는다.

RFC 1498은 대응하는 기능들을 서비스 이름 해석, 노드 이름 위치 파악, 경로 서비스라고 불렀다. 하나의 기계가 둘 이상을 수행하더라도 개념적으로는 서로 구분된다.

각 단계가 반드시 단 하나의 답을 내야 하는 것도 아니다. 여러 노드가 서비스를 실행할 수 있다. 노드는 멀티홈드일 수 있다. 하나의 연결 지점에 여러 경로가 도달할 수 있다. 경로 품질이 어느 노드가 더 나은지에 영향을 줄 수 있으므로 서로 다른 수준에서의 선택은 상호작용할 수 있다. 테이블은 목록이나 부분 바인딩을 반환할 수 있고, 최종 선택은 마지막 순간까지 미뤄진 뒤 네트워크의 바인딩 서비스 바깥에 기록될 수 있다.

이것은 관찰된 하나의 답의 증거 가치에 대한 결정적 한계다. 반환된 연결 지점은 어떤 상태와 질의 아래에서 리졸버가 그 후보를 제공했다는 것만 증명한다. 다른 후보가 존재하지 않았다는 것, 어떤 정책이 그것을 선택했는지, 경로가 계속 사용 가능했는지, 응용이 그 결과 통신을 받아들였는지는 증명하지 않는다.

이더넷은 두 이름을 융합해 테이블을 줄였다

논문은 이 모델을 이더넷에 적용해 검증했다. 노드는 48비트 식별자를 가질 수 있고, 이더넷을 따라 물리적으로 어디에 연결되든 그 값을 사용할 수 있었다. 그 값은 노드가 제공하기 때문에 노드 이름으로, 또는 인터페이스가 네트워크에서 그것을 지켜보기 때문에 연결 지점 이름으로 합리적으로 해석될 수 있었다.

바인딩 관점에서 이 설계는 노드 이름과 연결 지점 이름을 같은 값으로 만들었다. 그 영구적인 연결에는 실용적 이점이 있었다. 노드는 네트워크 기록 변경 없이 이동할 수 있었다. 바인딩 테이블의 한 계층이 사라졌다. 멀티홈드 노드는 서로 다른 이더넷에서 같은 식별자를 제시할 수 있어 대체 경로 탐색이 단순해졌다.

그러나 이 단순화는 표현력을 소모했다. 하나의 노드가 같은 이더넷에서 독립적으로 주소 지정 가능한 두 연결을 필요로 하면, 두 식별자는 다른 기록들이 노드가 둘 있다고 믿게 만들 수 있었다. 하나의 식별자를 재사용하면 그 착시는 피할 수 있지만, 발신자가 특정 연결 하나를 선택하는 것은 불가능해졌다.

여기서 이 융합이 실수였다는 것을 증명하는 것은 없다. RFC 1498은 그 환경에서는 이점이 더 크리라고 판단했다. 교훈은 더 좁다. 테이블을 제거하는 것이 그 테이블이 관계 지었을 대상을 없애는 것은 아니다. 그것은 하나의 바인딩을 고정하고 그 결과의 트레이드오프를 물려받는다.

친근한 ARPANET 이름은 보이는 것보다 낮은 곳을 가리켰다

ARPANET NCP 사례는 정반대의 문제를 드러냈다.RADC-Multics같은 문자열은 노드 또는 서비스 이름처럼 보였다. 논문의 분석에 따르면 그것들은 실제로 네트워크 연결 지점, 이 경우 ARPANET IMP 포트의 이름이었다.

노드가 이동할 때 이 배치가 문제가 되었다. 컴퓨터를 다른 포트에 다시 연결하면 사용자가 새 눈에 보이는 이름을 익혀야 하거나, 다른 노드들에 걸친 테이블이 바뀌어야 할 수 있었다. 병렬 연결은 또 하나의 문자열 신원을 요구했다. 연상 기호의 친근함은 사람들이 그것을 서비스에 귀속시키도록 유도했지만, 운영 네임스페이스는 체인에서 더 낮은 곳에 끝나 있었다.

메일은 이 불일치를 드러냈다. 여러 컴퓨터가 서로의 메일을 수신할 수 있었다. 사용자가 익숙한 문자열이 지목하는 노드가 다운되면, 같은 기능을 다른 곳에서 찾기 위해 겉보기에 다른 서비스 이름을 요청해야 할 수 있었다. 서비스에는 중복이 있었지만, 이름은 서비스 계층에서 그것을 표현하지 않았다.

꼬리표는 기억에 남으면서도, 사용자가 내리려는 결정에 대해 틀린 대상을 이름 지을 수 있다.

하나의 답은 두 개의 바인딩을 숨길 수 있었다

구현은 모델을 압축할 수 있다. 이름 서버는 서비스 이름을 받아 연결 지점 목록을 반환할 수 있다. 기계적으로 하나의 요청이 서비스-노드 해석과 노드-연결 지점 위치 파악을 모두 수행한 것이다. 이후 분산 라우팅 알고리즘이 눈에 보이는 세 번째 서비스로 자신을 드러내지 않으면서 경로를 선택할 수 있다.

이 압축은 유용하다. 그러나 중간 관계들이 소멸했다는 증거는 아니다. 결과가 틀리거나 낡았을 때 진단은 여전히 어느 연결이 실패했는지 묻는다. 서비스가 더 이상 그 노드에 없었는지, 노드가 그 연결 지점을 떠났는지, 아니면 경로가 사라졌는지?

이후 인터넷 문서들은 같은 압박을 새로운 맥락에 실어 날랐다.RFC 1958은 응용이 하드코딩된 주소 대신 이름을 사용하도록 조언하고 모듈식 분리를 아키텍처적 미덕으로 다뤘다.RFC 2101은 IPv4 식별자 요구사항과 로케이터 요구사항을 구분하고, 같은 주소 필드를 함께 쓰는 것은 역사적 우연이라고 명시했다.RFC 2956은 노드 신원과 전달 위치가 뒤섞인 채 남을 때 생기는 문제들을 기록했다. 이 문서들은 RFC 1498을 개정하지 않는다. 같은 압축이 얼마나 오래 세심한 해석을 요구했는지를 보여준다.

경로는 결과 앞에서 멈췄다

Saltzer는주소에 대한 폭넓은 독해를 제시했다. 서비스의 주소는 그것을 실행하는 노드의 이름일 수 있고, 노드의 주소는 연결 지점의 이름일 수 있고, 그 연결 지점의 주소는 경로의 이름일 수 있다. 서비스로의 경로는 또한 소켓처럼 노드 내부의 관련 활동을 식별해야 한다.

이렇게 더 완전한 경로조차 전달 영수증은 아니다. 서비스가 수신 대기 중이었는지, 상대가 진짜였는지, 정책이 교환을 승인했는지, 응답이 도착했는지, 비즈니스 조치가 완료되었는지 말해 주지 않는다. RFC 1498은 보안 문제는 논하지 않는다고 명시한다.

그러므로 신뢰할 수 있는 기록은 체인을 열어 둔 채 유지해야 한다. 정확한 서비스 이름과 네임스페이스, 리졸버 질의와 시각, 반환된 모든 노드, 노드-연결 지점 상태, 후보 및 선택된 경로, 활동 또는 소켓 식별자, 전송 기록, 응용 응답, 그리고 각 선택을 내린 행위자. 하나의 주소를 찍은 스크린샷은 이 영수증들을 대신할 수 없다.

Lu Heng의running-code primacy,localized future decision,reality layers에 대한 논의는 제도적 경계를 더 선명하게 한다. 조율 테이블은 상호운용 가능한 조치를 가능하게 할 수 있다. 그러나 그것이 서비스, 운영자, 실행 중인 경로, 그리고 그들에 대한 상설 위임이 되는 것은 아니다. 기록은 그것이 실제로 실행하는 가장 낮은 계층에서 해석되어야 한다.

RFC 1498이 남긴 지속적인 기여는주소의 또 다른 선호 정의가 아니었다. 거짓 압축을 거절하는 방법, 즉 대상의 이름을 밝히고, 바인딩을 노출하고, 변경 가능한 모든 경계에서 영수증을 요구하는 방법이었다.

출처