요약

  • 초기 인터넷 설계자들은 여러 전송 프로토콜이 난립하는 상황을 피하려 했습니다. RFC 114는 파일 프로토콜이 어디까지 할 수 있을지,execute(실행)까지 포함해 시험해 보았습니다.
  • RFC 171/172는 다른 경계를 그렸습니다. 여러 애플리케이션이 하나의 전송 계층을 공유할 수 있지만, FTP에는 원격 실행을 위한 표준 절차가 없었습니다.

1971년 네트워크 설계자들은 표준화 문제에 직면했습니다. 각 애플리케이션이 자신만의 방식으로 데이터를 옮길 것인가, 아니면 여러 애플리케이션이 하나의 전송 프로토콜을 공유하면서 각자의 명령을 정의할 것인가. RFC 114는 이 문제의 핵심을 하나의 동사에서 드러냅니다. 그 목록은retrieve(검색)와rename(이름 변경)에서execute(실행)까지 이어지는데, 실행은 다른 컴퓨터에게 작업을 수행해 달라고 요청하는 것입니다. 몇 달 안에 RFC 171은 여러 애플리케이션을 위한 공통 전송 프로토콜을 제안했고, RFC 172는 그 위에 FTP를 올리면서 원격 실행은 표준 절차 없이 남겨 두었습니다. 이 논쟁은 공유 인프라가 어디서 끝나고 애플리케이션 동작이 어디서 시작되는가에 관한 것으로, 오늘날의 서비스에도 여전히 나타나는 설계 질문입니다.

RFC 114에서 파일은 명령, 데이터, 또는 둘 다를 담을 수 있었습니다. 그렇기 때문에execute가 검색·저장 작업 곁에 등장했습니다. 이는 일반 원격 셸이 아니라 제한된 트랜잭션이었습니다. 표제에는 1971년 4월 16일이 기재되어 있고, RFC Editor 목록은 4월 1일로 기록합니다. 이 제안은 트랜잭션을 통해 다른 호스트의 파일 시스템을 사용하는 협력 프로세스를 다룹니다. 작업 목록은 식별과 검색에서 저장, 추가, 이름 변경, 삭제, 열기, 닫기, 조회에 이르며,execute도 포함되어 있었습니다.

이 요청은 일반 원격 셸이 아니었습니다. RFC 114는 입력을 보내고 서비스 호스트에서 프로그램이나 서브루틴을 실행한 뒤 출력을 돌려받는 방식을 설명합니다. 그리고 그 가능성을 좁힙니다. 호출하는 프로세스가 인수와 응답에 관한 규약을 알고 있어야 했습니다. 이 프로토콜은 프로그램 파일을 둘러싼 통제된 교환을 스케치했을 뿐, 만능 명령줄이나 보안 모델은 아니었습니다.

이 제안은 구체적이면서도 한정된 환경과 묶여 있었습니다. RFC 114는 자신의 프로토콜이 MIT의 두 호스트, 즉 GE 645/Multics와 PDP-10/DM/CG-ITS에서 즉시 구현하기 위해 개발되었고 하버드 호스트도 가능성으로 언급되었다고 밝힙니다. 제한된 기능을 가진 중간 버전이 디버깅 중이었다고 합니다. 이것은 특정 구현 노력의 증거일 뿐, 나열된 모든 트랜잭션이 동작했거나 이 프로토콜이 네트워크 전반에 퍼졌다는 것을 보여 주지는 않습니다.

이후의 설계 문서들이 이 경계를 분명히 합니다. 1971년 6월자 RFC 171은 파일 전송, 원격 작업 접수, 메일, 그래픽, 원격 프로그램 실행을 포함한 여러 애플리케이션을 위한 공통 데이터 전송 프로토콜(Data Transfer Protocol)을 제안했습니다. 그 논거는 아키텍처적인 것이었습니다. 전송을 애플리케이션 기능에서 분리하면 구현이 더 유연해지고 복잡성을 줄이며 프로토콜의 난립을 피할 수 있다는 것입니다.

이에 짝이 되는 파일 전송 프로토콜인 RFC 172는 데이터 이동을 위해 그 공유 DTP를 사용하고 파일 작업을 자신의 애플리케이션 영역으로 정의했습니다. 호스트가 명령의 부분집합만 구현하는 것을 허용했습니다. 또한 FTP가 원격 프로그램 실행을 위해 확장될 수 있다고 밝혔지만, 그 방법에 대한 표준 절차는 제시하지 않았습니다. 가능성은 보이는 채로 남았고, 표준 FTP 절차는 그것을 흡수하지 않았습니다.

RFC 141의 동시대 논평은 실무적 질문을 구체화합니다. 로컬 파일 접근, 명령 부분집합, 그리고 작업 실행이 긴 대기를 수반할 수 있다는 가능성입니다. 이를 RFC 172의 일부 명령만 구현해도 된다는 허용과 함께 읽으면, 애플리케이션 프로토콜이 각 호스트에 얼마나 많은 것을 맡길 수 있었는지 알 수 있습니다.

RFC 171의 설계 타협은 경제성이었습니다. 하나의 재사용 가능한 전송 프로토콜이 여러 애플리케이션을 지원하며 프로토콜 난립을 줄일 수 있다는 것입니다. RFC 172는 그 타협의 다른 면을 보여 줍니다. DTP는 데이터를 옮길 수 있었지만, FTP 명령 부분집합과 애플리케이션별 절차는 여전히 호스트마다 달랐습니다. RFC 114는 제한된 구현 노력을 기록하고 있으며, 이 문서들만으로 execute 트랜잭션이 얼마나 널리 사용되었는지는 확인되지 않습니다.

이 경계가 이야기의 핵심입니다. 6월이 되어서도 원격 실행은 상상 가능한 일이었지만, FTP에는 그를 위한 표준 절차가 없었습니다.

출처