글자 하나에 짐 마흔 바이트가 따라붙었다

Summary

• RFC 914는 Telnet 글자 하나를 담은 TCP/IP 패킷이 41바이트라고 계산했다. 저자들의 가정 아래 1200보드 회선에서 전송 시간은 약 0.3초, 글자 하나씩 보낼 때 유효 속도는 약 30보드였다.
• Thinwire I은 예시 패킷을 17바이트로, II는 13바이트로 줄였다. III는 네트워크와 전송 계층의 일을 게이트웨이에 맡겨 평균 유효 속도를 약 900보드로 추산했다. 속도를 얻는 대신 누가 연결을 맡는지가 바뀐다.

엽서 한 장을 부치는데 우체국 건물까지 함께 보내야 한다면, 엽서 값보다 운송비가 먼저 눈에 들어온다. 1984년의 저속 인터넷 접속이 그랬다. David Farber, Gary Delp, Thomas Conte는 3000~1만 달러짜리 개인용 컴퓨터가 가정과 사무실에 놓이기 시작한 상황을 보았다. 56k 전용 회선은 비싸고 설치도 오래 걸렸다. 1200 또는 2400보드 전화 모뎀은 구하기 쉬웠다. 컴퓨터와 회선을 갖추자 남은 문제는 한 글자의 몸집이었다. Telnet 글자 한 바이트를 운반하는 최소 TCP/IP 패킷에는 총 41바이트가 들었다.

Thinwire 문서는 이를 기다리는 시간으로 바꿔 적었다. 1200보드 회선에서 패킷 하나에 약 0.3초, 한 패킷에 글자 하나씩 보낼 경우 유효 속도는 약 30보드라는 계산이다. 회선만이 속도를 제한하고 동기식처럼 작동한다는 가정이 붙었다. 인터럽트와 처리, 프레이밍 비용을 더하면 시간은 10~50% 나빠질 수 있다. 화면에 입력을 먼저 보여 주거나 한 줄을 모아서 보내면 일부 작업은 견딜 만하다. 상대가 매 글자에 반응해야 하는 프로그램에는 그 요금이 매번 붙는다.

Thinwire I은 지난번 소포의 복사본을 양쪽에 남긴다. 다음에는 바뀐 위치와 바꿀 바이트 수만 적어 보낸다. 문서의 Telnet 예시에서 갱신 패킷은 보통 17바이트였고, 저자들이 계산한 유효 속도는 약 70보드였다. 간단하지만 한 가지 틀만 기억하는 데서 한계가 생겼다. 서로 다른 종류의 패킷이 번갈아 오면 지난번 패킷이 다음 패킷의 좋은 밑그림이 되지 못한다. 짐을 줄일 방법을 찾았더니, 배송 물품마다 모양이 달랐다.

Thinwire II는 연결별로 밑그림을 따로 둔다. TCP 연결마다 패킷을 분류하고, 변한 헤더 필드를 비트맵으로 알리며, 긴 숫자 대신 짧은 차이를 전한다. 41바이트짜리 예시는 13바이트가 되고, 글자 하나의 유효 속도는 약 95보드로 추산됐다. 대신 PC에는 여러 틀을 보관할 메모리, 게이트웨이에는 연결표가 필요했다. 양쪽 기억이 엇갈리면 데이터 흐름이 멈춘다. 안정적인 직렬 링크와 주기적인 전체 패킷 전송으로 다시 맞춰야 한다. 압축 방식이 모르는 프로토콜은 통째로 보낸다. 선에서 절약한 바이트만큼 양쪽 끝에서 기억과 복구를 책임져야 했다.

Thinwire III는 짐 꾸리는 법 대신 짐꾼을 바꿨다. 중앙 게이트웨이가 PC를 대신해 인터넷 쪽 TCP와 UDP 연결을 열고 관리한다. PC와 게이트웨이는 하나의 신뢰 가능한 직렬 흐름에 데이터와 제어 명령을 섞어 보낸다. RFC가 추산한 평균 유효 속도는 약 900보드에 이른다. 그러나 연결의 모양도 달라진다. 게이트웨이는 PC의 대리인으로 외부 연결을 시작한다. PC가 서비스를 제공하려면 게이트웨이에 수동 수신을 마련할 수 있지만, 임의의 외부 연결이 완전한 인터넷 호스트처럼 PC에 직접 도착하지는 않는다. 좁은 선이 편해진 만큼 문지기의 역할이 커졌다.

오늘 RFC Editor 기록은 이 문서를 역사적 문서로 분류한다. 1984년의 세 안은 토론을 위한 제안이었고, 속도는 조건을 둔 계산값이다. 그렇기에 오히려 설계의 갈림길이 선명하다. 조금 줄이고 상태를 적게 갖거나, 많이 줄이는 대신 두 끝이 같은 기억을 공유하거나, 아예 게이트웨이가 인터넷의 무거운 일을 맡는 길이다. 키 하나의 지연을 고치려다 네트워크에서 개인용 컴퓨터가 맡을 몫까지 다시 정하게 된 셈이다.