요약

  • RFC 916의SO플래그는 1옥텟 페이로드가 헤더의LENGTH위치를 차지하게 만들어 별도의 데이터 부분을 없애고, 헤더 체크섬이 해당 글자를 보호하도록 했다.
  • 동일한 물리적 옥텟은 연결 개시 시에는 수신자의 최대 데이터 길이, 일반 패킷에서는 평범한 바이트 수,SO패킷에서는 데이터 그 자체를 의미했다. 옥텟만이 아니라 플래그와 수용된 상태가 해석을 승인했다.
  • 1비트 순서 번호와 확인 응답 번호가 충분했던 이유는 각 방향에서 응답을 요구하는 패킷이 동시에 최대 하나만 전송 중일 수 있었기 때문이다. 절약과 한계는 같은 설계 결정이었다.

1984년 10월에 발표된RFC 916은 신뢰성 있는 비동기 전송 프로토콜(RATP, Reliable Asynchronous Transfer Protocol)을 제안했다. 그것이 상정한 환경은 전이중 지점 간 링크였고, 대개 명령을 받아들이는 소형 컴퓨터, 모뎀 또는 장치를 연결하는 비동기 RS-232 회선이었다.RFC Editor 기록은 현재 이 문서를 Historic으로 분류한다. 이 표기는 현재의 아카이브 상태를 설명할 뿐, 메커니즘의 정밀함을 떨어뜨리지 않는다.

명세는 우선순위를 분명하게 밝혔다: 신뢰성이 먼저, 그다음이 단순한 구현이다. 동적 윈도우 관리와 여러 미해결 패킷은 제외되었다. 원격 측이 연결을 닫을 때 아직 대기 중이던 데이터는 폐기되었고, 문서는 이 선택이 두 개의 상태를 없앤다고 말했다. 이것은 TCP의 모든 능력을 갖춘 척하는 축소판 TCP가 아니었다. 한계가 더 작은 상태 기계를 사들인, 더 좁은 연결이었다.

데이터 바이트는 자기 길이를 대신했다

평범한 RATP 헤더는 4옥텟을 차지했다: 16진수01동기화 리더, 제어 옥텟, 데이터 길이로 표시된 옥텟, 그리고 헤더 체크섬. 일반 데이터는 헤더 뒤에 이어지고 별도의 16비트 데이터 체크섬으로 끝났다.

대화형 사용은 어색한 비율을 만들었다. 사람이 한 글자를 입력했고 지연이 중요하다면, 더 많은 글자를 모아 보내기를 기다리는 것은 경험을 바꿔버릴 것이다. 그것을 일반 형식으로 즉시 보내려면 4옥텟 헤더, 1옥텟 데이터, 2옥텟 데이터 체크섬, 모두 7옥텟이 필요했다.

RATP는SO, 즉 Single Octet 제어 플래그를 제공했다.SO가 설정되고SYN,RST,FIN이 모두 지워져 있으면, 수신자는 페이로드 길이가 정확히 1임을 이미 알고 있었다. "1"이라고 말하는 필드는 플래그가 담고 있는 정보를 반복하는 셈이었다. 그리하여 RFC 916은 글자 그 자체를LENGTH위치에 넣고, 데이터 부분을 생략하며, 헤더 체크섬이 내장된 글자를 덮도록 했다. 문서는 7옥텟에서 4옥텟으로의 축소를 전송 효율 40퍼센트 개선으로 기술했다.

수학적으로 압축된 것은 없었다. 3옥텟이 사라진 것은 프로토콜 상태가 그 기능을 중복으로 만들었기 때문이다: 플래그가 길이를 제공하고, 헤더 슬롯이 데이터를 제공하며, 헤더 체크섬이 그 데이터의 손상 검출을 제공했다.SO는 두 글자 문자열을 압축하지 않았고, 확인 응답을 없애지 않았으며, 모든 짧은 패킷을 4옥텟으로 만들지도 않았다. 그것은 정확히 하나의 경우를 기술했다.

하나의 위치가 세 가지 다른 계약을 담았다

헤더의 세 번째 옥텟은 그 위치만으로는 해석할 수 없었다.SYN을 실은 패킷에서 그것은 최대 데이터 길이(MDL, Maximum Data Length)였다. 그SYN의 송신자는 한 패킷에서 받아들일 준비가 된 최대 데이터 크기를 상대에게 알려주고 있었다. 3방향 개시 교환 동안 각 측은 자기 한계를 선언했다.

SYN,RST,FIN이 없는 설정 완료된 패킷에서는 같은 위치가LENGTH로 불렸다.SO가 지워져 있으면 그 값은 뒤따르는 데이터 옥텟 수를, 0부터 상대의 MDL까지 세었다.SO가 설정되어 있으면 그 값은 전혀 개수가 아니었다. 그것은 바로 그 하나의 데이터 옥텟이었다.

이것이 해석기에게 세 가지 그럴듯한 의미 사이에서 추측하도록 허락한 것은 아니었다. 제어 비트는 헤더 체크섬을 통과해야 했고, 패킷은 수신자의 연결 상태에서 의미가 있어야 했다. 그때에만 옥텟이 용량, 개수 또는 내용이 될 수 있었다. 바이트를 보존하지만 플래그나 연결 시점을 잃어버린 트레이스는 문법을 잃은 비문을 보존한 것이다.

이 구별은 오류 처리의 경계이기도 했다. 헤더가 체크섬은 통과했지만 수신 측 MDL보다 큰 평범한 길이를 선언했다면, RFC 916은 그 사건을 프로토콜 위반 또는 검출되지 않은 희귀한 길이 오류로 다루었다. 수신자는 연결을 재설정했다. MDL은 버퍼 선호에 관한 다정한 힌트가 아니었다. 프로토콜적 결과를 지닌, 각자 선언하는 수용 한계였다.

종단은 데이터를 받고 싶지 않다면 MDL 0을 광고할 수 있어 일방적 사용이 허용되었지만, 데이터가 오가려면 양쪽 모두 0을 선택할 수는 없었다. 공통 프로토콜은 한계가 어떻게 전달되고 위반이 어떻게 처리되는지를 정의했다. 자신의 용량에 관한 결정은 장치 소유자에게 남아 있었다.

1비트로 충분했던 이유는 큐가 한 패킷 깊이였기 때문이다

RATP의 순서 번호(SN)와 확인 응답 번호(AN)는 각각 1비트였다. 두 값짜리 순서 공간은 불변 조건을 함께 보기 전에는 무모하게 작아 보인다: 한 방향에서 한 번에 응답을 요구하는 패킷은 최대 하나만 전송되거나 확인되고 있었다.

수신자는 기대하는 모듈로 2 값을 사용해 다음 패킷과 이미 확인한 패킷의 중복을 구별했다. 송신자는 돌아온AN을 사용해 마지막 응답 요구 패킷을 재전송 큐에서 제거한 뒤 자기 순서 비트를 토글했다. 첫 패킷과 혼동될 두 번째 미확인 패킷이 없으므로 1비트가 필요한 일을 해낼 수 있었다.

두 방향은 여전히 독립적이었다. A 측의 마지막 관련 패킷이 확인되면, A는 B가 자체 데이터를 가질 때까지 기다리지 않고 보낼 수 있었다. 확인 응답은 편리할 때 송신 데이터와 결합될 수 있었다. 순수한 확인 응답 자체는 또 다른 확인 응답을 요구하지 않아, 영원히 계속되는 영수증 교환을 피했다.

비용이 드러나는 지점이 여기다. 1비트 필드는 고립된 영리함이 아니었다. 그것은 윈도우의 부재를 부호화했다. 대역폭-지연 곱이 큰 링크에서는 응답 요구 패킷마다 기다리는 것이 처리량을 제약할 것이다. 느린 대화형 링크와 작은 기계에서는 같은 제약이 구현, 할당, 중복 추론을 훨씬 쉽게 만들 수 있었다. 올바른 평가는 프로토콜이 섬기도록 설계된 환경에 달려 있다.

수신자가 감당할 수 있는 패킷을 광고했다

RATP는 MDL을 255로 상한 책정했으므로 가장 큰 평범한 패킷은 261옥텟이었다: 동기화, 나머지 헤더, 2옥텟 데이터 체크섬, 255옥텟 데이터. 명세는 그 숫자로부터 구현상의 결과를 끌어냈다: 수신자는 한 수신 패킷을 위해 그 이상의 공간을 예약할 일이 결코 없다.

상한만으로 사용 가능한 값을 결정하지는 않았다. 각 측은 자기 MDL을SYN에 넣었다. 제약받는 종단은 더 작게 알릴 수 있었다. RFC 916은 또한 이 선택을 외부 흐름 제어와 연결했다: 특정 보드레이트에서 긴 버스트가 제어 글자의 삽입을 유발하는 경향이 있다면, 구현은 어떤 패킷은 그 현상에 부딪히지 않고 지나갈 수 있도록 더 작은 최댓값을 선택해야 한다.

따라서 용량 계약은 계층을 무너뜨리지 않으면서 계층을 가로질렀다. 프로토콜은 하나의 결정론적 필드와 강제 규칙을 제공했다. 운영체제, 장치 드라이버, 모뎀 경로, 가용 메모리가 지역 숫자를 형성했다. 상대는 광고된 한계를 지키거나 연결을 잃을 수 있었다. 그 값을 선택하는 레지스트리나 지속적 권위는 없었다.

패킷 경계가 곧 레코드 경계인 것은 아니었다

체크섬이 적용된 헤더가 패킷에 속한 추가 옥텟 수를 결정했다. RATP는 시작 동기화 패턴을 사용했지만 맞추는 종료 구분자는 없었다. 임의의 패턴이 데이터 속에 나타날 수 있었다. 헤더가 신뢰되면, 그 해석된 길이가 패킷의 끝을 계산 가능하게 만들었다.

상위 계층의 자료는 MDL보다 클 수 있고 단편화를 필요로 할 수 있었다.EOR플래그는 상위 계층 레코드가 이 RATP 패킷에서 끝났음을 보고했다. 그것을 설정하고 지우는 책임은 상위 계층에 있었다. 따라서 패킷은 링크 전송으로서는 완결적이면서도 그 위의 대상물의 한 조각에 지나지 않을 수 있었다.

이 구분은 증거와 관련이 있다. 유효한 헤더는 후보 헤더가 체크섬을 통과했음을 증명한다. 확인 응답은 프로토콜이 정의한 의미에서 상대의 RATP 상태가 패킷을 수용했음을 증명한다.EOR은 레코드 경계를 밝히는 데 도움을 준다. 그 어느 것도 응용이 레코드를 해석했다는 것, 명령이 승인되었다는 것, 또는 그 요청된 효과가 발생했다는 것을 증명하지 않는다.

복구에는 자체 메커니즘이 있었다

RS-232는 완전한 RATP 패킷이 아니라 개별 옥텟을 프레임화했다. 잡음은 바이트를 삽입하거나 가짜01을 만들 수 있었다. 수신자는 그 동기화 리더를 탐색한 뒤 뒤따르는 세 옥텟을 검사했다. 헤더 체크섬이 실패하면 그 세 옥텟은 새로운 입력으로 다뤄지고 동기화 탐색이 재개되었다. 가짜 시작이 해석기에게 알 수 없는 양을 건너뛰도록 허락하지는 않았다.

이 복구 메커니즘은 문맥이지 본 글의 주장은 아니다.RFC 1055는 이후 SLIP의 다른 거래를 문서화했다: IP 데이터그램 주위의 구분자와 이스케이프 문자, 그러나 유형 필드도, 기반 표준 최댓값도, 직렬 링크 오류 정정도 없었다. 이 비교는 "직렬 프로토콜"이 프레이밍, 신뢰성, 협상의 단일한 필연적 배분을 함축하지 않음을 보여준다.

RFC 1661과RFC 1662는 이후 PPP의 프로토콜 멀티플렉싱, 링크 제어 프로토콜, 협상 가능한 링크 속성, 플래그 프레이밍, 투명성, 프레임 검사 시퀀스를 명세했다. 이 문서들이 PPP가 RATP의 후손이라는 증거는 아니다. 그것들은 더 오래된 선택을 보기 쉽게 만든다: RATP는 신뢰성 있는 연결 동작, 패킷 프레이밍, 용량 교환, 특별한 대화형 최적화를 하나의 작은 지점 간 프로토콜에 통합했다.

RFC 793은 RFC 916이 동적 윈도우 관리를 거부하면서 직접 인용한 동시대 TCP 비교 자료를 제공했다. TCP는 훨씬 더 넓은 스트림과 순서화 계약으로 상호 연결된 호스트들을 섬겼다. RATP는 데이터그램과 신뢰성 있는 연결 기능을 하나의 지점 간 링크에 결합하고 상위 계층 패킷의 단편을 운반하는 것을 상정했다. 유사한 어휘가 두 시스템의 동작 면을 서로 교체 가능하게 만들지는 않았다.

출처와 한계

이 글은 RFC 793, 916, 1055, 1661, 1662와 RFC 916에 관한 RFC Editor의 현재 기록을 사용한다. 이것들은 프로토콜 정의와 경계가 분명한 비교를 확립한다. 그것들은 RATP의 배포 보급, 프로토콜들 사이의 직계 계보, 현재 제품 동작, 현대의 사건을 확립하지 않는다.

체크섬은 서명이 아니다. 정확한SO패킷은 그 바이트를 입력한 사람을 식별하지 않고, 수신 프로그램이 그것에 복종하도록 승인하지 않고, 암호화하지 않으며, 응용 완료를 증명하지 않는다. 지속되는 역사적 요점은 더 작다: 4옥텟의 와이어 옥텟으로 충분했던 것은 양쪽 종단이 상태, 용량, 그리고 아직 미해결일 수 있는 것에 관한 엄격한 규칙을 공유했기 때문일 뿐이다.