요약

  • RFC 1006의 TPKT는 ISO 전송 TPDU 앞에 4옥텟 헤더—버전, 예약 필드, 전체 패킷 길이—를 추가하여, 수신 측이 TCP의 본래 경계 없는 바이트 스트림에서 해당 TPDU를 구분할 수 있게 한다.
  • 이 헤더는 레코드 경계를 복원한다. 그러나 신원, 무결성, 응용 수용, 서비스 소유, 현재 배포 현황 또는 TCP 아래에 ISO 네트워크가 존재한다는 사실을 증명하지는 않는다.

TCP에 관해 되풀이되는 오류는, 프로그램이send를 호출하기 전에 메시지를 썼다는 이유로 TCP를 메시지 프로토콜이라 부르는 것이다. TCP는 다른 약속을 한다.RFC 793은 각 방향에서 연속적인 옥텟 스트림을 기술한다. 세그먼트는 TCP의 전달 기계 장치이지, 수신 응용에 대한 공개 봉투가 아니다. 한 번의 읽기는 송신 측 쓰기의 일부일 수도, 여러 쓰기를 담을 수도 있으며, 버퍼링과 타이밍이 고른 양일 수도 있다.

1987년RFC 1006이 TCP 위에 옮기려 한 ISO 전송 서비스에게 이는 구체적인 상호운용성 문제였다. 전송 프로토콜 데이터 단위인 TPDU는 개별적인 프로토콜 객체였다. 그러나 TCP 하부층은 의도적으로 그에 대응하는 경계를 제공하지 않았다. 규격의 답은 TCP에 본래 약속하지 않은 응용 경계를 기억하라고 요구하는 것이 아니라, 스트림 위에 작고 명시적인 레코드 문법을 놓는 것이었다.

먼저 세고, 그다음 TPDU를 읽는다

RFC 1006은 이 레코드를 TPKT라 부른다. TPKT는 고정 패킷 헤더 뒤에 TPDU가 따르는 구성이다. 헤더는 4옥텟으로, 8비트 프로토콜 버전, 8비트 예약 필드, 16비트 패킷 길이로 이루어진다. 버전 3에서 버전 값은 항상 3이다. 길이는 헤더를 포함한 TPKT 전체의 옥텟 수이며, RFC 1006은 7부터 65,535까지의 범위를 제시한다. 헤더를 모두 모은 수신 측은 다음 레코드가 시작되기 전에 이 레코드에 속한 나머지 옥텟이 정확히 몇 개인지 알 수 있다.

이것은 프레이밍 규칙이지 TCP 세그먼트 경계에 대한 단정이 아니다. 헤더의 처음 2옥텟은 한 번의 읽기로 도착하고 나머지는 한참 뒤에 올 수도 있고, 완전한 TPKT 여러 개가 함께 도착할 수도 있다. 올바른 수신 측은 스트림을 버퍼링하고, 선언된 개수를 기다렸다가, 결과 TPDU를 ISO 전송 로직에 넘기고, 이를 반복한다. RFC의 4바이트 그림 역시 모든 TPKT가 4바이트의 배수여야 한다는 요구가 아니다. 그림은 표현일 뿐이며, 길이 필드가 규칙이다.

페이로드에도 고유한 이름이 필요하다. RFC 1006 클래스 0 논의에서 해당되는 개별 네트워크 서비스 객체는 TPDU와 동일하다. TPDU에는 정의된 ISO 전송 역할이 있으며, 어떤 비즈니스 트랜잭션 전체, 사람의 메시지, 로그인 또는 데이터베이스 쓰기가 일어났다는 증거가 아니다. 프레이밍은 프로그램에 파싱할 범위가 한정된 바이트 열을 준다. 의미는 여전히 그 위에 있는 프로토콜과 응용 계층에 속한다.

전송 매핑이지 OSI 대체물이 아니다

RFC 1006은 STD 35였고 RFC 983을 대체했으며, 버전 3을 규정하고 이 표준을 구현하는 호스트에 TCP 포트 102를 예약했다. 그 야심은 신중하게 한정되어 있었다. TCP/IP 위에 ISO 전송 서비스를 제공하여, 상위 ISO 계층이 자신의 하위 반송체가 TCP/IP라는 사실을 알 필요 없이 동작할 수 있게 하는 것이다. 그래서 4바이트 헤더가 중요하다. 이 헤더는 하위 계층 전달 형태의 불일치에 걸쳐 특정 서비스 인터페이스를 성립 가능하게 만들었다.

그러나 그것이 인터넷에 ISO 네트워크 계층을 새로 가져온 것은 아니다. 포트 번호가 특정 조직이 서비스를 운영한다는 증거가 되지도 않았다. 피어를 인증하거나, TPDU를 암호화하거나, 주소를 소유자에 묶거나, 수신자가 그 의미 내용을 수용했다고 말하지도 않았다. 길이 필드는 파서에게 어디서 멈추어야 하는지를 알려주는 데는 뛰어나다. 그러나 바이트를 누가 공급했는지, 그리고 그 바이트가 나타내는 동작이 실제로 수행되어야 하는지에 대해서는 침묵한다.

1997년에 발표된RFC 2126은 RFC 1006을 갱신했다. TPKT의 버전/예약/전체 길이 구조는 유지하면서, RFC 1006 기존 설치 기반을 위한 클래스 0을 정교화하고 TCP 위의 클래스 2 변형을 추가했다. 그 보안 절은 경계로서 드물게 유용하다. 이 프로토콜은 TCP 및 ISO 8073보다 더 안전하지도 덜 안전하지도 않다는 것이다. 이 갱신은 매핑의 진화를 기록할 뿐, 오늘날의 보급률에 대한 증거적 정당화도, 파싱된 TPKT가 신뢰할 수 있다는 주장도 아니다.

경계가 운영적으로 바꾸는 것

통제점은 평범하지만 견고하다. 상태 유지 프레이밍은 전송 전달과 상위 계층 결과와 별도로 관찰되어야 한다. 트레이스에 TCP 연결, 포트, 버전 3 TPKT 헤더, 선언된 길이, 문법적으로 파싱된 TPDU가 나타날 수 있다. 이 사실들은 전송 교환에 대한 한정된 서술을 뒷받침한다. 그러나 사용자의 신원, 요청의 권한, 네트워크 엔드포인트의 소유 또는 완료된 작업을 확립하지는 않는다.

이 구분은 “낡은 OSI”에 대한 향수 어린 서술보다 유용하다. 디코더에는 버퍼링된 바이트에 대한 한도, 불가능한 길이에 대한 합리적 처리, 레코드 수준 오류 보고, 그리고 스트림 수신과 TPDU 파싱을 구분하는 로그가 필요하다. 서비스 소유자에게는 인증과 비즈니스 결과에 대한 별도의 증거가 필요하다. 1987년 설계는 헤더가 함축으로 그 일들을 할 수 없기에 그 역할들을 분리해 둔다.

레코드의 근거와 한계

아래 RFC들은 여기서 다룬 역사적 지위, 스트림과 레코드의 불일치, TPKT 문법, 1997년 갱신을 확립한다. 그러나 현재의 배포 점유율, 특정 호스트에서의 구현, 인용된 프로토콜 이상의 보안 속성, 사용자 신원, 페이로드 무결성 또는 응용 성공을 확립하지는 않는다.