TCP는 두 번째 레코드를 인질로 잡았다: RFC 1693

요약

1994년 11월의 실험적 RFC 1693은 TCP에 부분 순서와 부분 신뢰성 서비스를 더하는 방안을 검토했다. 네 레코드로 만든 데이터베이스 예시에서 허용되는 결과 순서는 질의에 따라 하나, 둘, 넷 또는 4! = 24개였다.
문서 첫머리의 IESG 주석은 제안된 TCP 수정을 구현하도록 권고하지 않았고, 순서가 어긋나거나 일부가 빠진 데이터를 다루는 분석은 TCP 밖에서도 가치가 있다고 밝혔다. 제안과 판단이 한 문서에 나란히 남았다.

정확한 안내 직원이 일을 지연시킨다

서버가 레코드 네 개를 보낸다. 첫째가 네트워크에서 지체되는 사이 둘째는 수신 측에 도착한다. 일반적인 TCP 바이트 흐름은 첫째가 오기 전 둘째를 위쪽 응용 프로그램에 넘기지 않는다. 1981년의 RFC 793이 정한 신뢰할 만한 순서 있는 전달의 일부다. 그런데 질의 결과가 둘째를 먼저 보여 줘도 되는 경우라면, 운송 계층은 멀쩡한 서류를 들고도 앞사람이 안 왔다는 이유로 창구를 닫는 셈이다.

T. Connolly, P. Amer, P. Conrad는 RFC 1693에 이 문제를 네 장의 레코드로 그렸다. 서로 다른 영업사원 이름으로 정렬하면 가능한 결과 순서는 하나다. 두 레코드의 도시가 같은 위치 기준 정렬은 두 가지 순서를 허용한다. 두 쌍이 같은 상품 설명을 가진 경우에는 네 가지가 가능하다. ORDER BY를 빼면 네 장의 배열 4!, 곧 24가지가 모두 조건을 만족한다. 이 숫자는 논문 안에서 만든 예시의 조합 수다. 핵심은 결과 사이에 필요한 선후관계가 질의마다 달라진다는 것이다.

저자들은 그 중간 영역을 부분 순서라고 불렀다. 어떤 객체는 앞선 객체가 도착해야 전달되고, 서로 독립인 객체는 서로 앞뒤를 바꿔도 된다. 송신자와 수신자는 무엇이 허용되는 순서인지 전달하거나 협상해야 한다. 수신 쪽에는 도착한 객체가 이제 전달 가능한지 판단하는 알고리즘도 필요하다. 전부 한 줄로 세우는 방식과 모든 카드를 공중에 던지는 방식 사이에 질서 있는 여러 경로가 있는 것이다.

순서와 신뢰성은 또 다른 두 축이다. 데이터베이스는 모든 레코드가 결국 도착해야 하면서도 일부 결과의 순서는 바뀌어도 될 수 있다. 멀티미디어에서는 채널 안의 순서는 중요하지만 지나간 영상 프레임의 일부 손실을 허용할 수도 있다. RFC는 영상, 두 음성 채널, 자막과 수어 영상을 다른 속도의 흐름으로 예시했고, 화면 창의 다시 그리기도 살폈다. 어떤 객체가 뒤의 객체에 필요한지, 무엇을 잃어도 되는지는 응용 프로그램이 아는 사실이다.

문서는 이런 서비스를 수정된 TCP 연결 안에서 구현하는 방안을 제시했다. 연결 설정 때 상대가 기능을 이해하는지도 식별하고, 완전한 순서 때문에 대기하던 데이터를 더 일찍 넘길 가능성을 분석했다. 네 레코드에서 나온 1·2·4·24는 성능 측정치가 아니라 허용 가능한 배열의 수다. 실제 지연 시간이 몇 밀리초 줄었는지 이 숫자만으로 계산할 수는 없다.

눈여겨볼 것은 문서 맨 앞의 IESG 주석이다. 전송 분야 책임자와 담당 그룹은 제안된 TCP 수정의 구현을 권고하지 않았다. 동시에 순서가 뒤섞이거나 데이터가 불완전할 때의 처리 분석은 TCP 바깥에서도 쓸모 있다고 적었다. 문제를 잘 짚은 연구와 그것을 TCP에 넣는 선택은 별개의 판단을 받았다. RFC는 실험적 문서로 남았고, 둘 다 기록됐다.

네 장의 카드가 남긴 질문은 구체적이다. 지금 수신기가 기다리는 것이 응용 프로그램의 진짜 의존성 때문인가, 아니면 모든 것을 한 줄에 세우는 규칙 때문인가? 둘째 레코드는 이미 와 있었다. 1994년의 제안은 이 장면을 세밀하게 그렸고, IESG는 그 장면을 TCP 수정의 근거로 채택하지 않았다. 인터넷 역사는 이 두 사실을 함께 읽을 때 더 정확하다.