요약

  • RFC 1553은 송신 측과 수신 측의 대응되는 슬롯에 완전한 헤더를 저장하는 방식으로 반복되는 IPX 정보를 압축했습니다. 사라진 바이트는 '없음'이 아니라 공유 상태가 되었습니다.
  • 일반적인 IPX 컨텍스트에는 이후의 압축 프레임이 안전해지기 전에 Confirmed Initial과 그에 대응하는 Confirm이 필요했습니다. 슬롯 번호 자체까지 압축하려면 복호화기가 모든 수신 오류를 알아야 했고, 폐기가 한 번 발생하면 명시적 슬롯이 도착할 때까지 암시적 슬롯 패킷을 거부해야 했습니다.
  • 이 메모의 대략 2:1 수치는 가정된 패킷 크기에 기반한 예시적 계산이었습니다. 1993년의 Standards Track 지위와 오늘날의 Historic 지위는 문서적 사실이며, 실제 배포, 측정된 성능 또는 응용 성공의 증거가 아닙니다.

한 옥텟이 담고 있지 않은 역사를 실어 나르다

저속 WAN 링크를 사이에 두고 마주 보는 두 개의 표를 상상해 보십시오. 왼쪽의 슬롯 7에는 완전한 IPX 헤더가 들어 있습니다: 송수신 주소, 패킷 유형, 홉 수, 체크섬 관례, 길이 컨텍스트가 모두입니다. 오른쪽의 슬롯 7에는 같은 헤더가 들어 있습니다. 이후의 패킷은 사실상 "이미 합의된 내용을 재사용하라"고 말하는 아주 작은 CIPX 헤더만 실을 수 있습니다.

패킷이 짧은 이유는 관계가 길기 때문입니다.

그것이RFC 1553, 즉Compressing IPX Headers Over WAN Media (CIPX)의 동작 아이디어입니다. 이 문서의Datatracker 기록과RFC Editor 정보 페이지는 IETF Point-to-Point Protocol Extensions 워킹 그룹이 1993년 12월에 Standards Track으로 발행한 문서임을 확인해 주며, RFC Editor는 현재 이를 Historic으로 표시하고 있습니다.일반 텍스트판은 같은 사양을 그대로 보존하고 있으며,오류 정정(errata) 표면은 문서적 확인 수단입니다.

이 기록들은 무엇이 규정되었는지를 증명합니다. 그러나 어떤 제품이 이를 구현했는지, 얼마나 자주 실행되었는지, 실제 워크로드가 어떤 압축률을 달성했는지, 어떤 사용자가 개선을 체감했는지는 증명하지 않습니다.

RFC 1553의 더 깊은 역사적 가치는 '생략의 대가'에 있습니다. 자족적인 헤더는 정보를 반복합니다. 압축된 헤더는 수신 측의 기억을 대가로 바이트를 절약합니다. 따라서 이 프로토콜은 패킷 구문뿐 아니라 생략된 필드에 의미를 부여하는 분산된 기억까지 다스려야 했습니다.

두 압축 전략은 하나의 의존성을 공유했다

평범한 IPX 헤더는 30옥텟을 차지했습니다. RFC 1553은 두 가지 전략을 요구했습니다. 일반 방식은 전송 프로토콜에 의존하지 않고 IPX 헤더를 1~7옥텟으로 압축할 수 있었습니다. 두 번째 방식은 NCP 요청·응답 유형 0x2222와 0x3333을 위한 36옥텟짜리 NCP/IPX 결합 헤더를 대상으로 삼아 이를 1~8옥텟으로 줄였습니다.

다른 NCP 유형은 NCP 전용 처리를 받지 못했습니다. 그러나 여전히 일반 IPX 방식을 사용할 수 있었습니다. 이 구분은 NCP 요청/응답 순서가 일반 IPX 데이터그램에는 없는 복구 근거를 제공했기 때문에 중요했습니다.

RFC 1553은 헤더 압축이 데이터 압축과 공존하는 것도 허용했지만, 순서가 정확성의 일부였습니다. 송신 측은 데이터 스트림을 압축하기 전에 헤더를 압축했습니다. 수신 측은 헤더를 재구성하기 전에 데이터를 복호화했습니다. "두 알고리즘 모두 활성화됨"만으로는 충분한 기록이 아니었고, 실제 실행된 순서가 또 하나의 영수증이었습니다.

이 방식은 Van Jacobson의RFC 1144에서 영감을 받았음을 공개적으로 밝혔습니다. RFC 1144의정보 페이지는 TCP/IP 헤더 압축을 저속 직렬 링크 맥락에 위치시킵니다. 이 관계는 선행 기술 맥락이며, CIPX가 TCP의 모든 복구 특성을 물려받았거나 같은 배포를 누렸다는 증거가 아닙니다.

압축은 한 쌍의 상태 기계였다

협상 이후에는 압축되지 않은 평범한 IPX 패킷조차 1옥텟짜리 CIPX 접두어를 실었습니다. 압축기와 복호화기는 연결 상태를 위한 표를 유지했습니다. 슬롯에는 원래 헤더가 저장되었습니다. 압축기는 새 패킷과 저장된 사본을 비교해 무엇이 바뀌었는지 판단했고, 복호화기는 전송된 차이를 자신의 사본과 결합해 원래 헤더를 재구성했습니다.

이는 압축된 프레임 하나만 담은 패킷 캡처가 그 자체로 재구성된 헤더를 증명할 수 없다는 뜻입니다. 조사자는 선택된 슬롯, 슬롯 세대(generation), 그것을 설치한 Initial, 이후의 모든 필드 갱신, 그리고 설치 시점부터 해당 프레임까지의 손실·폐기 이력까지 함께 확보해야 합니다.

가장 작은 CIPX 헤더는 플래그 옥텟 하나일 수 있었습니다. 선택적 비트가 패킷이 슬롯 번호, 체크섬, 길이, NCP 태스크 번호를 추가로 실는지를 결정했습니다. 어떤 필드가 없을 때 수신 측은 규칙을 적용했습니다: 마지막 슬롯을 사용하거나, 관례적인 0xFFFF 체크섬을 가정하거나, 하위 계층에서 길이를 도출하거나, 이전 태스크 번호를 재사용하는 것입니다.

따라서 각 생략은 패킷 밖의 어떤 권위를 지명했습니다. "없음"은 "무관함"이 아니라 "이 다른 근거로부터 복구하라"는 의미였습니다.

최초의 일반 컨텍스트는 확인을 요구했다

RFC 1553은 일반 IPX Initial의 손실을 특수한 문제로 다뤘습니다. 그 패킷이 사라진 뒤 송신 측이 압축된 패킷을 내보내면, 수신 측에는 재구성에 필요한 헤더가 없습니다. 평범한 IPX 헤더에는 재전송을 식별하고 연관을 자동으로 복구할 만한 충분한 정보가 없었습니다.

프로토콜은 Confirmed Initial 패킷으로 답했습니다. 이 패킷은 완전한 IPX 패킷에 슬롯 번호와 1옥텟 ID를 더해 실었습니다. 수신 측의 Confirm은 슬롯과 ID를 되돌려 보냅니다. 그 확인을 받은 뒤에만 압축기가 해당 연관에 대해 압축 프레임을 보내기 시작할 수 있었습니다.

슬롯과 ID를 합치면 헤더 세대를 지명했습니다. 같은 슬롯을 다른 헤더에 재사용하려면 ID를 증가시켜야 했습니다. 이 문서는 영구적인 고유 식별자를 정의하지 않았습니다. 대신 "합리적으로 긴 기간" 동안 반복될 가능성이 낮은 조합을 요구했으며, 그 실질적인 길이는 전송 속도, 왕복 지연, 부하에 달려 있었습니다.

이 경계된 고유성이 중요합니다. 슬롯 번호만으로는 저장 위치를 식별할 뿐, 그 저장소가 어떤 역사적 내용을 담아야 하는지 알려 주지 않습니다. ID만으로는 슬롯 네임스페이스가 없습니다. Confirm은 지명된 연관의 수령을 증명할 뿐, 이후 모든 패킷의 성공적 전달이나 응용 결과를 증명하지 않습니다.

송신 측이 기다리면서 멈춰 있을 필요는 없었습니다. 같은 헤더에 대한 데이터가 더 도착하면 같은 슬롯과 ID로 또 다른 Confirmed Initial을 보낼 수 있었습니다. 다른 헤더가 그 슬롯을 필요로 하면 증가된 ID로 새 Confirmed Initial을 발행할 수 있었습니다. 효율은 여전히 가능했지만, 세대 변화는 관측 가능해야 했습니다.

NCP는 더 좁은 비확인 경로를 허용받았다

NCP 요청·응답 패킷에는 추가적인 성질이 있었습니다: 그 순서 번호는 보통 1씩 증가하고, 정상적인 전송 계층 동작은 잃어버린 패킷을 재전송할 수 있었습니다. RFC 1553은 이 신호를 근거로 Unconfirmed Initial을 허용했습니다. 이를 보낸 뒤 압축기는 Confirm을 기다리지 않고 곧바로 압축 프레임을 보낼 수 있었습니다.

이 허용은 확인이 결코 중요하지 않다는 선언이 아니었습니다. 이는 이후의 불일치가 가시화되는 데 의존했습니다. 관측된 순서가 이전 순서보다 정확히 1 크지 않으면, 같은 슬롯을 재사용하더라도 송신 측은 새 Initial을 보내야 했습니다. 잃어버린 압축 패킷은 의미 있는 체크섬이나 이후의 재전송을 통해서도 드러날 수 있었습니다.

이것은 국소화된 복구 규칙입니다. 일반 IPX가 NCP 때문에 이를 얻는 것은 아니었습니다. 순서 필드의 존재가 모든 손실이 이미 감지되었음을 증명하지도 않습니다. 기록은 어떤 압축 전략이 적용되었는지, 복호화기가 어떤 순서를 기대했는지, 어떤 패킷이 진행을 깨뜨렸는지, 어떤 Initial이 컨텍스트를 복구했는지를 보여 주어야 합니다.

슬롯 옥텟을 절약하려면 더 나은 관측 가능성이 필요했다

기본적으로 압축된 패킷은 자신의 슬롯을 선택할 만한 충분한 정보를 실었습니다. RFC 1553은 한 단계 더 나은 최적화를 제공했습니다: 슬롯 식별자를 생략하고 수신 측에게 바로 앞 패킷과 같은 슬롯을 사용하라고 지시하는 것입니다.

옥텟이 하나 더 사라졌습니다. 상태 하나가 더 암시적으로 되었습니다.

따라서 사양은 엄격한 사전 조건을 부과했습니다. 슬롯 압축은 수신 측이 모든 오류 패킷과 폐기된 패킷을 설명할 수 있는 경우에만 활성화될 수 있었습니다. PPP 링크에서는 링크 계층이 수신 오류를 복호화 모듈에 전달해야 했습니다. 그 신호가 없으면, 활성 슬롯을 바꾼 패킷이 사라졌을 때 복호화기는 이후의 암시적 참조가 어떤 슬롯을 뜻하는지 알 수 없게 됩니다.

일단 폐기가 발생하면 수신 측은 추측이 허용되지 않았습니다. 명시적 슬롯을 실은 패킷이 도착할 때까지 슬롯 번호를 생략한 이후 패킷들을 폐기해야 했습니다.

이 거부는 처리량 그래프에서 낭비처럼 보일 수 있습니다. 그러나 실제로는 근거의 보존입니다. 알 수 없는 컨텍스트에서 재구성된 바이트를 전달하면 감지 가능한 공백이 침묵하는 손상으로 변합니다. RFC 1553은 헤더를 지어내는 대신 일시적인 가용성 손실을 선택했습니다.

이 교훈은 모든 현대 압축기가 CIPX라고 주장하지 않으면서도 이 프로토콜을 넘어 확장됩니다. 어떤 최적화가 "지난번과 같으므로"라는 이유로 식별자를 제거한다면, 그 안전성은 "지난번"의 의미를 바꿀 수 있는 모든 사건을 관측하는 데 달려 있습니다.

Regular, 재시작, Reject 경로는 불일치를 가시적으로 유지했다

모든 패킷이 슬롯을 받을 자격이 있었던 것은 아닙니다. RFC 1553은 압축할 수 없는 트래픽, 메모리 부족, 표를 구성할 가치가 없는 산발적 흐름, 알고리즘을 무력화할 수 있는 미래의 IPX 변경을 위해 Regular 패킷을 유지했습니다. 좋은 효율 메커니즘에는 진실한 비효율 경로가 필요했습니다.

이 문서는 또한 중요한 재시작 경계를 보호했습니다. 플래그 옥텟은 결코 0xFF일 수 없었습니다. 평범한 IPX 헤더는 0xFFFF 체크섬 값으로 시작하는 경우가 흔했기 때문입니다. 한 단말이 실패한 뒤 X.25 영구 가상 회로 같은 매체에서 재시작하면, 상대 단말이 여전히 압축이 활성화되어 있다고 믿는 동안 그 단말은 CIPX 접두어 없는 평범한 IPX를 보낼 수 있었습니다. 수신 측은 낡은 압축 상태로 재해석하는 대신 평범한 헤더를 인식하고 재협상해야 했습니다.

마지막으로 Reject 패킷은 복호화기가 지원하지 않는 패킷 형식이나 종속 플래그를 보고하게 했습니다. 인식된 부분은 반환되는 플래그 값에서 지워 나머지 비트가 거부된 기능을 식별하도록 할 수 있었습니다. 미래 확장이 알 수 없는 의미를 추측할 허가가 되어서는 안 됩니다.

Regular, 재시작 인식, Reject는 서로 다른 세 가지 출구였습니다. Regular는 송신 측이 협상된 프레이밍 안에서 의도적으로 완전한 패킷을 실었다는 뜻이었습니다. 재시작 인식은 살아 있는 상대의 상태가 협상된 가정과 모순된다는 뜻이었습니다. Reject는 프레이밍은 인식되었으나 어떤 기능이 아니었다는 뜻이었습니다. 이를 "압축되지 않은 트래픽"으로 뭉뚱그리면 복구 판단이 지워집니다.

협상에는 하나 이상의 형태가 있었다

PPP에서 압축은 기본적으로 비활성화되어 있었습니다. IPXCP 옵션이 압축된 패킷을 수신할 능력을 광고했고, 양방향 압축을 원한다면 각 단말이 별도로 요청해야 했습니다.RFC 1552와 그상태 기록이 인접한 IPXCP 맥락을 제공합니다. 앞선 History 위원회가 자신의 조건부Opened와 IPX-WAN 완료 문제를 담당합니다; 본 글에서는 그것을 다시 이야기하지 않습니다.

IPX-WAN도 CIPX를 협상할 수 있었습니다. 그 경로에서 압축은 대칭이었습니다: 양단이 같은 슬롯 수와 옵션을 사용하며, 수락된 Timer Response는 요청된 내용의 부분집합으로 제한되었습니다. 따라서 운영자는 "CIPX"라는 단어만으로 방향성을 추론할 수 없습니다. 영수증은 협상 경로와 실제 합의된 값을 명시해야 합니다.

동시대의RFC 1548과 이후의RFC 1661, 그리고 각각의1548과1661정보 페이지는 이 메커니즘을 둘러싼 PPP 아키텍처를 규정합니다.IANA PPP Numbers 레지스트리는 조율된 식별자를 보존합니다. 그러나 그 어느 출처도 두 단말이 같은 슬롯 표를 협상했거나 하나의 실제 패킷을 올바르게 재구성했음을 증명하지 않습니다.

매력적인 압축률은 가정의 장부였다

RFC 1553은 CIPX가 평범한 IPX 트래픽에 대해 헤더와 데이터를 합쳐 대략 2:1의 압축률을 낼 수 있다고 말했습니다. 이 문서의 성능 섹션은 그 수치가 어떻게 만들어졌는지 보여 줍니다: 평균 데이터 길이 26옥텟, 압축되지 않은 헤더 30옥텟, 압축된 헤더 2옥텟이라는 가정에 기반한 계산입니다.

이는 유용한 설계 계산입니다. 그러나 측정된 실측 결과는 아닙니다.

실제 이득은 패킷 크기, 활성 연결 수, 가용 슬롯 수, 슬롯 재사용, Regular 폴백, Initial과 Confirm 트래픽, 오류, 재전송, 링크 특성, 그리고 추가 데이터 압축 여부에 달려 있었습니다. 전송 바이트 카운터는 회선상의 절약을 보여 줄 수 있었지만, 그것만으로 복호화의 정확성이나 응용 지연을 보여 줄 수는 없었습니다.

보안 고려 사항(Security Considerations) 단락은 CIPX가 IPX의 기본 보안을 크게 바꾸지 않는다고 말했습니다. 이 진술은 이 메모의 분석 경계를 기록한 것입니다. 이는 현대적인 보안 보증도 아니고, 근거 없이 취약점을 지어내는 근거도 아닙니다.

Lu Heng의Running-Code Primacy는 압축률, 실제 실행되는 디코더, 관측된 결과를 서로 다른 계층에 유지하는 데 도움이 됩니다.Minimum Initial Specification, Localized Future Decision and Voluntary Adoption은 공유된 패킷 계약과 슬롯 할당이나 폴백 같은 국소적 결정 사이의 분리를 밝혀 줍니다. 그의현실 계층 규율은 등록된 식별자, 협상된 옵션, 저장된 컨텍스트, 재구성된 패킷, 사용자가 목격하는 결과가 서로를 사칭하지 않도록 막아 줍니다. 이 후대의 글들은 공개된 분석 렌즈이며, RFC 저자들의 사적 의도에 대한 증거가 아닙니다.

사라진 바이트에는 소유자가 있었다

RFC 1553의 가장 작은 헤더가 인상적인 이유는 이미 다른 곳에서 수행된 작업에 의존했기 때문입니다. 압축기가 슬롯을 선택했고, Initial이 완전한 헤더를 설치했고, Confirm 또는 프로토콜 고유의 복구 성질이 생략을 승인했고, 링크 계층이 선택된 최적화에 필요한 만큼 손실을 가시화했고, 복호화기가 같은 역사를 보존했습니다.

그에 상응하는 책임 있는 운영 기록은 패킷보다 큽니다: 협상 주체와 방향; 수락된 옵션과 슬롯 수; 슬롯 할당과 세대 ID; 완전한 Initial 헤더; 필요한 경우의 Confirm; 링크 오류 통지; 폐기된 패킷 순서; 명시적 또는 암시적 슬롯 선택; 체크섬과 길이의 권위; 재구성된 헤더 해시; 복호화기의 조치; 전송 계층 복구; 그리고 응용 결과.

그 연쇄만이 1옥텟짜리 헤더가 왜 충분했는지 설명할 수 있습니다. 압축은 정보를 폐지하지 않았습니다. 관할권을 다시 배정했을 뿐입니다.

출처