요약

  • RFC 818은 포트 107을 선택적 Remote User Telnet 서비스에 할당했다. 호출자가 도달하는 응용 프로그램은 단순히 호스트 셸(실행 환경)을 보여주는 대신 다른 Telnet 연결을 시작할 수 있었다.
  • BBN의 TC68K는 수신 Server Telnet과 발신 User Telnet을 의사 텔레타이프(PTY)를 통해 등을 맞대어 결합했다. 이 다리는 기존에 동작 중이던 구성 요소를 재사용했지만, 그 안에는 여전히 두 개의 TCP 연결, 두 개의 Telnet 엔드포인트, 여러 개의 로컬 권한 경계가 존재했다.
  • 성공한 테스트는 당시 그 특정한 연쇄가 동작했음을 관찰한 것이다. 포트 번호는 기능을 위치시켰을 뿐, 조작자를 인증하거나 발신 대상을 허가하거나 응용 프로그램의 완료를 증명하지 않았다.

포트 23은 보통 실행 환경에서 끝났다

초기 Telnet에는 알아볼 수 있는 정문이 있었다. User Telnet이 연결을 시작했고, Server Telnet은 포트 23에서 수신 대기하며 통상 호출자를 호스트의 실행 환경(executive)에 연결했다. TOPS-20에서는 EXEC일 수 있고, Unix에서는 셸일 수 있었다. 원격 기계는 사용자가 다음 프로그램을 선택할 수 있는 일반적인 환경을 노출했다.

이 관례는 더 깊은 설계에 기반했다. 1980년에 발표된RFC 764는 Telnet을 터미널 장치와 터미널 지향 프로세스를 위한 일반적인 양방향 바이트 전송 수단으로 기술했다. 그 공통 객체는 Network Virtual Terminal, 즉 모든 호스트가 다른 모든 터미널을 알아야 하는 부담을 없앤 가상의 키보드-프린터 인터페이스였다. 선택적 동작은 협상될 수 있었고, 거부하면 양쪽 끝이 최소 NVT 상태로 돌아갔다.

User와 Server라는 명칭은 헌법적이라기보다 실용적인 것이었다. User 호스트는 보통 물리적 터미널을 보유했지만, 같은 문서는 더 이식 가능한 정의를 제시했다. 터미널 대 터미널 또는 프로세스 대 프로세스 사용에서 User란 통신을 시작한 쪽이다. 이 역할은 연결에 귀속되는 것이었으며, 기계에 영구히 붙는 계급이 아니었다.

그럼에도 포트 23은 하나의 응용 형태를 지배적으로 만들었다. 그곳에 연결하면 원격 Server Telnet이 일반 서비스 호스트로의 터미널 세션을 제공할 것으로 기대되었다. 네트워킹은 갖추었지만 들어갈 만한 실행 환경이 없는 기계에서는 이 가정이 불편해졌다.

작은 호스트는 셸이 있다고 가장할 필요가 없었다

1982년 11월에 발표된RFC 818은 화려하지 않은 예외로 시작했다. 작은 호스트는 기능이 매우 제한적이고 실행 환경이 없을 수 있다. 그런 기계에서는 일반적인 Telnet 로그인이 불필요했다. 특정 응용 프로그램 하나만으로도 자신만의 잘 알려진 만남 지점을 가질 만큼 유용할 수 있었다.

명세된 응용 프로그램은 의외의 것이었다. 바로User Telnet이었다. Remote User Telnet 서비스를 제공하기로 한 호스트는 포트 107에서 수신 대기했다. 들어오는 연결은 여전히 Telnet을 사용했지만, 그 뒤에 있는 기능은 스스로 또 다른 Telnet 연결의 User 측이 될 수 있는 프로그램이었다.

이것은 서버의 이름을 클라이언트로 바꾼 의미론적 트릭이 아니었다. 외부 경계에는 수신 서비스가 있었고, 호스트 내부에는 발신 User Telnet이 있었다. RFC 818은 이 구성을 주소 지정 가능하게 만들었을 뿐, 어느 쪽 프로세스도 지우지 않았다.

이 구분이 중요한 이유는 잘 알려진 번호가 답하는 질문이 좁기 때문이다. 이 종류의 교환을 위해 의도된 로컬 수신자는 어느 것인가? 번호는 누가 호출할 수 있는지, 내부 User Telnet이 어느 목적지에 도달할 수 있는지, 최종 응용 프로그램이 무엇을 할지 말해 주지 않는다.

열여섯 개의 직렬 회선과 하나의 재사용 가능한 프로세스 그래프

RFC 818의 예제는 Bolt Beranek and Newman에서 실제로 운용 중이던 기계에서 나왔다. TC68K는 Motorola MC68000을 기반으로 만들어진 터미널 집선기였다. 네트워크 연결 하나, RS-232 터미널 연결 열여섯 개, 프로그래밍 가능한 타이머를 갖추고 있었다. 그 Micro-Operating System은 IP, ICMP, TCP, Telnet을 구동했다.

이 기계에는 이미 유용한 두 가지가 들어 있었다. User TC-Telnet은 부속 터미널 앞의 사람이 네트워크 호스트에 연결할 수 있게 했다. Server Telnet은 반대 방향의 변환을 담당했다. 원격 프린터, 플로터, 컴퓨터를 포함해 네트워크 인식이 없는 장치를 대변했다.

BBN은 여러 건물에 TC68K를 두고 있었고, 원격 장치를 테스트할 운용 가능한 방법이 필요했다. 새 관리 프로토콜을 설계하는 대신, 그 소프트웨어는 User Telnet을 Server Telnet과 등을 맞대어 결합했다. 조작자가 원격 집선기로 Telnet 연결을 열면, User TC-Telnet에게는 마치 그 장치에 국지적으로 연결된 터미널에 앉아 있는 것처럼 보였다. 조작자는 이어서 발신 연결을 만들고 표준 응용 프로그램이 이미 유지하고 있던 통계를 확인할 수 있었다.

이 메모는 추가로 필요한 소프트웨어가 의사 텔레타이프 드라이버뿐이라고 말한다. 응용 프로그램에게 PTY는 터미널처럼 보였다. 내부적으로는 두 프로세스 사이의 문자 스트림을 제공했다.

이것은 축소판의 Running-Code Primarity였다. 구현은 한 사이트에 운용상의 필요가 있다고 해서 공유 프로토콜을 확장하지 않았다. Telnet의 기존 와이어 계약을 재사용하고, 이미 동작하던 프로그램들 사이에 작고 로컬한 어댑터를 놓았다.

하나의 터미널 화면 뒤에 감춰진 두 대화

조작자에게 그 결과는 하나의 연속된 콘솔처럼 느껴질 수 있었다. 구현 그래프는 더 정확했다.

  1. 조작자의 로컬 User Telnet이 수신 TCP 연결을 열었다.
  2. TC68K의 Server Telnet이 그 연결을 종단했다.
  3. PTY가 로컬 문자 스트림을 TC68K User Telnet으로 전달했다.
  4. 그 User Telnet이 선택된 대상으로 두 번째 TCP 연결을 시작했다.

각 Telnet 연결에는 자신만의 상태가 있었다. 각각은 독립적으로 옵션을 협상할 수 있었다. 한쪽 TCP 연결이 닫히는 동안 다른 프로세스는 계속 존재할 수 있었다. 첫 번째 스트림에서 받아들인 문자가 두 번째 연결의 최종 응용 프로그램에 의해 확인된 것은 아니었다.

RFC 818은 범용 옵션 변환기, 종단 간 보안 연계, PTY를 넘어 모든 장애를 전파하는 규칙을 정의하지 않는다. 등을 맞댄 배치라는 말이 그것을 투명한 파이프로 바꾸게 해서는 안 된다. Telnet은 데이터와 섞인 제어 정보를 전송하며, 로컬 NVT 매핑과 프로세스 동작은 여전히 양쪽 엔드포인트에서 일어난다.

후속 문서인RFC 854는 이 그래프가 왜 정당한지 설명해 준다. 이 문서는 터미널과 프로세스의 대칭적 관점을 유지하면서, 그 대칭은 철칙이 아니라 운용 원칙임을 인정했다. 같은 호스트가 수신 연결에서는 Server이고 발신 연결에서는 User일 수 있었다. 그 동사들이 서로 다른 관계를 지칭하기 때문에 모순은 없었다.

성공한 테스트에는 정확한 증거 경계가 있었다

RFC 818은 그 배열이 두 TC68K 사이의 네트워크 경로가 동작 가능함을 검증했다고 말한다. 이 진술은 관찰된 규모 그대로 유지되어야 한다.

성공한 세션은 호출자가 수신 서비스에 도달했고, 수신 Telnet이 교환의 필요한 부분을 처리했고, PTY가 해당 스트림을 전달했고, 발신 User Telnet이 테스트된 연결을 만들었고, 대상이 조작자가 통계를 볼 수 있을 만큼의 정보를 돌려보냈음을 보여준다. 그것은 의미 있는 운용 증거다. ICMP 에코보다는 많고, 네트워크의 모든 속성보다는 적은 것을 다룬다.

이것은 다른 경로도 작동할 것임을, 모든 Telnet 옵션이 이 구성을 통과함을, 프린터가 작업을 완료했음을 증명하지 못했다. 소켓에서 문자가 도착했다는 이유만으로 인간을 식별하지도 못했다. 수신자가 임의의 목적지에 도달할 권한이 있음을 보여주지도 않았다.

전송과 판정 사이의 이 구분은 콘솔에서는 잃기 쉽다. 익숙한 프롬프트 하나가 여러 계층을 하나의 시각적 표면으로 접어 버린다. 좋은 운영은 숨겨진 연쇄를 재구성한다. 입장 허가, 로컬 다리 놓기, 발신 대상 선택, 원격 수용, 최종 작업.

공통 터미널이 여전히 안전한 바닥이었다

1989년의RFC 1123은 Telnet을 주로 키보드/디스플레이를 명령 해석기에 연결하는 표준 원격 로그인 프로토콜로 기술했다. 그러나 그 요구 사항은 여전히 User Telnet과 Server Telnet을 각각 명명했다. 양쪽 모두 필수 제어 기능을 갖췄고, 양쪽 모두 지원되지 않는 명령을 처리해야 했으며, 모든 구현은 옵션 협상을 유지하고 더 풍부한 합의가 실패하면 NVT로 후퇴해야 했다.

이 조합이 중요하다. 대칭성은 프로세스 구성을 가능하게 했다. 역할별 의무는 그 구성을 이해 가능하게 유지했다. 최소 공통 상태는 엔드포인트가 선택적 동작을 거부해도 무효로 선언되지 않게 했다. TC68K는 포트 107을 제공할 수 있었고, 다른 호스트는 그 제공을 거부할 수 있었다. 발표는 명령으로 배치를 만들지 않았다.

현재의IANA 서비스 이름 및 전송 프로토콜 포트 번호 레지스트리에는 여전히 포트 107에rtelnet이 "Remote Telnet Service"라는 설명과 함께 실려 있다. 이 행은 조정을 위한 참조를 보존한다. 그것은 이 서비스가 현재 배치되어 있거나, 안전하거나, 특정 제품이 지원한다는 증거가 아니다. 레지스트리의 UDP 행이 RFC 818을 데이터그램 프로토콜로 만들지도 않는다. 그 메모는 연결 위의 Telnet을 명세했다.

직렬 포트는 결국 문자 이상을 필요로 했다

RFC 818으로부터 15년 뒤,RFC 2217은 Telnet을 또 다른 액세스 서버 경계에 사용했다. 클라이언트는 발신 모뎀, 프린터, 플로터, 모니터링 장치에 연결된 직렬 포트에 도달할 수 있었다. 경험이 누락된 의미론을 드러내게 만들었다.

벌거벗은 문자 스트림은 전송 속도, 데이터 폭, 패리티, 스톱 비트, 모뎀 신호 변화, 서로 다른 두 계층의 흐름 제어를 신뢰할 수 있게 표현할 수 없었다. 그래서 RFC 2217은 Telnet COM-PORT-OPTION을 정의했다. 엔드포인트는 통상의 WILL, WON'T, DO, DON'T 절차로 그것을 협상했다. 수락되면 명시적 명령이 포트 상태를 바꾸고, 명시적 통지가 회선 상태를 보고했다.

가장 드러나는 점은, 서버가 구성 명령을 처리한 뒤 이를 확인 응답하고 실제로 설정된 값을 보고했다는 것이다. TCP는 이미 바이트 수신을 확인했다. 그 이후의 응답은 다른 사실을 확립했다. 액세스 서버가 어떤 값을 적용했다는 것인데, 그 값은 요청된 것과 다를 수 있었다.

보안 절은 또한 입장과 정리를 분리했다. 인증은 하나의 관심사였다. 세션이 끝나면 서버는 원격 서비스를 끊고 직렬 구성을 관리자가 정의한 알려진 상태로 재설정할 것으로 기대되었다. 그렇지 않으면 한 호출자의 로컬 선택이 다음 호출자에게 상속된 현실이 되어 버릴 수 있었다.

RFC 2217은 여기서 RFC 818의 문서화된 후속물이나 대체물로 제시되지 않는다. 그것은 같은 아키텍처 경계에 대한 나중의 시험이다. 스트림을 재사용하는 것은 값싸다. 로컬 하드웨어 결정이 중요해지는 순간, 그 결정에는 명명된 명령, 보고, 그리고 상태를 복원할 책임 있는 주체가 필요해진다.

번호는 서비스를 위치시켰을 뿐, 연쇄를 소유하지 않았다

RFC 818의 가장 깊은 교훈은 현대의 원격 액세스 플랫폼보다 작으면서 포트 107보다 오래 지속된다. 안정적인 공통 인터페이스는 한 사이트가 로컬 구현 역할을 재배치할 수 있게 했다. 공유 계층은 Telnet 피어들이 어떻게 대화할 수 있는지를 말했다. TC68K는 어떤 프로세스를 결합할지, 그 구성을 노출할지를 결정했다. 조작자는 존재하는 로컬 통제 아래에서 대상을 선택했다. 대상은 여전히 어떤 서비스를 수행할지를 스스로 결정했다.

등록은 문을 이름 지었다. 수신 대기가 한 호스트에서 문을 실재하게 만들었다. 인증은 호출자를 이름 지을 수 있었다. 인가는 다음 연결을 제한할 수 있었다. 응용 증거는 작업을 증명할 수 있었다. 그 어떤 동사도 다른 모든 동사를 대신할 수 없었다.

클라이언트가 서비스가 된 것은 동작 중인 구성 요소들이 그 구성을 유용하게 만들었기 때문이지, 레지스트리가 프로그램을 권한 주체로 변환했기 때문이 아니었다.