Summary

  • RFC 1692는 같은 호스트로 향하는 짧은 Telnet·Rlogin 세그먼트를 IP 데이터그램 하나에 묶어 패킷 처리와 인터럽트 부담을 줄이는 TMux를 제안했다.
  • 겉의 IP 프로토콜 18만 보는 포트 필터 라우터에는 내부 TCP 포트가 보이지 않는다. RFC는 그 라우터가 TMux를 풀어 검사하거나 차단하도록 했다. RFC 4450은 훗날 이 문서를 Historic으로 옮겼다.

터미널에서 글자 하나를 친다. 서버가 작은 패킷 하나를 보낸다. 여러 사용자가 비슷한 순간에 같은 호스트를 이용하면, 전송한 바이트는 적어도 호스트가 처리해야 할 패킷은 쌓인다. 1994년 8월의 RFC 1692는 데이터가 1옥텟인 패킷을 처리하는 일과 1500옥텟인 패킷을 처리하는 일이 호스트에는 거의 비슷한 부담이라고 설명했다. 저자들이 본 병목은 초당 비트보다 초당 패킷이었다.

Peter Cameron, David Crocker, Danny Cohen, Jon Postel은 짧은 전송 세그먼트 여러 개를 한 IP 데이터그램에 넣는 TMux를 제시했다. 각 세그먼트 앞의 4옥텟 소형 헤더에는 길이, 원래 전송 프로토콜, 헤더 검사용 값이 들어간다. 외부 IP 헤더에는 프로토콜 번호 18이 붙는다. 받은 호스트는 묶음을 풀어 각 부분을 TCP나 UDP에 평소처럼 전달한다. 터미널 애플리케이션은 합승 여부를 알 필요가 없다.

합승객을 기다리는 데에도 시간이 든다. 첫 세그먼트가 들어오면 타이머가 시작되고, 그 사이 도착한 조각들이 함께 출발한다. RFC는 설정 가능한 20~30밀리초를 적절한 값으로 들고, 터미널 응답을 위해 약 0.1초를 사실상의 상한으로 봤다. 버퍼가 차면 바로 보낸다. 700옥텟을 넘는 식의 큰 세그먼트는 보통 데이터그램으로 보내는 편이 낫다. 매번 조각 하나만 들어간다면 절약보다 지연이 크다.

상대가 새 봉투를 열 수 있는지도 알아야 했다. 유효한 TMux 패킷을 받으면 능력을 확인할 수 있고, 처음에는 내용이 없는 프로토콜 18 ENQ 패킷으로 물을 수 있다. 답이 없으면 재시도 간격을 늘리면서, 일반 데이터그램으로 실제 데이터는 계속 보낸다. 상대 호스트가 재시작하면 지원 여부가 바뀔 수 있어 이 능력 기록에는 만료 시간이 필요했다. 연결 전체를 한 형식에 고정하는 설계도 아니었다.

문제는 보안 절에서 분명해진다. TCP 포트로 거르는 라우터는 겉의 프로토콜 18만 보고, 묶음 안의 포트 번호를 못 본다. 같은 TCP 연결의 큰 세그먼트는 일반 IP/TCP 패킷으로 가며 다른 판단을 받을 수도 있다. RFC 1692는 포트 필터를 쓰지만 TMux를 이해하지 못하는 라우터라면 양방향 TMux 패킷을 막으라고 했다. 형식을 이해하는 라우터라면 각 내부 세그먼트를 검사해 규칙을 어긴 것만 제거할 수 있다.

TMux는 Proposed Standard로 출발했다. 2004~2005년 옛 제안들을 검토한 공동체는 누가 이를 새로 구현하거나 유지할지를 물었고, RFC 4450은 TMux를 Historic으로 옮긴 목록에 넣었다. 지금의 RFC Editor 기록도 그렇게 표시한다. 하나로 묶으면 호스트의 패킷 일은 줄어든다. 그 봉투를 통과시킬 라우터에는 안쪽을 읽는 일이 새로 생긴다.

출처