요약

  • Ginny Strazisar는 초기 BBN 게이트웨이 소프트웨어를 작성하여 이기종 네트워크 경계에 걸쳐 설치했습니다. 유명한 3개 네트워크 전송이 실행되기 전에 코드, PDP-11 하드웨어, 로컬 인터페이스가 조율되어야 했습니다.
  • 남아 있는 기록은 아키텍처와 운영상의 실증을 구분합니다. 논쟁이 있는 데모 날짜, 준비되었지만 실제로 통과되지 않았을 수 있는 사이트, 집단적 저작, 그리고 이후 연구 코드에서 제한된 큐와 관측 가능한 게이트웨이 운영으로의 전환을 문서화합니다.

오슬로에서 미래의 인터넷은 잠시 사라진 기계 하나에 의존했습니다. Ginny Strazisar는 회의 후 게이트웨이 소프트웨어를 설치하러 도착했지만 하드웨어가 준비되지 않았습니다. 그녀는 노르웨이 연구자 Paal Spilling과 함께 머물렀고, 노르웨이의 다른 곳을 여행한 뒤, PDP-11이 마침내 프로그램을 받을 수 있게 되었을 때 돌아왔습니다. 그녀의 후기 구술 역사에서 이 일화는 극적 긴장보다 애정으로 회상됩니다. 그러나 여기에는 초기 인터넷워킹의 실용적 핵심이 담겨 있습니다. 프로토콜은 하드웨어, 인터페이스, 코드, 사람이 같은 장소에서 만나야만 경계를 넘을 수 있었습니다.

이것은 패킷이 이동 중인 밴을 떠나 패킷 라디오, ARPANET, 위성 네트워크를 거쳐 캘리포니아의 호스트로 돌아오는 익숙한 도식과는 다른 기원 이야기입니다. 그 도식은 경로를 보여줍니다. Strazisar의 작업은 그 전제 조건을 드러냅니다. 패킷이 이동하기 전에 게이트웨이 소프트웨어가 먼저 이동해야 했습니다.

Strazisar는 1975년 4월 Bolt Beranek and Newman에 합류했습니다. 그녀는 곧 네트워크를 연결하는 기계인 "게이트웨이" 작업을 시작했다고 말했습니다. 게이트웨이는 이미 BBN의 실험용 Resource Computer Network를 ARPANET에 연결하고 있었습니다. 이후 그녀는 ARPANET과 Packet Radio Network 간, 그리고 ARPANET과 Atlantic Satellite Network 간 연결을 작업했습니다. Computer History Museum은 그녀를 등장하는 TCP/IP 프로토콜을 위한 최초의 인터넷워킹 라우터 소프트웨어의 저자로 묘사합니다. 당시 "라우터"는 아직 통상적인 명칭이 아니었습니다.

"연결된 네트워크"라는 표현은 이 일을 균일한 케이블 작업처럼 들리게 할 수 있습니다. 실제로는 정반대였습니다. 패킷 라디오는 이동성, 변하는 무선 경로, 간헐적인 테스트베드 가용성을 다뤘습니다. ARPANET은 자체 호스트 및 인터페이스 관례를 갖고 있었습니다. SATNET은 바다를 건너 지리적으로 분리된 장비와 운영자에 의존했습니다. 인터넷워킹이 중요했던 이유는 바로 그 네트워크들이 서로의 복제품으로 재설계되지 않았기 때문입니다.

물리적 배치는 그 이질성을 반영했습니다. Strazisar는 패킷 라디오 국 코드와 게이트웨이 코드가 하나의 PDP-11을 공유했다고 회상했습니다. 위성 경계에서는 게이트웨이들이 별개의 PDP-11이었고, 한쪽은 ARPANET과, 다른 쪽은 위성 네트워크와 통신했으며 소프트웨어가 그들 사이에서 패킷을 전달했습니다. 이것은 모든 랙에 변경 없이 놓이는 단일 범용 장치가 아니었습니다. 공통의 인터넷워킹 기능은 서로 다른 로컬 메커니즘 위에서 구현되어야 했습니다.

그녀의 설치 연대기는 이 의존성을 보여줍니다. 그녀의 회상에 따르면 1976년 여름 BBN, 1976년 12월 런던, 1977년 여름 노르웨이에 작업을 설치했습니다. 하드웨어와 소프트웨어는 별개의 책임이었으므로, 출장은 기계 인도와 인터페이스 준비 상태와 조율되어야 했습니다. 런던의 기계는 그녀의 소프트웨어 방문보다 먼저 도착했습니다. 오슬로의 지연은 그 순서를 깨뜨렸고 재방문을 강요했습니다. 아키텍처적 높이에서 묘사된 프로그램은 일련의 사이트 준비 결정이 되었습니다.

초기의 실증은 단계적으로 이루어졌습니다. Computer History Museum 잡지는 1976년 여름에 진행된 패킷 라디오 실험을 설명하는데, 그 실험은 Strazisar의 양방향 ARPANET 게이트웨이 소프트웨어를 담은 국에서 무선 한 홉 거리에 머물렀습니다. 같은 잡지는 의식적인 2개 네트워크 전송을 1976년 8월 27일로 표기합니다. 더 어려운 데모는 1977년에 세 가지 물리적 종류의 네트워크를 연결했습니다. 박물관의 후기 기록은 데이터가 이동 중인 밴을 통해 베이 에어리어를 지나 대서양 횡단 인프라를 거쳐 USC로 흐르는 것을 묘사합니다.

이 유명한 사건조차 하나의 세련된 날짜로 정리되지 않습니다. 박물관의 2017년 에세이는 데모가 1977년 11월 22일 수요일에 진행되었다고 합니다. 2002년 잡지는 3개 네트워크 도식을 11월 27일로 표기합니다. 출처들은 또한 배치 지리와 패킷 지리를 구분합니다. Strazisar는 노르웨이에 소프트웨어를 설치했지만, Vint Cerf는 구술 역사 토론에서 데모 트래픽이 실제로 노르웨이에 진입하지 않았으며, 실제로 사용된 게이트웨이들은 다른 위성 링크와 연관되어 있었다고 회상했습니다. 준비된 사이트가 사용된 경로의 증거는 아닙니다.

이 구분은 유치한 세심함이 아닙니다. 인프라 역사에서는 성공적인 종단 간 교환이 모든 구성 요소, 사이트, 우발 상황이 작동했다는 증거로 변하기 쉽습니다. 실제로 데모는 한 시점의 한 구성에서 하나의 경로를 검증합니다. 설치는 하드웨어와 소프트웨어가 함께 놓였음을 증명할 뿐입니다. 어느 하나만으로도 페일오버, 지속 가용성 또는 사용되지 않은 인터페이스의 행동을 증명하지 못합니다.

이것은 한 명의 프로그래머의 성과도 아니었습니다. 박물관은 8개 기관에 걸쳐 35명이 넘는 참여자를 나열합니다. 별도로 박물관은 TCP 개념은 Bob Kahn과 Vint Cerf에게, 클라이언트는 Jim Mathis와 Dave Retz에게, 서버는 Ray Tomlinson과 Bill Plummer에게, 패킷 라디오 및 위성 작업은 SRI, Collins Radio, Linkabit, BBN, UCL, 노르웨이 국방연구소의 팀들에게, 그리고 게이트웨이 부문에서 Strazisar에게 공을 돌립니다. 그 시스템 안에 놓을 때 그녀의 기여는 작아지지 않고 더 명확해집니다. 그녀는 양쪽의 모든 네트워크를 소유하지 않으면서 하나의 경계를 소유했습니다.

게이트웨이 기록은 데모 이후에도 이어졌습니다. RFC 823은 그 설계가 처음에 IEN 30,Gateway Routing: An Implementation Specification으로 문서화되었고, 이후 Strazisar의 IEN 109,How to Build a Gateway로 문서화되었다고 기록합니다. RFC 823은 V. Strazisar, M. Brescia, E. Rosen, J. Haverty에게 특별한 공을 돌립니다. 이 순서가 중요한 이유는, 작동하는 산출물이 다른 구현자와 운영자가 검토할 수 있는 서면 기록을 축적했기 때문입니다.

IEN 30은 구현 세부 사항이 무엇을 보장할 수 없는지에 대해 특이할 만큼 솔직합니다. 이 문서는 구축할 수 있을 만큼 충분히 라우팅 알고리즘을 상세히 규정하고 실패한 구성 요소 주변으로 경로를 우회하는 것을 목표로 합니다. 그러나 분석만으로 게이트웨이가 항상 올바르게 라우팅할 것임이나 어떤 목적지도 무기한 미전달을 겪지 않을 것임을 증명할 수 없다고 명시합니다. 취약성은 실험과 실제 운영 사용 이후에만 나타날 수 있습니다. 또한 알고리즘 실패와 구현 실패를 구분합니다. 라우팅 정보는 손상될 수 있고, 하드웨어나 소프트웨어는 오작동할 수 있으며, 올바른 알고리즘도 잘못 코딩될 수 있습니다.

RFC 823은 다음 전환을 기록합니다. 초기 게이트웨이 소프트웨어는 ELF 운영체제와 함께 BCPL을 사용했고, 더 나은 성능을 위해 MOS로 이동했습니다. 1981년 말까지 프로그램은 연구 테스트베드가 아닌 운영 통신 시설을 위한 새 구현을 만들고 있었습니다. 재작성은 버퍼와 모니터링을 위한 공간을 확보하기 위해 MACRO-11을 사용했습니다. 언어와 운영상의 변화에도 불구하고 RFC는 아키텍처가 근본적으로 동일하게 유지되었다고 말합니다.

따라서 운영화는 프로토타입이 완성되었다고 선언하는 것을 의미하지 않았습니다. 한계를 관측 가능하게 만드는 것이었습니다. 문서화된 게이트웨이는 각 인터페이스의 출력 큐를 제한하여 느린 네트워크가 모든 버퍼를 소비하지 못하게 했습니다. 패킷을 큐에 넣을 수 없을 때 시스템은 그것을 폐기하고 모니터링 트랩을 보냈습니다. 운영자는 인터페이스 상태, 이웃, 도달 가능한 네트워크, 처리량, 폐기 사유를 검사할 수 있었습니다. RFC 823은 자신을 사양이 아닌 현재 구현의 스냅샷이라고 불렀습니다. 배포된 버전을 영구적인 계약과 혼동하지 말라는 경고였습니다.

Strazisar의 여정은 현대의 정확한 시험 기준을 남깁니다. 플랫폼이 이기종 네트워크를 연결한다고 주장할 때, 각 경계에서 실행되는 빌드, 그것이 기대하는 하드웨어와 드라이버, 실제로 사용된 인터페이스, 폐기 항목을 드러내는 텔레메트리를 요구하십시오. 제어 평면 도식은 의도의 증거입니다. 성공한 패킷은 하나의 경로의 증거입니다. 반복 가능한 배포와 실패 관측은 그 경계를 운영할 수 있다는 증거입니다.

게이트웨이 코드가 패킷보다 먼저 이동한 이유는 상호운용성이 지리를 갖기 때문입니다. 그것은 기계, 배포 매체, 로컬 케이블링, 사이트 일정, 인터페이스가 단순히 설치된 것인지 입증 가능하게 작동하는 것인지 판단할 수 있는 사람들 속에 존재합니다. 추상화가 인터넷을 가능하게 했습니다. 설치 작업이 그 추상화를 실제로 만들었습니다.

출처