요약

  • RFC 1025는 호환성을 관찰 가능한 교환들의 집합으로 만들었습니다: 연결 열기, 데이터 전달, 연결 닫기, 리셋 없이 반복하기, 그리고 게이트웨이를 통해 다른 구현물에 도달하기.
  • 이 점수 체계는 유용한 증거를 정리했지만, 통과 점수가 보편적인 정확성, 성능 순위, 배포 증명이 되도록 하지는 않았습니다.

정확성은 여전히 논쟁의 대상이었다

1987년 9월, Jon Postel은 소프트웨어와 규격이 모두 발전 중이던 시기에 TCP와 IP가 어떻게 시험되었는지를 이례적으로 솔직하게 담은 짧은 문서를 발표했습니다. 구현물이 거의 없던 시절, RFC 1025에 따르면 어떤 것이 ‘정확한’지 판단하는 실용적 방법은 다른 것과 대결해보고 실제로 일어난 일을 근거로 논쟁하는 것이었습니다. 시험은 구현물을 바꿀 수 있었습니다. 논의는 규격 자체를 바꿀 수도 있었습니다.

이 문장은 현대의 인증 실험실과는 다른 위치에 베이크오프를 놓아줍니다. 검증 대상은 완성된 규정집 앞에 놓인 봉인된 제품이 아니었습니다. 소수의 구현자들이 공유하던 작동 중인 프로토콜로서, 서면 기술이 정착되기 전에 그 행동이 여러 기기 사이에서 해독 가능해져야 했습니다. 이런 상황에서 실패한 교환은 증거였지만 자동으로 판정은 아니었습니다. 참여자들은 여전히 구현물이 규칙을 오해한 것인지, 규칙이 불완전한 것인지, 아니면 시험이 잘못된 질문을 던진 것인지 판단해야 했습니다.

RFC 1025 자체는 모든 사건의 분 단위 기록이 아니라 회고 문서입니다. 이 문서에 따르면 초기 시험 목록은 1978년 10월 IEN 69에 등장했고, 1978년 12월 4일 네 개의 TCP 구현이 Reston에서 시연되었으며, 1979년 1월 27~28일에 여섯 개 구현이 USC의 Information Sciences Institute에서 만났고, 1980년 4월에는 네트워크를 통한 분산 베이크오프가 진행되었습니다. 1987년 메모는 그 1980년 행사에 사용된 절차, 시험 항목, 점수 체계를 약간 편집해 재현합니다. 날짜와 이 연습의 변화하는 모양은 중요한 의미를 지닙니다. 이것은 프로토콜이 완성된 뒤 내려온 단일한 공식 시험이 아니라, 반복적인 조우를 통해 조립된 관행이었습니다.RFC 1025,IEN 69,IEN 77

대화는 여러 부분으로 이루어져 있었다

첫 번째 구분은 거의 소박할 정도로 작았습니다. TCP는 자기 자신에게 연결을 열면 한 점, 데이터를 보내고 받으면 한 점, 충돌이 아니라 우아하게 닫으면 한 점을 얻었습니다. TCP를 재초기화하지 않고 교환을 반복하면 두 점이 더 주어졌습니다. 시험 게이트웨이를 통한 완전한 대화는 다섯 점이었습니다.

이 순서는 단일한 ‘연결됨’ 라벨이 뭉개버릴 여러 사건들을 분리했습니다. 연결 열기는 두 엔드포인트가 상태를 수립할 수 있음을 보였습니다. 데이터 전송은 그 상태가 쓸모 있는 것을 실어줄 수 있음을 보였습니다. 우아한 종료는 관계가 어떻게 끝나는지 시험했습니다. 새 초기화 없는 반복은 첫 주기 이후 구현물이 여전히 사용 가능한지 물었습니다. 게이트웨이는 중개자와 두 번째 네트워크 경계를 추가했습니다. 성공적인 첫 핸드셰이크가 이 모든 질문에 답할 수는 없었습니다.

중량급 이전 구분은 자기 시험에서 상호 운용성으로의 전환을 명시적으로 만들었습니다. 다른 TCP와의 연결 열기, 데이터 교환, 연결 닫기가 각각 두 점이었고, 재초기화 없는 반복에는 네 점이, 시험 게이트웨이를 통한 교환 완료에는 열 점이 주어졌습니다. RFC 1025는 이 기회들이 접촉한 각각의 고유한 TCP마다 적용된다고 밝히며, 예시는 구현물 하나당 최대 20점까지 언급합니다. 목표는 N제곱 연결성, 즉 선호되는 한 쌍이 통신할 수 있음을 보여주는 것이 아니라 가능한 관계의 그물 전체를 시험하는 것이었습니다.

이 목표는 증거의 단위를 바꿉니다. 하나의 결과는 특정 경로와 시험 조건 아래에 있는 구현물의 한 쌍에 속했습니다. A가 B와 통신했다고 해서 B가 C와 올바르게 통신한다는 것, 또는 A가 패킷 전달을 바꾸는 게이트웨이를 통해서도 계속 작동할 수 있다는 것이 확립되지 않았습니다. 이 매트릭스는 단일 쇼케이스가 숨길 수 있는 이음새를 드러냈습니다.

게이트웨이는 경로를 불편하게 만들 수 있었다

이 메모의 기억에 남는 장치는 ‘flakeway’였습니다. 데이터그램을 통째로 떨어뜨리고, 손상시키고 전달하고, 전달 전에 순서를 바꾸는 비율을 조정할 수 있는 의도적으로 신뢰할 수 없는 게이트웨이였습니다. 이름은 장난스럽지만 목적은 진지합니다. 경로 자체를 실험의 일부로 만든 것입니다. 깨끗한 경로에서만 살아남은 연결은, 패킷이 사라지고, 변하고, 다른 순서로 도착해도 데이터를 계속 교환하는 연결보다 더 좁은 결과였습니다.

체크섬 규칙은 이 실험을 조작하기 어렵게 만들었습니다. RFC 1025에 따르면 체크섬은 반드시 강제되어야 했고, 체크섬 시험이 비활성화되면 점수가 주어지지 않았습니다. 이 제약은 겉보기 성공을, 손상을 탐지하도록 만들어진 메커니즘과 연결시켰습니다. 결함을 드러낼 수 있는 장치를 끄는 것으로 시험을 통과할 수 없었습니다.

점수표는 이후 평범한 대화 너머로 확장되었습니다. 헤비급 TCP 구분은 여러 피어에 대한 동시 연결, 긴급 데이터, 시퀀스 넘버 랩어라운드, 많은 헤더 특성을 한 번에 결합한 ‘Kamikaze’ 세그먼트에 점수를 배정했습니다. 스펙을 만족하는 합법적 공격 세그먼트와 스펙을 위반하는 ‘더티’ 공격 세그먼트까지 구분했습니다. 점수표는 합법 세그먼트로 상대를 녹아웃시키면 30점, 더티 세그먼트로 하면 20점을 주었습니다. 이 표현이 경기처럼 들리는 것은 구현물의 한계를 적대적 교환 속에서 드러내도록 설계되었기 때문입니다. 유효하지 않은 세그먼트가 정상적인 운영 조건이 되었다거나, 한 번의 충돌이 프로토콜이 보편적으로 안전하지 않음을 증명했다는 뜻은 아닙니다.

별도의 호스트·게이트웨이 IP 구분도 있었습니다. 이 구분의 점수 항목은 단편화와 재조합, 소스 경로, 복귀 경로, 라우팅 조언, 소스 퀸치 메시지, 서비스 표시 및 옵션을 다뤘습니다. TTL(time to live)을 줄이지 못하는 게이트웨이 동작, TTL이 0인 데이터그램을 전달하는 동작, 체크섬을 잘못 다루는 동작을 발견하는 것에 점수를 주었습니다. 이 분리는 서로 다른 책임을 반영했습니다. TCP는 호스트 간 대화를 관리했고, IP는 상호 연결된 네트워크와 게이트웨이를 통과해 데이터그램을 옮겼습니다.RFC 793,RFC 791

제안된 시험 목록은 수명 주기와 경계 조건을 계속 파고들었습니다: 하나의 연결을 반복해서 열기; 여러 연결을 동시에 열고 데이터가 분리된 상태를 유지하는지 확인하기; 로컬 TCP를 충돌시킨 뒤 같은 연결을 다시 시도하기; 서비스를 거부하는 소켓에 연결하기; 윈도우가 0인 수신자에게 보내기; ‘소방 호스’를 통해 데이터를 빠르게 밀어 넣기; 긴급 전달 시험하기; 랩어라운드 경계 주변에서 시퀀스 넘버를 사용해보기. 마지막 사례는 시퀀스 넘버가 랩어라운드에 가까워지는 시점에 반열린 연결과 불쾌한 세그먼트를 결합했습니다. 이 목록이 우아하지 않았던 이유는 네트워크가 우아하지 않았기 때문입니다. 겉보기에 독립적인 규칙들이 충돌할 수 있는 조합을 시험했습니다.

점수 합계에는 경계가 있었다

점수표에는 최장 대화, 최다 동시 연결, 심지어 변명(excuse)에 대한 점수까지 포함되어 있었습니다. 이런 요소들은 베이크오프를 기억에 남게 만들었지만, 합계를 단일 순위로 다루려는 시도를 복잡하게 만듭니다. 일부 점수는 기본 수명 주기 동작을 측정했고, 다른 점수는 특징 수, 게이트웨이 처리, 많은 대화를 동시에 유지하는 능력을 셌습니다. 이것들은 하나의 속성에 대해 상호 교환 가능한 측정이 아니었습니다.

RFC 1025는 마지막 절에서 이를 직접 말합니다. 앞서의 시험들은 기본 동작과 까다로운 사례를 확인했지만, 성능이나 더 최근의 아이디어가 구현되었는지는 다루지 않았다는 것입니다. 이 문서는 별도의 주의가 필요한 예로 John Nagle 절차, Van Jacobson의 slow-start 및 왕복 시간(RTT) 연구, SQuID 절차를 듭니다. 이어서 가능한 성능 연습을 제시합니다: FTP나 NETBLT로 이더넷 또는 ARPANET을 통해 1메가바이트 파일을 전송하기, 에코 문자의 왕복 시간 측정하기. 이 메모는 성능 결과가 시험 환경에 크게 의존한다고 경고합니다.

이것은 유용한 경계입니다. 선택된 피어들을 통해 연결을 열고, 사용하고, 닫는 점수는 다른 경로에서, 다른 부하 아래에서, 시험에 없는 메커니즘과 함께 시스템이 얼마나 빠르게 작동할지 말해주지 않았습니다. 성공적인 쌍별 교환이 모든 호스트가 같은 소프트웨어를 사용한다는 것, 모든 배포가 통과했다는 것, 모든 코너 케이스가 소진되었다는 것을 확립하지도 않았습니다. 증거에는 범위가 있었고, 이 문서는 그중 일부를 명시했습니다.

시험은 프로토콜의 작동 생활의 일부였다

인터넷의 초기 구현 문화는 규격과 운영 사이의 깨끗한 분리를 기다리지 않았습니다. 베이크오프는 참여자들에게 불일치를 관찰할 수 있는 반복 가능한 표면을 주었습니다: 이 엔드포인트는 열었고 저쪽은 열지 않았다; 이 쌍은 리셋을 견뎠다; 이 게이트웨이는 헤더를 잘못 처리했다; 이 손상된 패킷은 잡혔는데, 잡히지 않았다. 이런 관찰은 코드 수정, 명확화, 서면 규칙의 변경으로 이어질 수 있었습니다.

점수 체계의 신선함보다 역사적으로 더 많은 것을 말해주는 것은 이 피드백 루프입니다. 점수는 산술로 네트워크를 정확하게 만들지 않았습니다. 점수는 구현물의 책임자들 사이에서 특정한 행동을 논의 가능하게 만들었습니다. 공유된 규칙은 독립적인 시스템들이 그것을 실제로 작동시킬 수 있을 때 의미를 얻었고, 시험은 그 한계가 엔지니어들이 결과가 무엇을 확립하고 무엇을 확립하지 않는지를 논쟁할 수 있을 만큼 보이기 시작할 때 유용해졌습니다.

이후의 RFC는 그 관행의 스냅샷을 보존했습니다. 이 문서는 호환성을 대화의 그물로, 복구를 서로 다른 수명 주기 사건들의 순서로, 결함 처리를 엔드포인트에서뿐 아니라 경로를 통해서도 시험할 것으로 다뤘습니다. 그 자체의 경고들은 이 매트릭스가 성능이나 모든 새로운 TCP 아이디어의 완전한 측정인 것처럼 행세하지 못하도록 했습니다. 그렇게 읽으면 RFC 1025는 승리의 환호도 현대의 적합성 인증서도 아닙니다. 젊은 인터넷이 ‘작동한다’를 다른 구현물들이 도전할 수 있는 질문으로 바꾸려던 시도의 기록입니다.

출처