요약

  • IPComp는 각 IP 데이터그램을 독립적으로 손실 없이 압축합니다. 패킷 손실과 재정렬이 이전 데이터그램에 대한 의존을 배제하므로, 수신 측은 동일한 관계 아래 압축된 패킷과 원본 패킷을 모두 수용해야 합니다.
  • 비확장 규칙이 결정적입니다. 압축된 페이로드에 4옥텟 IPComp 헤더를 더한 크기가 원본 페이로드보다 작지 않으면, 송신자는 IPComp 헤더 없이 원본 형태로 전송해야 합니다.
  • CPI는 해제 측이 선택하는 방향성·수신지 범위의 조회 값이며, 자격 증명이나 전역 알고리즘 식별자가 아닙니다. 협상은 역량을 확립할 뿐이며, 압축이 실행되었는지, 성공했는지, 도움이 되었는지는 패킷과 엔드포인트의 증거만이 보여 줍니다.

회선 위에 빈 자리를 남긴 협약

프로토콜 협상은 보통 이분법적 해석을 부릅니다. 기능은 합의되었거나 그렇지 않은 것입니다. 합의되면 관찰자는 그 표지가 나타날 것으로 기대합니다. IPComp는 그 지름길을 의도적으로 깨뜨렸습니다. 두 노드가 유효한 IPComp 협회(IPComp Association)를 공유하면서도, 특정 패킷은 프로토콜 번호 108도 IPComp 헤더도 실지 않은 평범한 형태로 그들 사이를 통과할 수 있었습니다.

그 부재는 실패 이후 임시로 꾸려낸 대체 수단이 아니었습니다. 압축이 자신의 오버헤드를 정당화할 수 없을 때 요구되는 결과였습니다. 협회는 압축되어 도착한 패킷을 수신자가 어떻게 해제할지를 기술했습니다. 모든 대상 페이로드를 압축하라고 명령하지는 않았습니다.

이 구분이 중요한 이유는 압축이 터널만의 속성이 아니기 때문입니다. 압축은 알고리즘과 한 번의 시도에서 제시된 바이트 사이의 관계입니다. 반복적인 페이로드는 줄어들 수 있습니다. 작은 제어 패킷은 커질 수 있습니다. 응용 프로그램이 이미 압축한 페이로드는 CPU를 소모하면서 길이는 그대로 나올 수 있습니다. 고정된 구성이 모든 미래 데이터그램의 결과를 미리 알 수는 없습니다.

비밀 유지가 압축을 무의미하게 만들기 전에 압축이 이루어져야 했다

RFC 2393은 1998년 12월 IPComp를 도입했습니다. 그 동기는 IPsec 바로 옆에 놓여 있었습니다. 암호화는 데이터를 무작위처럼 보이게 만들고, 한 번 암호화된 페이로드는 하위 계층에서 제거할 반복 구조를 대개 거의 남기지 않습니다. 압축과 암호화를 모두 원한다면, 압축이 암호화보다 앞서야 합니다.

처리 순서는 이 관찰에서 나왔습니다. 송신 측 압축은 인증·암호화 이전, 그리고 단편화 이전에 일어납니다. 수신 측 해제는 단편이 재조립되고 IP 보안 처리가 패킷을 인증·복호화한 뒤에야 수행됩니다. 압축기는 원본 페이로드를 보고, 해제기는 주변 보호가 자기 일을 마친 후에야 그것을 봅니다.

외부 IP 헤더가 무조건 삼켜지는 것은 아닙니다. IPv4에서는 그 헤더 뒤부터 압축이 시작됩니다. 그러나 IPsec 터널에서는 내부 IP 헤더가 외부 페이로드에 속하므로 압축 대상이 될 수 있습니다. IPv6에서는 중간 노드가 검사해야 하는 헤더는 압축 영역 밖에 유지됩니다. 단편 헤더와 IPComp가 모두 존재할 때, 단편화는 수신된 헤더 사슬에서 여전히 더 앞쪽에 위치합니다.

이것은 유용한 의미에서의 작은 규격이었습니다. 순서와 가시적 경계를 고정하면서, 개별 입력이 변환을 받을 자격이 있는지는 현지 기계가 스스로 판단하도록 남겨 두었습니다.

모든 데이터그램은 자기 자신의 압축 가능성 증명을 실었다

IPComp는 데이터그램 사이에서 상태가 없습니다. 각 패킷은 그 자체로 압축되고 해제됩니다. 해제기가 이전 패킷에서 물려받은 사전을 필요로 하지 않는 이유는, 그 패킷이 늦게 오거나 아예 오지 않을 수 있기 때문입니다. 성공적인 복원은 전달 이력에 의존해서는 안 됩니다.

이 설계는 한 결과가 다음 결과에 대해 말할 수 있는 것에 강한 한도를 둡니다. 41번 패킷에서 좋은 비율이 나왔다고 해서 압축기가 42번 패킷도 줄어들 것이라고 가정할 권한을 얻지는 못합니다. 최근 실패를 성능 힌트로 쓰는 것은 합리적일 수 있지만, 그 힌트가 수신자의 회선 계약을 바꿀 수는 없습니다.

따라서 RFC 3173은 적응형 구현이 연속 실패 후 몇 개 패킷 동안 시도를 멈추었다가 나중에 다시 검사하는 것을 허용합니다. 또한 알고리즘별 압축 가능성 검사가 작업을 조기에 중단하는 것도 허용합니다. 카운트, 임계값, 백오프는 모두 현지 구현의 선택이며, IPComp 헤더에 보편적 상수로 담기지 않습니다.

RFC 2394는 DEFLATE에 대한 구체적 예를 제공합니다. 비공식 테스트에 근거해 90바이트 미만 버퍼는 시도하지 말 것을 권합니다. 그러나 90을 보편적 IPComp 경계로 만들지는 않으며, 추가 압축 가능성 검사도 정의하지 않습니다. 다른 알고리즘, 프로세서, 링크, 트래픽 조합은 서로 다른 현지 임계값을 정당화할 수 있습니다.

비확장 규칙은 생략을 규범적으로 만들었다

중심 비교에는 프로토콜 자체의 비용이 포함됩니다. IPComp는 압축된 페이로드만이 더 짧은지를 묻지 않습니다. 그 페이로드에 4옥텟 IPComp 헤더를 더한 것이 원본 페이로드보다 작은지를 묻습니다. 그렇지 않다면 송신자는 압축되지 않은 원본 데이터그램을 전송해야 하며, IPComp 헤더를 추가하지 않습니다.

이 규칙은 두 가지 희소 자원을 보호합니다. 절감 없는 결과에 해제 사이클을 소모하는 것을 막고, 경로 MTU 이하에 맞던 원본 패킷이 최적화를 시도했다는 이유만으로 단편화가 필요한 더 큰 패킷으로 변하는 것을 막습니다.

이것은 특이한 증거 경계를 만듭니다. 프로토콜 108은 그 지점에서 IPComp 형태 패킷이 선언되고 있음을 증명합니다. 한 패킷에서 그것이 없다는 것은 생략된 이유 중 어느 것도 증명하지 못합니다. 페이로드가 임계값 이하였을 수도 있고, 적응형 카운터에 의해 건너뛰었을 수도 있고, 압축 불가로 판정되었을 수도 있고, 압축에 실패했을 수도 있고, 세션 정책에 의해 제외되었을 수도 있습니다. 캡처만으로는 어느 현지 분기가 선택되었는지 되돌릴 수 없습니다.

크기 감소가 이득을 증명하지도 않습니다. 더 적은 바이트가 빠른 링크가 절약하는 것보다 더 많은 CPU나 지연을 요구할 수 있습니다. 압축 비율은 콘텐츠 유형, 사용자 가치, 혼잡 완화를 식별해 주지 않습니다. 프로토콜이 보장하는 것은 손실 없는 복원과 회선 위의 비확장이며, 보편적 성능 향상이 아닙니다.

4옥텟이 디스패치를 복원하고 로컬 컨텍스트를 선택했다

압축이 이길 때는 IPv4 Protocol 또는 IPv6 Next Header가 108이 됩니다. 삽입된 4옥텟 헤더는 세 요소를 실습니다: 원본 Next Header 값, 예약된 Flags 옥텟 하나, 16비트 압축 매개변수 인덱스(CPI).

저장된 Next Header가 필수입니다. 해제 후 수신자는 IPComp를 제거하고 원본 디스패치 값을 복원하여 재구성된 페이로드를 원래 페이로드가 속했던 자리에 놓습니다. 결과는 새 응용 프로토콜이 아니라, 조건부 변환 이후 복구된 기존 패킷의 페이로드입니다.

CPI 역시 과잉 해석하기 쉽습니다. 0부터 63까지의 값은 잘 알려진 변환을 식별하고, 협상 범위와 사설 범위가 다른 네임스페이스를 제공합니다. 그러나 이 필드는 전역 이름이 아닙니다. 각 노드는 자신의 인바운드 CPI를 독립적으로 선택할 수 있고, 아웃바운드 패킷은 이를 해제할 노드가 선택한 CPI를 사용합니다. CPI와 수신지 주소가 함께 관련 압축 특성을 선택합니다.

따라서 동일한 숫자 CPI가 다른 수신지 컨텍스트에서는 다른 의미를 가질 수 있습니다. 잘 알려진 CPI조차도, 두 노드 사이의 협회들이 수명이나 적응형 카운터가 다를 때 그 협회들을 구분하기에 불충분해질 수 있습니다. RFC 3173은 협회의 고유성이 중요할 때 협상 범위 값을 권합니다. 회선 위의 숫자는 조회 입력이며, 그 상태가 어떻게 승인되고 유지되었는지에 대한 완전한 설명이 아닙니다.

기본 알고리즘이 없다는 것은 보이지 않는 불문율이 없다는 뜻이었다

두 노드가 IPComp를 사용하기 전에 CPI, 모드, 알고리즘, 필요한 매개변수를 담은 IPComp 협회를 수립합니다. 정책은 두 노드 사이의 모든 패킷에 적용되거나, 선택된 세션에만 적용될 수 있습니다. 두 방향은 별개이며 서로 다른 알고리즘을 선택할 수 있습니다.

기본 압축 알고리즘은 없습니다. 모든 IPComp 구현이 지원해야 하는 알고리즘도 없습니다. 상호 운용성은 명시적 공통 선택에서 나오며, "압축"이라는 단어가 DEFLATE나 다른 어떤 변환을 함축한다는 가정에서 나오지 않습니다.

RFC 3173이 원본 규격을 대체한 주된 이유는 IKE/IPsec 환경에서의 협상을 명확히 하기 위해서였습니다. 이후 IKEv2도 이 경계를 유지했습니다. 요청자는 하나 이상의 압축 알고리즘을 제안할 수 있지만, 응답은 최대 하나만 수용합니다. 구현은 제안되고 수용되지 않은 알고리즘으로 압축해서는 안 됩니다.

IKEv2는 수명도 읽을 수 있게 만듭니다. 가상 압축 협회는 그것을 담는 ESP 또는 AH Child SA 밖에서 독립적인 수명을 갖지 않습니다. 그 Child SA가 사라지면 압축 협회도 사라지고 별도의 Delete 페이로드를 받지 않습니다. 동시에 압축 협상은 암호 매개변수 협상과 별개로 유지됩니다. 수명을 공유한다고 해서 CPI가 암호화 키나 무결성 증명이 되는 것은 아닙니다.

압축은 중간자가 볼 수 있는 것을 바꾸었다

IPsec 없이 IPComp를 쓰면 경계 장치가 내부 프로토콜 필드를 기준으로 필터링하거나 계량화하는 능력이 줄어들 수 있습니다. 원본 Protocol 값은 IPComp 헤더로 옮겨 갔고, 포트 같은 전송 계층 필드는 압축된 바이트 안에 있습니다. IPComp 협회를 공유하지 않는 라우터는 그것들을 원래 위치에서 단순히 검사할 수 없습니다.

이것은 IPComp가 데이터를 암호화한다는 주장이 아닙니다. 압축은 기밀성이 아닙니다. 이것은 파싱과 권한의 문제입니다. 중간 상자는 자신의 정책이 의존하는 필드를 복원하는 데 필요한 상태를 더 이상 갖고 있지 않을 수 있습니다. 모든 패킷을 필터링하거나 계량화해야 하는 환경이라면, RFC 3173에 따라 관련 협회를 필터링 장치에 안전하게 전달해야 합니다.

따라서 운영 기록은 여섯 가지 사실을 구분해야 합니다. 역량이 구성되었는지, 협회가 협상되었는지, 패킷이 시도 대상으로 선택되었는지, 결과가 IPComp 헤더를 얻었는지, 수신자가 올바른 협회를 찾았는지, 해제가 원본 페이로드를 복원했는지. 이것들을 "압축 사용함" 하나로 뭉치면 정당한 생략과 실제 실패가 모두 가려집니다.

IPComp의 지속적 성과는 단순히 더 작은 페이로드를 IP 안에 넣은 것이 아니었습니다. 최적화가 각 패킷에 응답하도록 만든 것입니다. 공통 합의가 압축된 결과를 이해하는 안전한 방법을 제공했습니다. 실행 중인 바이트는 이번에는 압축할 가치가 없다고 말할 권리를 유지했습니다.

출처