요약

  • RFC 938은 수신 윈도우 내 IRTP 데이터 패킷의 목적지 포트를 알 수 없을 때PORT NAK를 규정했다. 수신자는 데이터를 폐기하고 현재rcv_nxt를 반환함으로써 패킷 시퀀스가 아니라 포트를 NAK했다.
  • 이 응답은 범위가 한정된 전송 계층 관찰과 실패한 로컬 포트 조회를 입증할 수 있다. 애플리케이션이 페이로드를 수신, 파싱, 인가, 저장하거나 처리를 완료했음을 보여주지는 못한다.

일부 프로토콜 이름은 세부 사항이 완전히 지키지 못하는 약속을 하고 있다. 1985년 2월에RFC 938로 발표된Internet Reliable Transaction Protocol은 트랜잭션의 전체 운명을 확정해 줄 것처럼 들린다. 그러나 이 문서에서 가장 많은 것을 드러내는 설계는 정반대를 한다. 패킷 시퀀스에 대한 호스트 간 판단과 페이로드가 어디로, 혹은 어디로도 가야 하는지에 대한 로컬 판단을 분리한다.

이 문서는RFC 938 정보 기록이 분명히 보여주듯 실험적/제안(experimental/proposed) 상태였다. 이 지위는 중요하다. 사양은 저자들이 설계한 것이 무엇인지 알려주지만, 얼마나 널리 운영되었는지, 얼마나 자주 동작했는지, 특정 설치된 시스템이 이를 채택했는지는 알려주지 않는다. 역사적 가치는 제안된 경계에 있다.

IRTP는 IP 위에 놓였다.RFC 791은 IP의 Protocol 필드를 다음 상위 프로토콜의 식별자로 정의한다. 현재IANA 프로토콜 번호 레지스트리는 28을 IRTP로 기록하고 RFC 938을 가리킨다. 레지스트리는 조정에 관한 사실을 보존한다. 이는 트래픽 측정, 코드 조사, IRTP가 여전히 사용 중이라는 증명이 아니다.

작은 헤더가 의미상 서로 다른 두 주소를 함께 실었다

IRTP 패킷에는 8옥텟 헤더가 있었다. 여기에는 패킷 타입, 포트 번호, 시퀀스 번호, 길이, 체크섬이 담겼다. RFC 938은SYNCH,SYNCH ACK,DATA,DATA ACK,PORT NAK의 다섯 가지 타입을 정의했다.

이 헤더는 두 가지 질문을 나란히 놓으면서 하나로 합치지 않았다. 시퀀스 번호는 호스트 간 신뢰 전달 기계에 속했다. 포트는 데이터가 의도된 상위 프로토콜이나 프로세스를 식별했다. 하나의 프로세스가 여러 포트 번호를 클레임할 수 있었지만, 특정 번호를 클레임할 수 있는 프로세스는 하나뿐이었다. 클레임된 로컬 포트에서의 패킷 교환은 원격 호스트의 동일한 포트와 대응하도록 의도되었다.

IRTP의 연결 개념도 충분히 특이해서 신중한 다룸이 필요했다. 상태 관계는 호스트·포트 쌍마다 별도 연결을 두는 것이 아니라, 원격 인터넷 주소로 식별되는 호스트 사이에 존재했다. 모듈의 연결 테이블에는snd_nxt,rcv_nxt,snd_una를 포함한 변수들이 담겼다.SYNCH와SYNCH ACK는 이 호스트 쌍 상태를 수복하거나 수립했다. 따라서 포트는 신뢰 연결의 이름이 아니었고, 그 연결 내에서 데이터가 마주치는 로컬 디멀티플렉싱 질문이었다.

이 구분은 현대의 로그 한 줄에서 쉽게 평탄화된다. “포트 4000에 전달됨”은 애플리케이션 결과로 읽힐 수 있고, “패킷 47 승인됨”은 같은 주장을 하위 수준 언어로 표현한 것처럼 읽힐 수 있다. RFC 938은 그런 지름길을 허용하지 않았다. 각 문장에 별도의 필드, 상태 조건, 응답 코드를 부여했다.

포트를 조회하기 전에 패킷이 자격을 갖췄다

수신 절차는 이 순서를 명시한다. 수신되는DATA패킷에 대해 IRTP 모듈은 먼저 시퀀스 번호가 자신의 승인 윈도우 안에 있는지 검토한다. 관련 윈도우 밖의 패킷은 동일한 결과를 얻지 못한다. 윈도우 안에 있는 패킷에 대해서는 수신자가rcv_nxt를 다시 계산한 뒤 명시된 포트가 알려져 있는지 검토한다.

포트가 알려져 있다면, 수신자는DATA ACK로 승인한 후에만 데이터를 사용자 프로세스의 큐에 넣는다. 포트가 알려져 있지 않다면, 대신PORT NAK를 보내고 데이터를 폐기한다. 두 승인류 응답에서 시퀀스 필드는 현재rcv_nxt를 담는다.

RFC 938은 후자의 응답 정의에서 가능한 모호성을 제거한다.PORT NAK는 “시퀀스 필드에 담긴 패킷 번호까지의 모든 패킷 번호 수신을 승인한다.” 그리고 NAK하는 것은 “패킷 번호가 아니라 포트 번호”다. 이 언어가 이례적으로 정확한 이유는 두 개의 독립적 사실이 하나의 와이어 이벤트에 압축되었기 때문이다.

따라서 수신자는 상대에게 말할 수 있다. 호스트 수준의 시퀀스는 이 경계까지 진행되었으며, 그 사실만으로 로컬 엔드포인트가 존재했다고 추론하지 말라. 패킷의 페이로드는 폐기되었다. 이 응답은 그 시퀀스 번호에 대한 재전송 요청도, 애플리케이션으로 들어가는 입장권도 아니었다.

수신은 디스패치가 아니고, 디스패치는 결과가 아니다

시퀀스 승인은 범위가 한정된 프로토콜 사실을 확립한다. RFC 938의 상태 머신을 고려하면, 트레이스는 IRTP 수신자가 수신된 DATA 패킷을 관련 승인 범위 안으로 취급했고 명시된rcv_nxt까지 누적 수신을 보고했다는 것을 뒷받침할 수 있다. 포트 NAK는 두 번째로 한정된 사실을 더한다. 그 시점에 수신자는 해당 포트를 클레임한 프로세스를 알지 못했다.

두 사실 모두 일상적인 산문에서 “전달(delivery)”에 흔히 부여되는 역할을 하지 못한다. 애플리케이션이 바이트를 파싱했는지, 서비스가 요청 수용을 선택했는지, 신원이 인증되었는지, 인가 검사를 통과했는지, 기록이 저장되었는지, 사람의 작업이 완료되었는지를 확립하지 않는다. 반대로 영구적 부재를 확립하지도 않는다. 포트 클레임은 로컬적이고 일시적일 수 있으며, 프로토콜 응답은 한 상태에서의 한 번의 관찰만 기록한다.

패킷의 시퀀스와 포트를 서로 다른 증거 대상으로 취급하면 이 경계는 더욱 명확해진다. 시퀀스 이벤트는 두 호스트 사이의 관계에 대해 말한다. 포트 클레임 이벤트는 수신 모듈의 프로세스에 대한 로컬 매핑에 대해 말한다. 애플리케이션 이벤트는, 발생한다면, 또 다른 주체에 속하며 자체적인 검증, 트랜잭션, 내구성 규칙을 가질 수 있다.

이 계층적 절제는 Lu Heng의 Note 64에서 최소 공통 규칙과 이후의 로컬 선택을 구분한 것과 상응한다. 와이어 프로토콜은 자신의 상태에 대해 결정론적이고 로컬에서 검증 가능한 한 가지 진술을 할 수 있다. 그 진술을 기록했다는 이유만으로, 포트를 클레임하지 않은 프로세스나 페이로드의 의미를 결정할 조직에 대해 권한을 행사할 수는 없다.

신뢰성이 곧 하나의 보편 정책은 아니었다

RFC 938은 호스트 쌍 동기화, 체크섬, 승인, 재전송 압박을 위한 간결한 메커니즘을 제시했다. 완전한 운영 정책을 규정하지는 않았다. 구현체에 재전송을 트리거하고snd_una를 재전송하는 방법을 요구했지만, 구체적인 타이머와 재전송 전략은 열어두었다. 이러한 선택을 결정하는 것은 공통 헤더가 아니라 로컬 구현이었다.

2분 정적 시간(quiet time) 참조도 같은 절제를 보여준다. RFC 938은 원격 주소가 알려지게 되었을 때 IRTP 모듈에 정적 시간을 관찰하도록 요구하며 독자들을RFC 793의 논의로 안내했다. 이 참조는 범위가 한정된 설계 비교일 뿐이다. IRTP를 TCP로 만들지도, 두 패킷에 동일한 의미론을 부여하지도, 구현체들이 공유 배포 역사를 갖췄음을 입증하지도 않는다.

그 결과는 거창한 프로토콜 레이블에 대한 유용한 역사적 교정이다. 여기서 “Reliable”은 의도된 모든 애플리케이션 엔드포인트가 존재했다는 뜻이 아니었다. “Transaction”은 모든 페이로드가 완결된 비즈니스 또는 사용자 행위가 되었다는 뜻이 아니었다. 이 RFC는 한정된 배치 안에서 신뢰할 수 있는 시퀀스 처리와 포트 디스패치 결과를 정의했고, 둘 사이의 간극을 의식적으로 보존했다.

바람직한 감사 추적은 ACK 비트가 아니라 체인이다

PORT NAK를 조사하는 운영자에게는 NAK라는 단어만으로는 부족하다. 원격 주소, 포트, 수신된 시퀀스 번호, 반환된rcv_nxt, 적용된 수신 윈도우, 연결 상태 에포크, 체크섬 결과, 패킷 타입, 당시의 포트 클레임 상태를 보존하라. RFC 938이 의도적으로 보편 정책 하나를 제공하지 않았으므로, 구현체의 타이머 및 재전송 정책은 별도로 기록하라.

이런 기록들은 “전달 실패” 카운터 하나가 답할 수 없는 질문들을 가능하게 한다. 패킷이 포트 미클레임 때문에 거부되었는가, 아니면 디스패치가 가능해지기도 전에 체크섬이나 윈도우 검사에서 실패했는가? 원격 호스트가 재동기화 중이었는가? 상대가 프로토콜이 요구한다고 해석한 응답에 따라snd_una를 재전송했는가? 이후 프로세스가 띄워졌고 새 패킷이 다르게 라우팅되었는가? 이 신호들은 서로 다른 제어 표면을 가리키며, 하나의 애플리케이션 실패 서사로 뭉개서는 안 된다.

가장 강한 결론은 동시에 가장 좁은 결론이다. RFC 938은 신뢰성 증거를 보존하면서 로컬 전달을 위조하지 않는 응답을 설계했다. 패킷은 시퀀스 상태에는 포함되면서 포트 경계에서 폐기될 수 있었다. 이는 불완전한 승인이 아니다. 수신, 디스패치, 결과가 서로 다른 권한에 속한다는 프로토콜 자체의 논증이다.

출처와 한계

이 글은 IRTP의 규정된 패킷 구조와 수신 절차는 RFC 938에, 실험적/제안 상태는 RFC 938 정보 기록에, IP 다음 프로토콜 필드는 RFC 791에, 정적 시간 비교는 오직 RFC 793에, 현재의 28번 조정 기록은 IANA의 프로토콜 번호 레지스트리에 의존한다. 이 출처들은 구현, 채택, 트래픽, 성능 또는 현재의 운영을 정량화하지 않는다.

또한PORT NAK를 보안이나 비즈니스 결론으로 격상시키는 것을 허용하지 않는다. 이 응답은 상대 인증도 기밀성도, 애플리케이션 인가도 내구성 있는 완료도 제공하지 않는다. 역사적 교훈은 더 소박하고 더 오래 지속된다. 승인은 한 경계를 진실하게 기술할 수 있고, 거부는 다음 경계를 진실하게 기술할 수 있다.