요약

  • 컴퓨터 역사 박물관(Computer History Museum)의 기록은 Vint Cerf와 Robert Kahn을 1973년 서로 다른 패킷 네트워크 간 통신을 설계하려던 노력과 연결합니다. 1977년 3-네트워크 시연에 대한 동 기록은 배포 가능성이 단일 발명자가 아니라 여러 네트워크, 기관 및 구현자에 달려 있었음을 또한 분명히 합니다. [2] [3]
  • RFC 675는 Vinton Cerf, Yogen Dalal, Carl Sunshine을 1974년 12월 인터넷 전송 제어 프로그램(Internet Transmission Control Program) 명세의 공동 저자로 명명합니다. 이 문서는 이후 인터넷 프로토콜(Internet Protocol)과 전송 제어 프로토콜(Transmission Control Protocol) 사이로 나뉜 기능들을 하나로 결합했으므로, 불변의 최종 아키텍처가 아니라 중요한 설계 단계의 증거입니다. [1]
  • Jon Postel의 IEN 2는 인터네트워크 패킷 전달이 호스트에서의 종단 간 전송과 분리되어야 한다고 주장했습니다. Cerf의 IEN 48은 나중에 catenet 모델을 기술하면서 Louis Pouzin의 용어를 명시적으로 보존했습니다. 이 기록들은 설계 과정 내부의 수정, 불일치, 계승된 아이디어를 보여줍니다. [4] [5] [12]
  • IEN 98과 IEN 175는 BBN, UCLA, SRI, MIT, UCL, NDRE 등 여러 조직에 걸친 구현 활동을 명명합니다. 이 기록들은 출판만으로 인터네트워킹이 작동하게 되었다는 어떤 주장보다도 실행 코드, 게이트웨이, 호스트 소프트웨어와 실험을 우선에 둡니다. [6] [11]
  • RFC 790은 할당된 네트워크 및 프로토콜 번호를 공표했고, RFC 791과 RFC 793은 1981년 인터넷 프로토콜 및 전송 제어 프로토콜 명세를 문서화했습니다. 기록 계층은 고유성과 공통 참조를 제공했습니다. 운영자와 구현자는 여전히 그 참조를 실제 시스템에서 작동하게 만들어야 했습니다. [7] [8] [9]

문제는 하나의 네트워크가 아니라 여러 호환되지 않는 네트워크였다

패킷 네트워크는 정보를 스위칭 시스템을 통과할 수 있고 종단에서 재조립될 수 있는 단위로 나누어 정보를 이동시킵니다. 1970년대 초반까지 패킷 네트워킹은 하나의 균질한 환경이 아니었습니다. 프로젝트마다 패킷 형식, 주소 공간, 최대 크기, 전달 가정, 오류 보고 방식이 달랐습니다. 한 네트워크 안에서 작동하던 프로그램은 다른 네트워크가 같은 내부 언어를 사용한다고 단순히 가정할 수 없었습니다.

이 차이가 인터네트워킹 문제를 만들었습니다. 목표는 모든 기존 네트워크를 중앙 집중식 운영 시스템 하나로 대체하는 것이 아니었습니다. 개별적으로 설계된 네트워크들이 각 네트워크가 내부 메커니즘을 포기하지 않고도 연결된 호스트 간 트래픽을 운반하도록 하는 것이었습니다. 연결 설계에는 공통 패킷과 주소 지정 경계, 네트워크 간 트래픽을 이동시킬 게이트웨이, 결합된 경로에서 손실·중복·재정렬로부터 복구할 수 있는 호스트 소프트웨어가 필요했습니다.

컴퓨터 역사 박물관의 1973년 타임라인은 초기 TCP/IP 스케치를 Vint Cerf와 Robert Kahn에게 귀속시킵니다. 동 박물관의 더 넓은 인터넷 역사는 Kahn과 Cerf를 네트워크 간 설계 문제에 함께 두고 1973년 9월 발표를 확인합니다. [2] [3] 이것은 유용한 인물 수준 사실이지만, 기원 증명서는 아닙니다. 패킷 스위칭, 데이터그램, 호스트 프로토콜, 네트워크 상호연결에는 이미 미국과 유럽의 연구자와 프로젝트가 관여하고 있었습니다. 출처는 Cerf가 설계 노력에 참여했음을 확립할 뿐 아니라, 그 노력이 더 넓은 기술적 계승 안에 있음도 보여줍니다.

이 계승이 중요한 이유는 인터네트워킹이 발명만큼이나 경계 결정이었기 때문입니다. 연결된 네트워크들은 인터네트워크 패킷을 운반하면서 모든 내부 세부를 노출하지 않는 자율 시스템으로 다뤄질 수 있었습니다. 호스트들은 종단 간 통신의 책임을 질 수 있었습니다. 게이트웨이들은 네트워크 사이에서 전달할 수 있었습니다. 식별자는 한 로컬 네트워크 안에서만이 아니라 결합된 시스템 전반에서 의미를 가져야 했습니다. 각 선택은 네트워크 스위치, 게이트웨이, 호스트, 기록 공표자, 운영자 사이에서 작업과 권한을 이동시켰습니다.

따라서 설계는 종이 위에서만 평가될 수 없었습니다. 다이어그램은 패킷이 두 네트워크를 건널 수 있음을 보여줄 수 있지만, 실행 중인 구현은 패킷 크기, 재전송, 혼잡, 주소 지정 또는 호스트 동작이 경로를 막는다는 것을 드러냈습니다. 프로토콜 설명은 책임을 호스트에 부여할 수 있지만, 실험은 서로 다른 호스트 구현이 같은 필드를 다르게 해석한다는 것을 보여줬습니다. 인터네트워킹을 배포 가능하게 만든다는 것은 이러한 불일치를 경계를 수정할 수 있을 만큼 충분히 이르게 노출하는 것이었습니다.

Cerf는 공개 기록이 특정 문서와 역할을 확인해 주기 때문에 이 과정에서 유용한 실마리가 됩니다. 그러나 이 실마리를 소유권으로까지 늘려서는 안 됩니다. Robert Kahn은 초기 설계에서 여전히 중심입니다. Yogen Dalal과 Carl Sunshine은 여기서 검토하는 첫 상세 명세의 공동 저자로 명명되어 있습니다. Jon Postel은 분리 비판과 이후 명세 및 식별자 기록의 중심입니다. Louis Pouzin의 catenet 용어와 CYCLADES의 영향은 여전히 드러납니다. 여러 기관의 구현자들이 제안된 아키텍처를 확인하거나 거부할 수 있는 실행 시스템을 공급했습니다.

이러한 공로 분배는 기술 이야기 이후 덧붙인 정중함이 아닙니다. 그것은 기술 이야기 자체의 일부입니다. 독립적으로 운영되는 네트워크들을 연결하기 위한 설계는 한 사람의 권위만으로 신뢰를 얻을 수 없었습니다. 서로 다른 팀들이 구축할 수 있을 만큼 정확한 공통 인터페이스, 그리고 결과를 비교할 수 있을 만큼 정확한 공개 기록이 필요했습니다.

RFC 675는 주요 단계를 기록했지, 최종 프로토콜 경계를 기록하지 않았다

1974년 12월에 발표된 RFC 675는 Vinton Cerf, Yogen Dalal, Carl Sunshine을 저자로 명명합니다. [1] 이 문서는 인터넷 전송 제어 프로그램, 사용자 프로세스에 대한 인터페이스, 연결 처리, 개념적 구현을 기술합니다. 이것은 Cerf가 상세 프로토콜 명세에 참여했다는 직접 증거입니다. 동시에 그 작업이 명명된 공동 저자들과 공유되었다는 똑같이 직접적인 증거이기도 합니다.

이 명세는 인터네트워크 프로토콜을 통한 패킷 스위칭 네트워크 간 통신을 상상했습니다. 네트워크, TCP 및 포트 식별자로 소켓을 구성하고 그 결합을 연결된 네트워크 전반에서 통신 종단을 고유하게 만드는 방법으로 다뤘습니다. [1] 이 세부는 초기 번호 자원 문제를 드러냅니다. 한 기계나 한 네트워크 안에서 유용한 식별자는 독립 시스템들이 충돌 없이 같은 종단을 참조해야 할 때는 충분하지 않습니다.

RFC 675는 또한 전송 제어 프로그램에 상당한 책임을 부여했습니다. 연결 관리, 순서 번호, 승인, 재전송, 흐름 제어, 그리고 사용자·호스트·패킷 스위칭 네트워크 간 인터페이스를 기술했습니다. [1] 이 설계는 신뢰할 수 없는 이질적인 전달을 종단 간 프로세스에서 사용 가능하게 만들려 했습니다. 구현을 안내할 만큼 상세했지만, 결합된 범위가 최종 경계로 남지는 않았습니다.

익숙한 약어를 접하고 그것이 이미 오늘과 정확히 같은 의미라고 가정하는 독자에게 이 구분은 중요합니다. 1974년 문서의 TCP는 나중의 명세들이 나눈 기능들을 갖춘 인터네트워크 전송 제어 프로그램이었습니다. RFC 675를 현대의 완전한 TCP/IP 스위트로 다루면 아키텍처를 더 배포 가능하게 만든 수정들을 지워버리게 됩니다.

문서 자체도 불확실성을 보존합니다. 이것은 하나의 강제적인 내부 프로그램 배치를 주장하기보다는 개념적 데이터 구조와 가능한 구현 선택을 기술합니다. [1] 개별 구현이 사용자 호출 형식을 다르게 정의할 수 있음을 인정합니다. 이 유연성은 팀들이 서로 다른 시스템 위에 구축할 수 있게 했지만, 공유 경계에서의 명확한 동작에 대한 필요도 동시에 키웠습니다. 내부 자유는 외부 교환이 호환될 때만 실용적입니다.

보안과 신원은 후대의 장식이 아니라 운영상 관심사로 나타납니다. RFC 675는 연결을 사용할 권한 확인과 한 TCP가 다른 TCP로 위장하는 것을 피하는 문제를 논의합니다. [1] 이 용어는 그 시대에 속하며 현대적 보안 보장으로 다뤄질 수 없습니다. 그럼에도 고유 식별자와 인증된 책임이 이미 연결된 문제였음을 보여줍니다. 네트워크 식별자와 포트 구조는 종단을 명명할 수 있었습니다. 구현들은 또한 누가 그것을 통해 행동할 수 있는지를 강제해야 했습니다.

지속되는 교훈은 RFC 675의 모든 필드가 살아남았다는 것이 아닙니다. 공개 명세가 구현자들이 테스트할 수 있는 무언가를 만들었다는 것입니다. 결합된 경계가 불편하다는 것이 드러났을 때, 기록은 불일치를 구체화했습니다. 여러 팀이 소프트웨어를 만들 때, 그들의 동작을 같은 텍스트와 비교할 수 있었습니다. 출판은 조정 도구였지, 시스템이 이미 작동한다는 선언이 아니었습니다.

Cerf의 기여는 그 경계에서 정확하게 서술될 수 있습니다. 그는 Dalal, Sunshine과 함께 이 문서를 공동 집필했습니다. 이 문서는 초기의 상세한 인터네트워크 전송 설계를 기록합니다. 그것은 Cerf가 모든 구현을 썼거나, 모든 메커니즘을 발명했거나, 참여 네트워크를 통제했거나, 이후의 운영 결과를 개인적으로 만들어냈다는 것을 증명하지 않습니다.

Postel의 분리 비판은 수정을 아키텍처의 일부로 만들었다

Jon Postel의 IEN 2는 기능이 어디에 있어야 하는지에 도전하기 때문에 짧지만 중요한 기록입니다. 이 노트는 인터네트워크 패킷 전달을 종단 간 호스트 전송에서 분리하자고 주장했습니다. [4] 실무적으로 인터넷 계층은 상호연결된 네트워크를 가로질러 데이터그램을 이동시키고, 호스트 수준 전송 프로토콜은 응용이 요구할 때 프로세스 간 신뢰할 수 있는 통신을 제공합니다.

이 분리는 공통 패킷 전달 계층에 내장되어야 했던 상태와 동작의 양을 줄였습니다. 네트워크는 전송 연결의 모든 세부를 알 필요 없이 인터넷 데이터그램을 운반할 수 있었습니다. 호스트들은 공통 명세에 맞는 전송 동작을 구현할 수 있었습니다. 다른 전송 프로토콜은 나중에 원래 결합된 TCP의 모든 가정을 물려받지 않고 인터넷 계층을 사용할 수 있게 되었습니다.

이것은 미용적 이름 바꾸기 연습이 아니었습니다. 단편화, 신뢰성, 순서화, 연결 상태를 경계를 넘어 이동하면 어느 구성 요소가 실패를 관찰할 수 있고 어느 운영자가 수리해야 하는지가 바뀝니다. 게이트웨이가 종단 간 연결 상태를 유지하도록 되어 있다면 실패와 확장은 호스트가 그 상태를 유지하는 설계와 다르게 나타납니다. 인터넷 계층이 신뢰할 수 있는 스트림이 아닌 데이터그램을 제공한다면, 응용은 전달 동작을 별도의 전송 프로토콜에 의존하게 됩니다.

따라서 IEN 2는 이 글을 흔한 영웅 서사로부터 보호합니다. 프로토콜 스위트는 다른 사람들이 단순히 수용한 하나의 완성된 설계로 전해지지 않았습니다. 명명된 협력자이자 편집자가 결합 모델을 비판했고, 아키텍처는 바뀌었습니다. [4] Cerf의 문서화된 역할은 여전히 중요하지만, 그 수정은 권위가 설계가 기술적 검증과 구현 증거를 견딜 수 있는 능력에서 나왔음을 보여줍니다.

새 경계는 또한 기록을 더 중요하게 만들었습니다. 네트워크 전달, 전송, 응용 포트가 별개의 계층이 되자, 각각은 독립 구현들이 일관되게 해석할 수 있는 식별자와 프로토콜 번호를 필요로 했습니다. 필드 값은 교환의 양쪽에서 같은 의미를 가져야 했습니다. 이 요구 사항은 아키텍처적 분리를 나중에 논의되는 할당 번호 대장에 연결합니다.

이 과정은 문서를 폐하며 실행 코드 우위를 보여줍니다. 이 노트는 개념적 비판을 읽을 수 있게 만들었습니다. 구현과 실험은 제안된 분리가 도움이 되었는지를 드러냈습니다. 수정된 명세는 새 공유 경계를 고정했습니다. 문서는 독립적으로 운영되는 시스템들이 같은 합의를 기준으로 구축하고 테스트할 수 있게 해주었기 때문에 중요했습니다. 문서가 테스트를 대신하지는 않았습니다.

정확한 귀속은 기술적 책임성도 향상시킵니다. 분리 비판을 다룰 때는 Postel의 이름을 붙여야 합니다. 그의 문서와 프로그램 역할이 뒷받침되는 곳에는 Cerf의 이름을 붙여야 합니다. Kahn, Dalal, Sunshine, Pouzin, 구현 팀들은 각자의 기여에 계속 붙어 있어야 합니다. 그들을 단일 발명자로 축소하면 시스템이 왜 배포 가능해졌는지를 설명하는 불일치와 검증의 그 과정 자체를 없애버립니다.

Catenet은 자율성을 보존하면서 공통 데이터그램을 요구했다

Cerf의 IEN 48은 catenet 모델, 즉 호스트들이 그 가로질러 통신할 수 있도록 결합된 패킷 네트워크들의 모음을 기술했습니다. [5] 이 노트는 Louis Pouzin의 catenet 용어를 명시적으로 보존했고, 인터넷 명예의 전당(Internet Hall of Fame)의 Pouzin 프로필은 CYCLADES와 데이터그램의 영향에 대한 독립적인 경계를 제공합니다. [12] 이 귀속이 중요한 이유는 그 개념이 지적 진공 속에서 생겨난 것이 아니기 때문입니다.

catenet 모델은 참여 네트워크들을 그 자체로 네트워크로 다뤘습니다. 그들은 게이트웨이와 호스트 사이에서 공통 인터네트워크 데이터그램을 운반하면서 내부 스위칭 방식과 로컬 행정을 유지할 수 있었습니다. 공통 계층은 모든 네트워크의 내부 세부를 재현할 필요가 없었습니다. 종단을 식별하고 패킷을 결합된 경로를 통해 이동시키기에 충분한 정보만 필요했습니다.

자율성은 단일 글로벌 네트워크 운영자에 대한 수요를 줄였지만 조정을 없애지는 않았습니다. 게이트웨이는 공통 패킷을 이해해야 했습니다. 호스트들은 호환되는 프로토콜 구현을 필요로 했습니다. 네트워크 식별자와 프로토콜 값은 고유성을 유지해야 했습니다. 패킷 크기와 단편화 동작에는 명확한 규칙이 필요했습니다. 경로가 실패할 때 운영자는 로컬 네트워크 문제인지, 게이트웨이·호스트·종단 간 전송 문제인지를 구분해야 했습니다.

그래서 자율성과 정확한 기록은 같은 계정에 속합니다. 네트워크는 공유 식별자가 그 네트워크를 넘어서도 해석 가능하게 유지될 때만 자체 내부 결정을 내릴 수 있습니다. 레지스트리나 할당 번호 문서는 그 식별자들을 기록합니다. 그것은 네트워크를 소유하거나 운영 선택을 강제하지 않습니다. 그 권한은 더 좁고 더 유용합니다. 독립 구현들이 서로 호환되지 않는 목적에 같은 값을 사용하지 않을 만큼 대장을 정확하게 유지하는 것입니다.

catenet 개념은 또한 연속성이 분배된 결과임을 드러냅니다. 어떤 중앙 논문도 모든 참여 네트워크가 계속 이용 가능하다고 보장할 수 없습니다. 한 네트워크, 게이트웨이 또는 호스트 구현이 실패하면, 공통 명세가 정확하더라도 종단 간 경로는 실패할 수 있습니다. 운영자는 실행 시스템에서 오는 라우팅과 테스트 증거를 필요로 합니다. 기록은 기대되는 구성 요소를 명명하는 데 도움을 줍니다. 관찰은 어느 구성 요소가 실제로 작동했는지를 보여줍니다.

Cerf의 IEN 48 저자십은 제한된 인물 수준 결론을 지지합니다. 그는 이 모델을 문서화하고 용어 경계를 계승했습니다. [5] 그가 데이터그램을 발명했거나 CYCLADES를 통제했거나 모든 게이트웨이를 운영했거나 개인적 결정으로 catenet을 신뢰 가능하게 만들었다는 주장까지 허용하지 않습니다. 공개 기여는 설계를 집단적 구현과 수정을 위할 만큼 읽을 수 있게 만드는 데 있습니다.

실행 코드가 저자십을 여러 기관에 분배했다

IEN 98은 BBN, UCLA, SRI, NDRE, MIT 등 여러 조직의 구현 보고서를 나열했습니다. [6] IEN 175는 나중에 많은 구현자들, 게이트웨이 문제, 주소 지정 질문, 성능 관심사, 참여 기관들과의 회의를 기록했습니다. [11] 이 출처들은 유명 인물 요약이 할 수 없는 방식으로 구현 계층을 보이게 만듭니다.

각 구현 팀은 서로 다른 로컬 환경에서 작업했습니다. 호스트 운영 체제는 자신의 프로세스 및 메모리 모델에 맞는 인터페이스를 필요로 했습니다. 게이트웨이는 각자의 최대 패킷 크기와 타이밍 동작을 지닌 패킷 네트워크들을 연결했습니다. 패킷 라디오 경로는 위성 또는 유선 ARPANET 경로와 정확히 같지 않았습니다. 로컬 테스트를 통과한 소프트웨어는 반대편의 다른 구현을 만났을 때 실패할 수 있었습니다.

따라서 기관 목록은 단순한 배경 이상입니다. 배포 가능성이 독립적 시도를 필요로 했다는 증거입니다. 하나의 코드베이스만 설계를 구현했다면, 코드와 문서 사이의 일치는 한 팀의 가정을 반영했을 수 있습니다. 여러 구현은 모호한 필드와 암묵적 의존성을 노출했습니다. 그들 사이의 교환은 명세가 실제로 공유 경계를 정의했는지를 드러낼 수 있었습니다.

컴퓨터 역사 박물관의 1977년 시연 기술은 3-네트워크 환경을 가로지르는 전송을 묘사합니다. [2] 이 사건은 흔히 "TCP/IP가 작동했다"는 증명으로 압축됩니다. 더 정확한 해석은 더 좁습니다. 그것은 사람, 네트워크, 게이트웨이, 호스트 소프트웨어의 집합이 테스트된 조건 아래에서 이질적인 패킷 시스템을 가로질러 트래픽을 운반할 수 있었다는 것을 보여줬습니다. 그것은 보편적 신뢰성, 보안, 성능 또는 모든 호스트를 위한 준비 상태를 증명하지 않았습니다.

Cerf와 Kahn은 설계와 시연 기술에서 그들의 역할로 공로를 인정받을 수 있습니다. 조직과 구현자들은 실행 시스템에 대한 공로를 인정받아야 합니다. 인물 수준 글은 Cerf의 문서화된 실마리가 설계와 프로그램 조정을 연결하기 때문에 여전히 유용하지만, 결과는 작업의 네트워크에 속합니다.

이 경계는 운영적 진실을 보호합니다. 명세의 저자는 그 문서의 주장과 인터페이스에 대해 책임집니다. 구현자는 코드 경로와 그 동작에 대해 책임집니다. 네트워크 운영자는 경로, 기계, 로컬 결정에 대해 책임집니다. 프로그램 관리자는 목표와 자원을 조정할 수 있습니다. 이 역할들은 상호작용합니다. 한 이름이 더 잘 알려져 있다고 서로 교환 가능해지지는 않습니다.

구현 보고서는 또한 결함과 불일치의 차이를 드러냅니다. 프로그램은 명세를 정확히 해석하면서 코딩 오류를 포함할 수 있습니다. 두 개의 올바른 로컬 해석은 텍스트가 모호하기 때문에 불일치할 수 있습니다. 게이트웨이는 설계를 따르면서 기반이 되는 네트워크가 패킷을 잃을 수 있습니다. 수리에는 계층을 식별하는 것이 필요하지, 모든 실패를 프로토콜의 가장 잘 알려진 기여자에게 귀속시키는 것이 아닙니다.

공개 구현 기록은 이 진단을 가능하게 합니다. 그것들은 논의 중인 시스템과 문제를 명명합니다. 나중의 독자들이 문제가 알려져 있었고 수정이 집단적이었음을 볼 수 있게 합니다. 그것들은 기술적 리더십에 대한 더 현실적인 정의도 제공합니다. 조정이 모든 참여 시스템의 소유권을 부여한다고 가장하지 않으면서 문제가 보고, 비교, 수정될 수 있는 조건을 만드는 것입니다.

할당 번호는 고유성을 공유 인프라로 만들었다

아키텍처가 네트워크 전달을 전송 및 응용 동작에서 분리하면서, 숫자 필드가 더 많은 의미를 실어나르게 되었습니다. 구현들은 네트워크 번호, 프로토콜 번호, 포트 및 관련 식별자에 대해 합의해야 했습니다. 두 독립 팀이 같은 값을 다른 의미에 할당하면, 두 프로그램 모두 자신의 로컬 문서를 따르더라도 패킷이 잘못 해석될 수 있었습니다.

Jon Postel이 편집한 RFC 790은 인터넷 프로토콜 환경을 위한 할당 번호를 공표했습니다. [7] 그 가치는 문서가 네트워크를 실행할 수 있다는 것이 아니었습니다. 그 가치는 독립 구현자들이 공통 대장을 참조할 수 있다는 것이었습니다. 이 기록은 번호를 정의된 사용에 연결하고 우연한 충돌을 줄였습니다.

대장 역할은 신중하게 서술되어야 합니다. 할당을 공표하는 것은 모든 구현이 그것을 정확히 사용한다는 것을 증명하지 않습니다. 모든 경로가 할당된 네트워크에 도달한다는 것을 보여주지 않습니다. 기록 공표자를 기반이 되는 기계나 주소의 소유자로 만들지 않습니다. 그것은 운영자가 실행 중인 구성과 비교할 수 있는 고유성, 정확성, 공유 참조를 제공합니다.

이것은 실용적인 형태의 권위입니다. 번호 레지스트리는 그 번호를 사용하는 모든 네트워크의 주권이 되지 않으면서 자신의 기록 상태에 대해 권위적일 수 있습니다. 기록이 잘못되거나 지연되거나 모호하면, 독립 시스템들은 충돌할 수 있습니다. 기록이 정확하더라도, 그들에게는 여전히 작동하는 코드와 운영 연속성이 필요합니다. 기록 계층과 현실 계층은 서로를 지지하지만 별개로 남습니다.

번호 대장은 감사 추적도 만듭니다. 프로토콜을 구현하는 팀은 사용한 값을 인용할 수 있습니다. 검토자는 코드 또는 패킷 캡처를 공표된 할당과 비교할 수 있습니다. 이후 수정은 주어진 시점에 어느 값이 무엇을 의미했는지를 보존할 수 있습니다. 이 역사는 변경이 마치 옛 의미가 존재하지 않았던 것처럼 다뤄질 가능성을 줄입니다.

이야기의 이 부분에서 Cerf의 역할은 간접적이고 제한적입니다. 그의 초기 명세 작업에는 주소 지정 모델이 포함되었고, 그의 프로그램 역할은 더 넓은 인터넷 노력에 속했습니다. [1] [10] RFC 790 자체는 Postel의 기록이므로 그에 맞게 공로를 인정해야 합니다. [7] 이 구분을 유지하는 것이 글을 강화합니다. 아키텍처에는 프로토콜 설계와 규율 있는 기록 관리, 그 둘이 필요했고, 그것들은 서로 다른 사람과 기관이 공급했습니다.

같은 구분은 현대 번호 자원 논쟁에서도 유용합니다. 고유 식별자, 정확한 기록, 이전 또는 할당 이력, 보안 메타데이터, 운영 연속성은 구체적 필요입니다. 커뮤니티 언어나 기관적 지위는 그것들을 대체하지 않습니다. 레지스트리는 그 대장이 운영자들의 조정을 돕고, 그 기록이 네트워크들이 실제로 광고하고 사용하는 것과 조정될 수 있을 때 실용적 신뢰를 얻습니다.

1981년 명세는 더 명확한 작업 분할을 고정했다

1981년 9월에 발표된 RFC 791과 RFC 793은 DARPA 인터넷 프로그램 아래의 인터넷 프로토콜과 전송 제어 프로토콜 명세를 문서화했습니다. [8] [9] 이 별개 문서들은 더 이른 결합 설계가 아직 같은 형태로 표현하지 못했던 아키텍처적 분리를 구현합니다.

인터넷 프로토콜은 상호연결된 네트워크를 가로지르는 데이터그램 서비스를 제공했습니다. 패킷에 주소를 부여하고 신뢰할 수 있는 종단 간 전달을 약속하지 않으면서 패킷이 어떻게 전달되고 단편화될 수 있는지를 기술했습니다. 전송 제어 프로토콜은 인터넷 프로토콜을 사용하는 종단들 사이의 신뢰할 수 있고 순서화된 바이트 스트림 서비스를 제공했습니다. 이 분할은 다른 전송 프로토콜이 인터넷 계층을 사용하게 하고 모든 게이트웨이가 전송 연결 책임을 지는 것을 막았습니다.

운영자에게 이 분리는 더 명확한 진단 질문을 만들었습니다. 호스트가 데이터그램을 올바르게 만들었는가? 목적지 주소가 유효했는가? 게이트웨이가 전달했는가? 단편화가 처리되었는가? TCP가 상태를 만들고 데이터를 승인하고 필요할 때 재전송했는가? 실패한 응용 교환에 여러 계층이 관여할 수 있었지만, 명세는 각 계층에 더 정확한 계약을 부여했습니다.

이 문서들은 저자십을 한 사람에게 귀속시키는 것이 왜 부정확한지도 보여줍니다. Postel은 인터넷 프로토콜 명세의 편집자이자 TCP 명세 기록의 저자로 확인되지만, 이 문서들은 DARPA 프로그램과 더 긴 집단 설계 역사 안에 있습니다. [8] [9] Cerf의 더 이른 작업과 프로그램 역할은 중요하지만, 1981년의 모든 필드를 그의 개인적 텍스트나 결정으로 만들지는 않습니다.

이것은 Cerf의 강등이 아닙니다. 그의 기여에 대한 더 유용한 계정입니다. 그는 설계 아이디어가 공표되고, 비판받고, 구현되고, 수정되는 과정에서; 명명된 동료들이 특정 문서를 집필하는 과정에서; 기관적 메커니즘이 공통 명세를 보존하는 과정에서 나타납니다. 배포 가능한 시스템에는 그러한 책임의 분배가 필요했습니다.

1981년 공표는 여전히 배포를 완료하지 않았습니다. 명세는 규격 구현이 무엇을 해야 하는지를 정의할 수 있지만, 호스트는 소프트웨어를 설치하고, 운영자는 시스템을 구성하고, 게이트웨이는 트래픽을 전달하고, 조직은 전환을 일정에 넣어야 합니다. 다음 운영 단계에는 마이그레이션 계획과 1983년 1월 전환이 포함되지만, 그 단계는 이 글의 증거 엔진이 아닙니다. 그것은 강제, 예외, 거버넌스에 대한 별도의 계정에 속합니다.

주요 기술적 흐름을 1981년에서 끝내는 것은 새 논지를 보존합니다. 이 글은 인터네트워킹이 경계 수정, 공유 식별자, 다자간 실행 코드를 통해 어떻게 구현 가능해졌는지에 관한 것입니다. 이것은 나중에 옛 프로토콜을 끄기 위해 필요한 권위에 대한 또 다른 이야기도, 표준화 이후 Cerf에 대한 또 다른 전기도 아닙니다.

Cerf의 프로그램 역할은 주권적 통제가 아니라 조정이었다

1990년에 공표된 회고적 역사인 RFC 1160은 Cerf를 제한된 DARPA 프로그램 관리자 맥락에서 확인하고, 인터넷 구성 제어 위원회(Internet Configuration Control Board), 이후의 조직 변화와 인계를 기술합니다. [10] 이 출처는 프로토콜 개발을 프로그램 구조와 연결하면서 동시에 프로그램 역할이 영구적 개인 권위가 되는 것을 막기 때문에 유용합니다.

프로그램 관리자는 목표를 설정하고, 연구를 지원하고, 구현자들을 소집하고, 우선순위 해결을 도울 수 있습니다. 이 행동들은 프로토콜이 논문을 넘어 발전하는지에 실질적으로 영향을 미칩니다. 자금과 실험을 공유 목표 주위로 정렬할 수 있습니다. 그러나 그것들은 관리자를 모든 네트워크의 운영자, 모든 구현의 저자, 모든 이후 기관적 결정의 근원으로 만들지 않습니다.

인계 증거는 특히 중요합니다. 기술 시스템은 책임이 이동할 수 있을 때만 개인의 역할보다 오래 지속됩니다. 명세는 공개 참조가 됩니다. 식별자 대장은 내구 있는 기관에 의해 유지될 수 있습니다. 구현 지식은 팀들 사이에 퍼집니다. 운영 통제는 호스트, 게이트웨이, 네트워크를 운영하는 조직에 남습니다. 프로그램 구조는 영구적 주권이 되지 않으면서 작업을 가속할 수 있습니다.

이 분리는 아키텍처를 반영합니다. 인터네트워킹은 중앙 집중식으로 운영되는 하나의 네트워크로 대체하는 대신 공통 인터페이스를 통해 자율 네트워크들을 연결했습니다. 작업의 거버넌스도 유사하게 공통 기록, 프로그램 조정, 이후 기관적 과정에 의존했으며, 한 사람에게 모든 참여 시스템의 통제를 주지 않았습니다.

따라서 Cerf의 프로그램 역할은 인물 수준의 네트워크 기여로 서술될 수 있습니다. 그것은 연구, 구현, 공유 명세를 연결하는 데 도움을 주었습니다. 기여는 사적 동기나 보편적 인과를 발명하지 않고도 귀속될 수 있습니다. 공개 문서는 역할과 과정을 보여줍니다. 그것들은 모든 로컬 팀이 Cerf의 지시를 따랐거나 모든 결과가 하나의 결정에서 나왔다는 것을 보여주지 않습니다.

리더십은 경계가 명시적일 때 종종 더 강합니다. 상호운용 가능한 실험을 지원하는 관리자는 독립 구현들이 생산적으로 불일치할 수 있게 만듭니다. 고유 할당을 보존하는 기록 공표자는 운영자들이 자신의 시스템을 내주지 않고 조정할 수 있게 만듭니다. 수정을 수용하는 표준 편집자는 기술적 권위가 평판이 아니라 검증 가능한 문서에 의존하게 만듭니다.

Cerf의 기록은 그 분배된 패턴에 부합합니다. 그 가치는 다른 사람들이 테스트하고 계속할 수 있는 과정에 대한 문서화된 참여에서 옵니다. 이 작업이 인프라가 된 것은 정확히 그것이 한 경력에 붙은 사적 설계로 남지 않았기 때문입니다.

배포 가능성은 창립 라벨이 아니라 증거의 사슬이다

여기서 검토한 출처들은 사슬을 이룹니다. 컴퓨터 역사 박물관은 Cerf와 Kahn을 1973년 네트워크 간 설계 문제와 이후 시연에 놓습니다. [2] [3] RFC 675는 Cerf, Dalal, Sunshine이 공동 집필한 상세한 1974년 명세를 기록합니다. [1] IEN 2는 Postel의 분리 비판을 기록합니다. [4] IEN 48은 Cerf의 catenet 모델과 Pouzin 경계를 기록합니다. [5] IEN 98과 IEN 175는 다기관 구현 활동을 기록합니다. [6] [11] RFC 790은 할당 번호를 기록하고, RFC 791과 RFC 793은 1981년 프로토콜 분할을 기록합니다. [7] [8] [9] RFC 1160은 제한된 기관적 인계 계정을 제공합니다. [10]

그 사슬의 어떤 고리도 그것만으로는 충분하지 않습니다. 역사적 타임라인은 정확한 프로토콜 계약을 공급할 수 없습니다. 명세는 독립 코드가 상호운용했다는 것을 증명할 수 없습니다. 구현 보고서는 식별자 충돌을 없앨 수 없습니다. 할당 번호 기록은 실제 시스템이 값을 정확히 사용한다는 것을 보장할 수 없습니다. 프로그램 역할은 로컬 운영자를 대체할 수 없습니다.

함께, 이 기록들은 아키텍처가 어떻게 배포 가능해지는지를 보여줍니다. 문제가 틀 안에 놓입니다. 공유 설계가 공표됩니다. 비판이 책임을 더 나은 계층으로 옮깁니다. 여러 팀이 코드를 만듭니다. 실험은 불일치를 노출합니다. 식별자 기록이 고유성을 보존합니다. 수정된 명세가 경계를 안정시킵니다. 기관과 운영자가 작업을 원래 프로그램 너머로 나릅니다.

이 증거 사슬은 "인터넷의 아버지"라는 표현보다 더 유익합니다. 창립 라벨은 협력과 수정을 지위로 압축합니다. 사슬은 누가 무엇을 했는지, 어느 문서가 주장을 뒷받침하는지, 무엇이 아직 증명되지 않았는지를 보존합니다. 독자가 기술적 과잉 없이 Cerf의 기여에 대한 존중을 가질 수 있게 합니다.

이 접근은 현재의 운영적 추론도 보호합니다. 오늘 네트워크가 실패할 때, 유명한 기원 이야기는 끊긴 경로, 부정확한 기록, 호환되지 않는 구현 또는 누락된 보안 메타데이터를 식별하지 않습니다. 운영자에게는 역사적 과정에서 보이는 것과 같은 범주가 필요합니다. 경계, 식별자, 구현, 관찰, 책임 있는 로컬 행위자.

따라서 배포 가능성은 설계가 공식화되는 순간이 아닙니다. 그것은 독립 시스템들이 같은 패킷을 해석하고, 충돌 없이 식별자를 사용하고, 실패를 관찰하고, 구현을 수정하는 축적되는 능력입니다. 공개 기록은 그 능력을 고정하고, 실행 코드와 운영 네트워크가 그 현실을 공급합니다.

출처

  1. RFC Editor,RFC 675: Specification of Internet Transmission Control Program.
  2. Computer History Museum,1973 타임라인.
  3. Computer History Museum,인터넷 역사: 1970년대.
  4. RFC Editor History,IEN 2.
  5. RFC Editor History,IEN 48.
  6. RFC Editor History,IEN 98.
  7. RFC Editor,RFC 790: Assigned Numbers.
  8. RFC Editor,RFC 791: Internet Protocol.
  9. RFC Editor,RFC 793: Transmission Control Protocol.
  10. RFC Editor,RFC 1160: Internet Activities Board.
  11. RFC Editor History,IEN 175.
  12. Internet Hall of Fame,Louis Pouzin.
  13. Wikimedia Commons,Vint Cerf 사진, Joi (Jōichi Itō), 2005년 7월 14일, CC BY 2.0.