요약

  • TCPMUX는 TCP 1번 포트로의 접속이 이미 성립된 뒤에 응용을 선택했다. 서비스 이름 한 줄과 긍정 응답이 같은 접속을 선택된 프로토콜에 넘겼다.
  • 사설 서비스도 개별 공식 포트 할당 없이 이 만남 지점을 사용할 수 있었다. 다만 기존에 할당된 서비스, 예약된 이름, 클라이언트 호환성은 여전히 공통 규칙을 요구했다.
  • 구현 경계가 중요했다. inetd는 프로그램을 대신해 긍정 응답을 보낼 수 있었다. 선택, 실행, 인증, 작업 완료는 모두 같은 사건이 아니었다.

응용 앞에 오는 응답

플러스 기호는 의외로 약한 증거일 수 있다. TCPMUX 접속에서 이 기호는 클라이언트에게 선택된 프로토콜로 진행하라고 알린다. 그 응답이 반드시 그 프로토콜의 서버에서 온 것은 아니다. 중개자가 긍정 답변을 대신 제공하여, 구식 프로그램이 선택 교환이 있었다는 사실을 모른 채 일반 입력을 읽기 시작할 수 있게 하는 것이다.

이 작은 편의가 더 큰 설계를 드러낸다. TCPMUX는 익숙한 전송 계층의 만남 지점과 응용 사이에 디스패처를 놓았다. 클라이언트는 먼저 TCP 1번 포트에 접속하고 원하는 서비스를 지명한 뒤 결정을 기다렸다. 그다음에야 응용 대화가 시작되었다. 전화를 걸 두 번째 목적지도, 새로 열 전송 접속도 없었다.

M. Lottor의RFC 1078은 1988년 11월에 발표되어 이 메커니즘을 두 페이지에 규정했다. 서비스 이름은 대소문자를 구분하지 않고 캐리지 리턴과 줄 바꿈으로 끝났다. 응답은 플러스나 마이너스로 시작하고 설명을 포함할 수 있으며 같은 방식으로 끝났다. 긍정 응답은 선택된 프로토콜로 이어졌고, 부정 응답은 접속을 끝냈다.

이름과 달리, 이것은 하나의 오래 살아있는 채널 안에서 여러 응용을 끼워 넣는 방식이 아니었다. 하나의 접속에 대해 하나의 서비스를 선택했다. 다중화는 공용 입구에서 일어났다. 많은 가능한 서비스가 만남 지점을 공유했지만, 선택된 스트림은 이후 하나의 응용 대화였다. 이를 동시 스트림과 혼동하면 그 경제성과 한계를 모두 가리게 된다.

그 번호가 하던 일

제안의 동기는 TCP가 쓸 수 있는 모든 포트 값을 다 소진했다는 것이 아니었다. 문제는 낯선 클라이언트가 알려진 서비스를 찾을 수 있도록 조율된, 더 좁은 접점 집합이었다. RFC 1078은 당시의 잘 알려진 범위를 0–255로 기술했다. 이 역사적 범위를 TCP 포트 필드의 폭이나 오늘날의 레지스트리 분류와 혼동해서는 안 된다.

제안이 인용한 1987년 5월 할당 번호 문서RFC 1010은 당시의 관행을 보여준다. 프로토콜 개발자는 할당을 위해 지명된 조율 담당자에게 안내되었다. 공통 표가 서로 독립적으로 작성된 프로그램들이 하나의 번호가 가진 의미에 대해 일치하도록 만들었다. 이것은 상호운용성 서비스였다. 클라이언트가 보통의 접속 포트를 알아보기 위해 모든 서버 운영자와 별도 대화를 나눌 필요가 없게 해주는 것이었다.

그 이익은 동시에, 새로 만들어지는 전 세계적으로 인정되는 접점마다 하나의 조율 사건이 됨을 의미했다. TCPMUX는 사설 프로토콜에게 다른 거래를 제시했다. 입구와 그 간단한 선택 문법에 한 번 합의하고, 호스트가 적절히 구별되는 서비스 이름을 자기 프로그램에 대응시키게 하는 것이다. 로컬 실험은 더 이상 그 입구를 쓰기 전에 전용 공식 TCP 포트 할당을 받을 필요가 없었다.

"로컬"이라는 형용사는 대응의 범위를 말할 뿐, 제약이 없다는 뜻이 아니었다. 클라이언트는 여전히 호스트, 이름, 선택된 프로토콜에 대한 지식이 필요했다. 호스트는 여전히 리스너와 프로그램 실행 권한이 필요했다. 공유 포트는 네트워크 도달 가능성, 사용자 인가, 다른 운영자가 이 메커니즘을 채택해야 할 의무를 부여하지 않았다.

오래된 문은 열려 있어야 했다

RFC 1078에서 가장 영향력 큰 문장 가운데 하나는 이미 고유한 할당 포트를 갖던 서비스에 관한 것이다. 그 서비스들은 그 포트에서 계속 이용 가능해야 했고, 다중화기 경유는 선택 사항이었다. 새 입구는 오래된 입구를 보완할 수는 있었지만, 조용히 그 클라이언트를 빼앗을 수는 없었다.

이것이 중요한 이유는 서곡이 관측 가능하기 때문이었다. 기존 클라이언트는 접속 직후 서버 인사말을 기대할 수 있다. TCPMUX 클라이언트는 서비스 이름을 먼저 보내야 했다. 낡은 클라이언트를 1번 포트로 재지정하는 것이 그 규칙을 가르쳐 주지는 않는다. 프로토콜 확장은 서류상으로는 소박하면서도 양쪽 끝의 조율된 변경을 요구할 수 있었다.

이름 공간도 물려받은 의미를 유지했다. Assigned Numbers에 실린 이름은 지정된 정의를 위해 예약되어 있었다. 사설 서비스는 충돌 가능성이 낮은 이름을 고르도록 권고받았고, 조직 이름을 접두어로 붙이거나 버전 접미어로 변형을 구분할 수 있었다. 그러나 이들은 명명 규범이지 증명서가 아니었다. 그럴듯한 조직 접두어가 그 조직을 인증해 주지 않으며, 버전 접미어도 두 구현이 그 의미에 합의하지 않는 한 호환성을 협상해 주지 않는다.

예약된 HELP 요청은 메뉴를 제공했다. 지원되는 서비스 이름을 한 줄에 하나씩 나열한 뒤 접속을 닫는 것이다. 이는 유용한 로컬 발견 기능이지만 범위는 작았다. 인터넷의 모든 호스트를 지명하지도, 지리적으로 적합한 서버를 찾아주지도, 목록에 오른 프로그램이 요청을 완수할 수 있다고 증명하지도 않았다. 이 메뉴는 호스트가 제공하는 선택지를 기술할 뿐, 보편적인 서비스 시장이 아니었다.

설정 파일이 교환기가 되다

운영체제 문서는 작업 분담을 구체적으로 보여준다.NetBSD inetd 매뉴얼은/etc/inetd.conf가 제공하는 서비스 이름 표에서의 조회를 기술한다.tcpmux/형식에서는 호출된 서버가 긍정 응답을 제공할 것으로 기대한다.tcpmux/+형식에서는 다중화기가 그 응답을 대신 제공하며, 표준 입력과 출력을 쓰는 구식 프로그램을 수용한다.

이것은 단순한 표기 차이 이상이다. 프로토콜 경계에 대한 책임을 배정하는 것이다. 두 구성 요소가 모두 자신이 선택을 확인해야 한다고 믿으면, 응용 입력에 응답이 하나 더 붙을 수 있다. 서로 상대방이 확인해 주기를 기대하면, 클라이언트는 영원히 오지 않을 답을 기다릴 수 있다. 이는 넘겨주기 배치의 결과물이며, 문서화된 역사적 장애에 대한 주장이 아니다.

FreeBSD inetd 매뉴얼 소스는 별도의 활성화 요건을 더한다. 개별 TCPMUX 서비스 외에 다중화기 자체도 활성화되어야 한다. 서비스 정의와 활성화된 만남 지점은 서로 다른 설정 조각이다. 매뉴얼은 이 기능을 로컬에서 개발한 서버에 유용하다고 말하며, 접속을 파일 디스크립터 0과 1로 전달한다고 기술한다.

이 자료들은 하나의 구현 경로를 확립할 뿐, 그 보편성을 확립하지 않는다. 또한 운영상 권한이 어디에 있는지를 보여준다. 로컬 설정이 실행 파일과 실행 신원을 선택한다. 디스패처가 이름을 프로세스와 연결함으로써 유용하게 만든다. 전역 레지스트리는 기계 내부로 들어가 그 행위를 수행하지 않는다.

따라서 긍정 선택 응답은 신중한 해석이 필요하다. inetd가 응답을 제공할 때, 그 응답은 어떤 의미 있는 응용 교환보다 먼저 올 수 있다. 프로그램이 응답을 제공하는 경우에도, 응답은 완료된 거래가 아니다. 클라이언트는 여전히 자신이 의도한 프로토콜로 대화하고 있음을 확인하고, 인증 요건을 충족하며, 실제 요청의 결과를 관찰해야 한다.

정복 서사 없이 보존하기

번호 체계는 계속 진화했다. 2011년에 발표된RFC 6335는 시스템 포트 0–1023, 사용자 포트 1024–49151, 동적 포트 49152–65535를 구분한다. 또한 고정 포트 없이 서비스 이름을 등록하는 것을 허용한다. 이름과 번호가 불가분의 행정 대상일 필요는 없다.

2015년에RFC 7605는 대역 내 역다중화를 포함해 불필요한 포트 할당을 피하는 방법을 논의하고, 프로토콜 안에서 서비스 버전을 구별할 것을 권고했다. 이 후대 권고는 아키텍처적 맥락을 제공한다. 그러나 TCPMUX가 후대의 정책을 직접 낳았거나, 하나의 공용 포트가 모든 서비스에 최선이라는 것을 확립하지는 않는다.

현재의IANA 서비스 및 포트 레지스트리는 tcpmux를 1번 포트에 유지하고 있다. 나란히 놓인 TCP와 UDP 행에는 특별한 주의가 필요하다. RFC 1078이 정의한 것은 TCP 교환이며, 추가된 레지스트리 행이 그 문서가 한 번도 정의하지 않은 UDP 프로토콜을 제공해 주지는 않는다. 행정적 대칭은 프로토콜 의미론의 대용품이 아니다.

유지된 할당이 활성 설치 수를 세어 주지도 않는다. 표준, 매뉴얼, 활성화된 설정, 관측된 트래픽은 서로 다른 네 종류의 증거다. 이용 가능한 기록은 이 제안과 그 구현 경계에 대한 정확한 서술을 뒷받침한다. 그러나 채택률 조사나, 인터넷 전체가 이를 왜 수용했거나 거부했는지에 대한 자신만만한 이야기를 뒷받침하지는 않는다.

그런 결론이 없어도 TCPMUX는 가치 있는 역사다. 작은 공유 문법이 미래의 선택을 로컬에 남겨 둘 수 있게 하면서도 기존 클라이언트에 대한 의무를 지키는 방식을 보여준다. 공통 계층은 묻는 방법을 결정한다. 호스트는 어떤 프로그램이 응답할지 결정한다. 응용은 여전히 유용한 작업이 실제로 일어났음을 증명해야 한다.