요약

  • 1983년 1월 1일 기한은 ARPANET에서 효력을 가졌다. 그 후원자가 NCP 트래픽을 거부할 수 있는 실행 경계를 통제했기 때문이며, 이는 전 세계의 독립 네트워크들을 구속하지 않았다.
  • RFC 801은 각 호스트 조직이 자체 구현에 책임을 지도록 했고, 임시 중계, 애플리케이션 동등성, 서비스 조사, 시험 차단은 구식 서비스의 최종 철수 전에 불확실성을 줄였다.
  • 전환은 기한 이후에도 완전하지 않았다. 서비스 조사 수치는 순진한 100퍼센트에 크게 못 미쳤고, 호스트 테이블 배포는 실패했으며, 운영 부하는 테스트에서 놓친 성능 문제를 드러냈다.

한 문서가 IMP에 도달한 순간

NCP만을 지원하는 호스트는 동작하는 소프트웨어와 유효한 ARPANET 연결, 기꺼이 사용하는 사용자를 모두 갖추고 있었더라도, 서브넷이 그 프로토콜에 대한 서비스를 중단하면 일상적인 통신을 잃을 수 있었다. 그것이 1983년 전환의 실천적 핵심이다. 사양이 TCP와 IP를 기술했고, 계획이 기한을 발표했다. 그러나 그 어느 것도 그 자체로 패킷 처리를 바꾸지는 못했다. 변화가 현실이 된 것은 ARPANET 경계를 운영하는 장비가 구식 호스트 간 트래픽을 거부할 수 있게 되었을 때였다.

Vint Cerf는 나중에 Interface Message Processor가 NCP 서비스를 거부할 수 있는 메커니즘을 갖추고 있었다고 회상했다. 그의 서술에 따르면 네트워크는 1982년 중반 하루 동안, 그리고 10월경 이틀 동안 NCP를 비활성화했다. 이전을 완료하지 못한 사람들에게 전자우편은 동작을 멈췄다. 그 소란은 시험의 일부였다. 약속된 미래의 차단이 관측된 현재의 결과가 된 것이다.

Cerf의 날짜들은 스위치 로그가 아니라 회상이며, 그는 1월 차단 이후 몇 가지 특별한 예외가 남았다고 기억했다. 이런 단서들이 이 사건을 더 유용하게 만든다. '플래그 데이'는 완벽하게 동시적인 전 세계의 탄생이 아니었다. 그것은 하나의 후원 네트워크에서, 리허설과 예외 조치, 그리고 잔여 문제들을 거쳐 관리된 일련의 과정이 끝난 지점이었다.

NCP가 다음 세대의 네트워크를 운반할 수 없었던 이유

NCP는 단순히 TCP의 구버전이 아니었다. 그것은 ARPANET의 서비스 가정과 주소 환경에 묶여 있었다. RFC 801은 패킷 라디오, 위성 시스템, 로컬 네트워크에 대한 연구가 ARPANET의 호스트 간 프로토콜을 부적합하게 만들었다고 말했다. 새로운 과제는 서로 다른 기반 기술로 구축된 네트워크들 사이에서, 그 네트워크들이 하나의 물리적 시스템이 되도록 요구하지 않고 호스트들이 통신하게 하는 것이었다.

IP는 RFC 791에 기술된 공용 데이터그램 계층을 제공했다. TCP는 그 위에서 신뢰성 있는 호스트 간 통신을 RFC 793으로 제공했다. 이 결합은 기반 네트워크들을 지우지 않았다. 오히려 그 너머에 공유 환경을 만들었다. RFC 801은 이 상호연결된 집합을 ARPA Internet, 때로는 'Catenet'이라 불렀다.

이 구분이 NCP를 무기한 유지하는 것이 중립적일 수 없는 이유를 설명한다. NCP 의존성 하나하나가, 연구 프로그램이 여러 네트워크를 연결하려 하는 동안 하나의 패킷 네트워크에 묶인 서비스를 보존했다. 이중 운영은 이전 시간을 벌어 주었지만, 중계 용량을 소모하고 호스트 테이블을 복잡하게 만들었으며 두 환경에서 서비스 소프트웨어를 유지해야 했다. 호환성에는 비용이 따랐고, 그 비용은 뒤처지는 호스트가 아니라 운영자들이 부담했다.

미국 국방부는 DoD 패킷 네트워크에 IP와 TCP를 채택했고, ARPANET은 그가 정의된 계약자와 호스트 커뮤니티를 통해 후원하고 운영하던 네트워크였다. 따라서 그 기한에는 통제면이 존재했다. 국방부는 ARPANET 서비스의 지속을 프로토콜 전환에 조건부로 걸 수 있었다. 이는 표준 저자가 훗날 인터넷에 합류할 수 있는 모든 네트워크에 대한 관할권을 얻었다는 주장과는 전혀 다르다.

현지의 작업에서 만들어진 기한

RFC 801은 구현의 주된 의무를 정확히 그것이 속한 곳에 두었다. 각 호스트 조직이 자신의 기기들을 위해 IP/TCP를 구현해야 했다. 공용 문서는 패킷 형식과 동작을 명명했지만, 어떤 중앙 사무실도 모든 운영체제를 포팅하고 모든 애플리케이션을 고치고 모든 사이트를 교육할 수는 없었다.

계획은 또한 동작하는 전송 스택만으로는 불충분하다는 것을 인정했다. Telnet, 파일 전송, 메일이 TCP 위에서 작동해야 했다. 사용자는 IP 패킷이 테스트를 통과하는 순간 '프로토콜 채택'을 경험하지 않는다. 사용자가 로그인하고 파일을 옮기고 메일을 주고받을 수 있고, 각 작업마다 아래 네트워크를 다시 구축하지 않아도 될 때 채택은 신뢰성을 얻는다.

메일은 이 연속성 문제를 가장 선명하게 드러냈다. RFC 773은 전환의 기본 규칙을 정했다. 기존 ARPANET 메일박스 이름은 계속 작동해야 하며, 구식 메일 메커니즘은 과도기 동안 사용 가능해야 하고, NCP와 TCP 환경 간 전달은 가능한 한 사용자 개입 없이 이루어져야 한다. 철수가 정당화될 수 있기 전에, 새 환경은 구식 환경과 최소한 같은 정도로 유용해야 했다.

이를 위해 다리가 필요했다. RFC 801은 NCP와 TCP를 모두 다룰 수 있는 호스트를 Telnet, FTP, 메일의 중계 호스트로 지정했다. 대화형 사용자는 TCP로 중계 호스트에 접속한 뒤 목적지로 두 번째 NCP 연결을 만들 수 있었다. 파일은 두 단계로 복사될 수 있었다. 메일 포워더는 한 프로토콜로 접수하고 다른 프로토콜을 통해 배달을 큐잉할 수 있었다.

이런 장치들은 의도적으로 임시였다. 중계는 경로에 또 하나의 호스트, 또 하나의 계정 체계, 또 하나의 고장 지점을 놓았다. 그 부하는 서로 호환되지 않는 두 모집단의 곱에 비례해 커졌다. 중계는 조직들이 자신들의 시스템을 포팅하는 동안 연속성을 보호했지만, 구식 호환성 집합을 영원히 보조하겠다는 약속은 아니었다.

의례적 합의 대신 경고성 차단

시험 차단은 종종 마지못한 엔지니어들에 대한 색채 있는 이야기로 전해진다. 제도적으로 그것들은 정밀한 일을 했다. 발표된 경계가 실행 가능한지 검증하고, 누가 여전히 NCP에 의존하는지 드러내며, 추상적 경고를 귀속 가능한 운영 손실로 바꿨다.

그렇다고 그 과정이 민주적이었거나 민주적일 필요가 있었던 것은 아니다. ARPANET 호스트 커뮤니티는 전 세계적 프로토콜 정부를 선출한 적이 없었다. 관련 권위는 네트워크에 대한 책임에서 나왔다. 후원자는 자신이 지원하는 서비스를 변경할 수 있었고, 호스트 조직들은 자신들이 연결하는 시스템에 대한 책임을 유지했다. 시험은 또한 후원자가 자신의 규칙에 따르는 비용을 직면하게 했다. 메일이 멈출 때, 그 혼란은 자신의 연구와 조정이 네트워크에 의존하던 바로 그 커뮤니티 안에서 가시적으로 드러났다.

그렇기 때문에 이 사건은 보편적 프로토콜 경찰을 정당화할 수 없다. 네트워크를 운영하지도, 그 손실을 감당하지도 않는 조직이 ARPANET의 기한을, 비채택자를 전 세계적으로 무효화하는 선례로 빌려올 수는 없다. 1983년의 강제 메커니즘은 물리적이고 유한했다. NCP 트래픽은 네트워크 가장자리에서 서비스를 잃었을 뿐, 다른 곳의 독립 네트워크는 선언으로 존재를 멈추지 않았다.

조사가 실제로 측정한 것

RFC 801의 깔끔한 이정표는 1983년 1월까지 모든 호스트가 TCP를 지원하게 되고, NCP와 중계가 서비스에서 철수하며, 모든 주요 서비스가 TCP 위에서 실행될 것이라고 말했다. 측정 기록은 그보다 지저분하다.

David Smallberg는 호스트들이 Telnet, FTP, SMTP 서버에 대한 연결을 수락하는지 검사했다. RFC 847은 전환기 전후의 주간 조사를 요약했다. 1982년 12월 28일에는 목록에 오른 314개 호스트 중 95개가 Telnet을, 80개가 FTP를, 72개가 SMTP를 수락했다. 1983년 1월 4일에는 315개 중 각각 151, 132, 124로 올랐다. 2월 22일에는 325개 중 190, 181, 178이었다.

이것들은 TCP 구현을 갖거나 갖지 않은 호스트의 백분율이 아니다. 호스트는 다운되어 있을 수도, 특수 목적으로 운영되고 있을 수도, 테스트된 서비스를 의도적으로 제공하지 않을 수도 있다. 저자들은 호스트의 11퍼센트가 이런 범주에 속해 이론적 상한이 약 89퍼센트라고 추정했다. 조사의 분모도 달라졌다. 정확한 추론은 절제된 것이다. 가시적인 TCP 서비스는 차단을 전후로 급격히 늘었지만, 계획이든 날짜든 깨끗하게 관측 가능한 100퍼센트 상태를 만들어내지는 않았다.

이 조사들은 승리의 슬로건보다 가치 있다. 불확실성을 검사 가능하게 만들기 때문이다. 공표된 의도와 도달 가능한 서비스를 구분한다. 또한 운영적 이전에는 여러 지표가 필요한 이유를 드러낸다. 스택 가용성, 애플리케이션 준비 상태, 실제 서비스, 트래픽 점유율, 예외 상태, 사용자 경험은 서로 다른 사실이다.

그 다음 날 아침도 여전히 전환기였다

후에 RFC 942로 공표된 미국 국가연구위원회의 평가는 커트오버를 운영적으로 성공했다고 판단하면서도, 플래그 데이 전설이 빠뜨린 것들을 기록했다. 약 30개의 TCP 전용 호스트가 1월 전에 수개월간의 테스트에 참여했다. 이 준비는 스위치 기간 중 운영 능력을 유지하는 데 도움이 되었지만, 정상 서비스 수준으로 돌아오는 데는 몇 달이 걸렸다.

Network Information Center는 새 프로토콜을 지원할 준비가 되어 있지 않았고, 이로 인해 호스트 테이블 배포에 문제가 생겼다. 서비스 호스트들은 심각한 성능 문제를 겪었다. 어떤 것도 긴 기간 동안 전체 사용자 부하 아래에서 스트레스 테스트를 받지 않았기 때문이다. 사용자가 도착한 뒤 매개변수가 조정되어야 했다. 메일 중계는 많이 사용되었지만, 다른 중계 기능은 그렇지 않았다.

이런 실패들은 전환을 무효화하지 않는다. 오히려 그것을 정의한다. 프로토콜은 배치에 충분히 올바를 수 있지만, 그를 둘러싼 이름 체계, 배포, 용량, 인력 체계는 준비되지 않은 채 남을 수 있다. 커트오버 날짜는 하나의 호환성 약속을 은퇴시킬 뿐, 운영 성숙성을 만들어내지는 못한다.

근거는 또한 중앙 계획에 대한 손쉬운 이론을 반박한다. RFC 801의 시간표는 이례적으로 명시적이었지만, 실행은 운영체제 팀, 서비스 호스트 관리자, Network Information Center, TAC 운영자, 중계 유지자, 사용자들 사이에 분산되어 있었다. 중심은 경계를 설정할 수 있었다. 그러나 현지의 역량을 대신할 수는 없었다.

권한이 멈춘 곳

1983년의 사건은 명령과 자발적 채택을 모두 담고 있지만, 서로 다른 계층에서다. ARPANET 안에서, 지원받는 호스트 조직은 NCP 서비스를 영원히 요구할 무한한 권리를 유지하지 않았다. 지속적인 접근은 서브넷을 책임지는 행위자가 정한 호환성 조건을 수반했다. 몇 가지 예외가 허용될 수 있었지만, 구식 서비스에는 끝이 있었다.

ARPANET 밖에서, 같은 후원자는 TCP/IP를 명령으로 참되게 만들 수 없었다. 다른 패킷 네트워크, 로컬 네트워크, 공급자들이 이를 구현해야 했다. 상대편은 성공적으로 패킷을 교환해야 했다. 애플리케이션이 작동해야 했다. 프로토콜 스위트가 퍼진 것은, 이질적인 네트워크들 너머의 최소한의 공용 환경을 제공했고, 그 주장이 실행 중인 시스템들로 입증되었기 때문이다.

이것이 조정과 주권 사이의 경계다. 네트워크 운영자는 지원할 수 없거나 지원하지 않을 트래픽을 거부할 수 있다. 규칙을 공표하고, 근거를 제시하고, 예외를 드러내고, 예측 가능한 비용을 감당해야 한다. 자신의 지역적 실행 권력을 모든 참여자, 모든 구현, 모든 미래의 네트워크에 대한 소유로 변환할 수는 없다.

따라서 1983년 1월 1일 가장 중요한 사건은 '인터넷의 탄생'이 아니었다. 인터네트워킹은 이미 설계되고 시연되고 사용되고 있었다. 그것이 TCP/IP에 정치적 지배를 부여한 투표도 아니었다. 그것은 하나의 구식 호환성 집합이 ARPANET에서 더 이상 일상적인 서비스로 남지 않게 된 지점이었다.

이 더 좁은 서술이 더 큰 의미를 지닌다. 기술적 변화가 어떻게 정당성을 얻는지 보여준다. 공용 규칙은 구현 가능해야 하고, 전환은 다리와 측정을 필요로 하며, 기한을 정하는 행위자는 경계를 통제하고 손실을 감당해야 하고, 권위는 그 책임이 끝나는 곳에서 끝나야 한다.

출처와 근거의 한계

전환의 아키텍처와 이정표는RFC 801에서 온다. 구식 메일 연속성 요구 사항은RFC 773에 있다. 공용 프로토콜 규칙은RFC 791과RFC 793이며,RFC 820은 당시의 더 넓은 프로토콜 환경을 기록한다.

서비스 수락 수치는RFC 847에서 온다. 그 자체의 경고들이 이를 컴플라이언스 인구조사로 다루는 일을 막는다. 운영 교훈은 RFC 942로 공표된 미국 국가연구위원회 보고서에서 온다. 시험 차단, IMP 거부 메커니즘, 마지막의 몇 가지 예외는 Vint Cerf의컴퓨터 역사 박물관 인터뷰에 근거를 둔다.

이 기사의 근거 묶음 어느 출처도 최종 예외 목록 전체, 네트워크 전체 장애의 정확한 지속 시간, 보편적 호스트 분모를 제공하지 않는다. 구술사의 날짜는 근사치다. 이 근거들은 계획되고 강제된 ARPANET 커트오버와 그 뒤를 따른 수개월의 운영적 수리를 뒷받침한다. 그러나 세계의 모든 네트워크가 TCP/IP를 채택했거나 인터넷이 시작된 단일한 순간을 뒷받침하지는 않는다.