요약

  • RFC 814는 인터넷 호스트 내부의 번역 사슬을 기술했다. 사람이 읽는 이름은 주소에 대응하고, 주소는 경로에 대응하며, 서비스 이름은 전송 계층별 포트 식별자에 대응한다. 각 참조는 서로 다른 질문에 답했다.
  • 성장으로 전체 표를 유지하는 방식은 감당할 수 없게 되었다. Clark은 분산형 이름 서비스, 사용 규모에 맞는 캐시, 교체 가능한 인터페이스를 권고하면서, 하나의 전역 메커니즘을 강제하는 대신 초기 게이트웨이 발견은 로컬 네트워크에 맡길 것을 제안했다.
  • 분리는 권한의 경계를 만들었다. 이름 조회가 경로를 증명하지 않고, 주소가 프로세스를 선택하지 않으며, 등록된 포트가 트래픽을 인증하지 않는다. 이후 DNS 설계는 네트워크 식별자, 주소, 경로를 필수 이름 구문에서 배제함으로써 이 원칙을 지켰다.

잘못된 기계가 올바르게 응답했다

RFC 814는 사람에게 영향을 미치는 구현 문제에서 출발했다. 호스트가 이전했지만 로컬 NIC 표 사본은 갱신되지 않았고, 연결은 이제 옛 주소를 차지한 어떤 기계든 향해 열렸다. 대화형 세션을 지켜보던 사람은 알아차릴 수 있었다. 대기 중 메일은 무인 상태로 진행되어 낡은 바인딩을 오해를 낳는 전달 이벤트로 바꿔놓았다.

이 예시가 중요한 이유는 모든 구성 요소가 설계대로 동작할 수 있기 때문이다. 이름 파서는 문자열을 받아들였다. 표는 문법적으로 유효한 주소를 반환했다. IP는 경로를 찾았고, TCP는 수신자에게 도달했다. 실패는 이 행위들 사이의 관계에 있었다. 매핑이 바뀐 뒤에는 주소로의 전달이 이름이 가리키는 대상으로의 전달이 아니었다.

따라서 David D. Clark의 1982년 7월 논문은 TCP/IP 참조를 하나의 연속으로 다루었다. 문자열은 네트워크, 호스트, 서비스를 이름짓는다. 호스트 이름은 32비트 인터넷 주소로 해석된다. 주소는 부착점과 위치를 식별한 뒤 경로 선택을 이끈다. 서비스 이름은 특정 전송 계층에서 포트를 고른다. 이 계층들을 하나로 뭉치면 한 단계에서의 성공 결과가 나머지 모든 단계를 대변하게 된다.

성장은 전체 표를 깨뜨렸다

Clark이 기술한 인터넷은 활성 네트워크가 대략 25개, 호스트는 수백 대 수준이었다. 그럼에도 그는 구현자들에게 훨씬 더 큰 시스템—작업 추정치 기준으로 약 1,000개 네트워크와 25,000개 호스트—을 대비하라고 경고했다.

모든 기계에 완전한 표를 두는 방식은 세 가지 이유로 실패했다. 표가 너무 커지고, 너무 자주 바뀌며, 대부분의 항목은 해당 호스트가 결코 사용하지 않는 것이었다. 제안된 대안은 분산된 책임이었다. 네트워크 또는 네트워크 그룹이 자신들의 이름을 관리하고, 이름 서버가 조회에 응답하며, 호스트는 최근에 사용한 바인딩만 유지한다.

가장 오래 남은 조언은 소프트웨어 경계에 관한 것이었다. 기존 표 접근은 코드 곳곳에 흩뿌리는 대신 서브루틴 뒤에 두어야 한다. 로컬 조회 구현은 나중에 모든 애플리케이션을 다시 쓰지 않고도 원격 이름 서비스 호출로 교체될 수 있다. 인터페이스는 질문을 보존하면서 답변 메커니즘의 변화를 허용한다.

이것이 실천적 형태의 최소 초기 명세였다. 공통 호출은 작게 유지하고, 변하는 메커니즘은 그 뒤에 지역화한다. 실행 코드는 애플리케이션에게 권위 있는 표가 어디에 사는지 강제하지 않으면서 HOSTS.TXT에서 분산 서비스로 이동할 수 있었다.

캐시는 나이를 가진 근거였다

분산은 불확실성을 없애지 못했다. RFC 814는 캐싱이 호스트 이전 문제를 악화시킬 수 있음을 보았다. 이전 답변을 들고 있는 기계가 이름 뒤의 주소가 바뀌었음을 자동으로 알지는 못한다. 이 문서는 외부 주소에 연관된 이름을 물어보는 방식을 검증 아이디어로 논의하면서도, 캐시를 영구적인 권위로 선언하는 대신 살아있는 매핑 문제로 인식했다.

이후 DNS는 만료를 명시적으로 만들었다. RFC 1034는 이름에 유형별 리소스 레코드를 연결하고, 책임을 여러 존에 분산하며, 갱신 트레이드오프를 데이터 출처가 통제하도록 했다. 그 1차 목표는 이름이 네트워크 식별자, 주소, 경로를 담을 필요가 없는 일관된 이름 공간이었다. 주소는 이름 자체에 내장된 필수 재료가 아니라 이름에 대해 얻을 수 있는 데이터가 되었다.

이 아키텍처는 연속성을 허용하지만 보장하지는 않는다. 도메인 이름은 별칭을 가질 수 있고, 만료될 수 있고, 잘못 위임될 수 있고, 독자가 기대하는 운영자가 아닌 누군가의 통제 아래 놓일 수 있다. DNS 답변은 진본이거나 위조되었을 수 있고, 신선하거나 낡았을 수 있으며, 도달 가능하거나 블랙홀에 빠졌을 수 있다. 분리는 좌표가 바뀌는 동안 참조를 보존할 여지를 만들지만, 참조를 신원이나 소유의 증명으로 바꾸지는 않는다.

주소에는 여전히 경로가 필요했다

조회 이후 IP는 또 하나의 번역에 직면했다. 목적지가 직접 연결된 네트워크에 속하면 호스트가 직접 보낼 수 있지만, 그렇지 않으면 게이트웨이가 필요했다. 초기 구현은 256개의 가능한 네트워크 번호 각각에 정적 항목을 하나씩 둔다고 상상할 수 있었지만, 이동과 장애, 확장된 주소 체계는 그 전수 모델마저 취약하게 만들었다.

RFC 814는 실제 사용 중인 목적지에 대한 경로 캐시를 제안했다. 항목이 없으면 호스트는 접근 가능한 게이트웨이를 시도할 수 있다. 더 나은 게이트웨이가 존재하면 ICMP Redirect가 더 좋은 다음 홉을 호스트에게 가르치고 캐시를 갱신할 수 있다. 따라서 경로 표는 두 번째 이름 표가 아니었다. 그것은 수명이 토폴로지와 활성 작업에 의존하는 운영상의 선택을 담았다.

초기 게이트웨이 발견은 의도적으로 로컬에 남겨졌다. 어떤 부착 네트워크는 브로드캐스트 발견을 지원할 수 있고, 다른 네트워크는 특수 설비를 제공할 수 있으며, 또 다른 네트워크는 설치자가 게이트웨이를 직접 입력해야 할 수 있다. 인터네트워크 아키텍처는 하나의 로컬 방법을 보편적 규칙으로 확대하지 않았다.

RFC 1122는 나중에 이 구분을 강화했다. 라우팅의 복잡성은 주로 게이트웨이에 속하고, 호스트는 라우팅 진화로부터 보호되어야 하며, 경로 캐시는 최대 데이터그램 크기나 측정된 지연 같은 경로 속성을 담을 수 있다. 이 속성들은 목적지의 인간 이름이 아니라 경로 epoch에 속했다.

포트는 주소의 일부가 아니었다

IP 주소는 데이터그램을 호스트로 전달할 뿐, 최종 에이전트로 직접 전달하지 않는다. IP는 상위 계층 프로토콜로 넘기고, TCP나 UDP가 포트 식별자를 사용해 프로세스, 수신자, 연결을 선택한다. RFC 814는 당대의 TCP와 UDP가 포트 필드를 같은 방식으로 배치함을 관찰하면서도 그 우연을 보편적 IP 기능으로 만들기를 거부했다.

아키텍처적 이유가 있었다. 다른 프로토콜은 다른 식별자 크기를 원할 수 있다. 잘 알려진 포트 할당은 프로토콜별로 정해진다. 무엇보다 IP는 게이트웨이가 이해해야 할 내용만 담도록 설계되었다. 애플리케이션 디스패치를 IP에 넣는다면 모든 게이트웨이가 포트 의미론을 이해해야 한다는 인상을 준다.

문서는 더 풍부한 대안도 검토했다. 문자열 서비스 기술자를 랑데부 서버로 보내면 서버가 해당 인스턴스의 포트를 고르는 방식이다. 이런 간접화는 연결 설정에는 적합했다. 하지만 단일 데이터그램 UDP 교환에 예비 왕복과 더 큰 필드라는 부담을 지웠다. RFC 814는 모든 서비스를 하나의 강제 브로커로 통과시키는 대신 디스패치 전략을 상위 계층 프로토콜에 맡겼다.

IANA의 현재 레지스트리는 이 어휘 경계를 지킨다. 서비스 이름과 포트 번호는 TCP, UDP 및 기타 전송 계층 내에서 서비스를 구분한다. 레지스트리는 또한 할당이 증명할 수 없는 것을 명시한다. 할당은 애플리케이션을 보증하지 않으며, 등록된 포트의 트래픽이 할당된 서비스나 안전한 트래픽일 필요는 없다.

주소는 압축된 전달 타협이었다

Clark은 데이터그램을 가상 회로와 대조했다. 회로 중심 시스템은 설정 단계에서 정교한 주소를 보내고 이후 짧은 식별자만 실을 수 있다. 인터넷 데이터그램은 사전 설정 없이도 라우팅 가능해야 하므로 주소가 모든 패킷에 들어가야 했다. 32비트는 도달 범위와 헤더 비용 사이의 타협이었고, 이미 논문이 표현한 대로 상당한 무리한 끼워 맞춤을 요구하고 있었다.

이 관찰이 RFC 814를 CIDR, NAT, IPv6 또는 오늘날 주소 시장의 예언으로 만들지는 않는다. 그것은 설계 압력을 확립한다. 주소는 압축된 전달 상태였다. 인간 참조가 그 상태를 물려받도록 요구한다면 신원은 전달 필드의 한계와 이동에 묶이게 된다.

분리가 바로 결과였다

운영 관점에서 네 가지 기록은 서로 구별되어야 한다. 조회된 이름과 그 바인딩의 출처 및 나이를 보존하라. 반환된 모든 주소를 보존하라. 선택된 경로, 인터페이스, 다음 홉, 경로 epoch를 기록하라. 전송 계층과 포트를 기록하라. 마지막으로 인증, 권한 부여, 애플리케이션 완료를 따로 보존하라.

그러면 실패의 위치를 잡을 수 있다. 이름은 해석되지만 경로가 존재하지 않을 수 있다. 경로는 동작하지만 잘못된 서비스가 수신 중일 수 있다. 기대한 프로세스가 연결을 수락하면서 신원을 거부할 수 있다. 애플리케이션이 호출자를 인증한 뒤에도 요청된 작업에 실패할 수 있다.

RFC 814의 역사적 가치는 이 모든 상태를 편의상 '목적지'라고 부르는 지름길을 거부한 데 있다. 이름은 주소가 아니었다. 주소는 경로가 아니었다. 경로는 프로세스가 아니었다. 포트는 서비스의 증거가 아니었다. 각 번역이 다음 단계에 대한 권한을 주장하지 않고 바뀔 수 있었기 때문에 상호 운용성은 더 오래 지속될 수 있었다.

출처