요약

  • RFC 2395는 모든 데이터그램 앞에서 LZS 기록을 리셋하고 압축 결과를 매번 플러시하는 방식으로 2,048바이트 LZS 슬라이딩 윈도우를 IP에 맞추어, 어떤 패킷도 이전 압축 상태에 의존하지 않도록 했습니다.
  • 고정된 종료 마커가 압축 데이터를 패딩과 구분했지만, 이는 비트스트림의 닫힘만을 보여줄 뿐 패킷을 인증하거나, 유효한 압축을 보증하거나, 애플리케이션 성공을 확립하지 않았습니다.
  • 약 90바이트 임계값과 Calgary Corpus 비율은 유한한 측정값이었습니다. 변환 합의는 디코더를 지명했을 뿐, 패킷 사용 여부, 크기 이득, 성공적인 압축 해제, 전달된 작업은 별개의 증거로 남았습니다.

유용한 기억이 위험한 의존성이 되다

압축은 반복에서 출발합니다. LZS는 2,048바이트 슬라이딩 윈도우를 유지하며 이미 본 바이트 문자열을 찾아 더 짧은 오프셋·길이 토큰으로 치환했습니다. 유용한 패턴이 메모리에 오래 남아 있을수록 압축기가 발견할 기회가 많아졌습니다. 연속 스트림에서는 어제의 바이트가 내일의 바이트를 더 저렴하게 만들 수 있었습니다.

IP 네트워크는 정반대의 조건을 제공했습니다. 데이터그램 순서는 보장되지 않았습니다. 패킷이 사라지는 동안 다음 패킷은 온전히 도착할 수 있었습니다. 같은 발신지의 두 패킷이 서로 다른 경로를 택해 수신자에게 역순으로 도착할 수도 있었습니다. 디코더가 사라진 패킷의 사전을 필요로 한다면, 단 한 번의 손실이 하나의 페이로드뿐 아니라 사라진 기록을 참조하는 이후의 모든 페이로드를 손상시킬 수 있었습니다.

RFC 2395는 겉보기 최적화를 거부함으로써 이 문제를 해결했습니다. 각 데이터그램 페이로드를 처리하기 전에 발신자는 LZS 압축 기록을 리셋해야 했습니다. 압축된 데이터그램을 디코딩하기 전에 수신자는 압축 해제 기록을 리셋해야 했습니다. 같은 알고리즘이 여전히 슬라이딩 윈도우를 사용했지만, 윈도우의 수명은 한 패킷 안으로 제한되었습니다.

이 선택은 단순한 구현 지시가 아니라 아키텍처적 경계로 읽혀야 합니다. 알고리즘이 기억 메커니즘을 제공했고, 프로파일이 그 기억이 권한을 행사할 수 있는 기간을 결정했습니다. 공유된 알고리즘 이름이 상태 수명을 보편적으로 만들지는 않았습니다.

플러시는 다음 패킷을 기다리는 것이 없음을 의미했다

리셋만으로 경계가 닫히지 않았습니다. 스트림 압축기는 모든 입력을 받아들인 뒤에도 더 나은 인코딩을 기대하며 몇 비트나 바이트를 남겨둘 수 있습니다. 그런 동작은 현재 출력이 미래의 호출에 의존하게 만듭니다.

그래서 RFC 2395는 발신자가 압축된 데이터그램을 전송할 때마다 플러시하도록 요구했습니다. 해당 데이터그램의 모든 입력 바이트는 그 데이터그램의 출력에 나타나야 했습니다. 어떤 것도 이후 패킷을 위해 남겨질 수 없었습니다. 이 규칙은 페이로드가 네트워크의 독립적인 전달 단위를 넘어 흘러나오는 것을 막았습니다.

구분은 정확합니다. 플러시는 인코더가 모든 입력을 현재 압축 스트림에 방출했음을 보여줍니다. 그러나 패킷이 수신자에게 도달했는지, 수신자가 이를 수용했는지, 압축 해제가 성공했는지, 전송 계층 체크섬이 통과했는지, 애플리케이션이 재구성된 바이트를 사용했는지는 보여주지 않습니다. 인코더 접수는 전달 접수가 아닙니다.

이 유한한 설계는 RFC 2395를 LZS의 PPP 사용과도 구분합니다. RFC 1967의 LZS-DCP는 번호가 매겨진 기록을 유지할 수 있었고 명시적인 검사 및 리셋 교환을 정의했습니다. RFC 1974 역시 시퀀스와 기록 선택을 갖는 링크 프로토콜 안에서 동작했습니다. IPComp 프로파일은 대신 패킷 독립성을 선택했습니다. 이 문서들은 같은 알고리즘 계열을 공유할 뿐, 동일한 상태 계약을 공유하지 않습니다.

종료 마커는 비트를 닫았을 뿐 신뢰를 닫지 않았다

LZS는 원시 바이트 또는 오프셋·길이 참조를 방출한 뒤 정의된 종료 마커를 내보냈습니다. 압축 비트스트림이 반드시 옥텟 경계에서 끝나지는 않으므로, 페이로드에는 후행 패딩 비트나 바이트가 포함될 수 있었습니다. 마커는 디코더에게 의미 있는 압축 데이터가 어디서 끝나는지 알려주었고, 전송된 전체 페이로드는 여전히 정수 개의 옥텟을 차지해야 했습니다.

그 닫힘이 없다면 정렬에 쓰인 0이 압축 내용으로 오인될 수 있었습니다. 이것이 있으면 디코더는 지정된 지점에서 멈추고 후행 패딩을 무시할 수 있었습니다. 이는 변환 내부의 프레이밍 사실이었습니다.

그러나 이는 무결성 메커니즘이 아니었습니다. 종료 마커는 데이터를 저자에게 묶거나, 의도적인 수정을 막거나, 원래 데이터그램을 식별하거나, 디코딩된 바이트가 애플리케이션 기대와 일치함을 증명하지 않았습니다. 마커는 LZS 코드 스트림이 어디서 끝나는지 서술했을 뿐입니다. 인증과 암호화는 다른 계층, 다른 접수에 속했습니다.

RFC 2407은 LZS 변환 식별자를 역사적인 IPsec 해석 도메인에 배치했습니다. 이 연관성은 뒤의 독자가 압축을 보안 속성으로 취급하도록 유혹하기 쉽습니다. 그러나 문서들은 그렇게 하지 않았습니다.IPCOMP_LZS선택은 IP 압축 협회에서 피어들이 적용할 변환이 무엇인지 알려주었을 뿐, LZS를 암호학적으로 만들지 않았습니다.

합의는 모든 데이터그램에서의 사용을 요구하지 않았다

일반 IPComp 사양은 또 하나의 경계를 제공했습니다. 압축 협회는 변환을 위한 공유 컨텍스트를 만들었지만, 각 데이터그램은 여전히 독립적으로 서 있었습니다. 압축된 페이로드에 IPComp 헤더를 더한 크기가 원래 페이로드보다 작지 않다면, 발신자는 원래 형태를 전송하고 IPComp 헤더를 생략해야 했습니다.

RFC 3173은 RFC 2393을 대체하면서 그 비확장 원칙을 그대로 유지했습니다. 이 결과는 운영상 중요합니다. 설정된 LZS 협회는 압축되지 않은 패킷과 공존할 수 있습니다. 평범한 패킷을 보는 것이 협상 실패를 증명하지 않습니다. 프로토콜 108과 IPComp 헤더를 보는 것이 성공적인 압축 해제나 유용한 절감을 증명하지 않습니다.

RFC 2395는 LZS 내부에 적응형 압축 가능성 검사를 추가하지 않았습니다. 변환이 어떤 트래픽 클래스가 절망적이라는 것을 학습하고 시도를 멈추도록 하지 않았습니다. 구현은 호출 전에 로컬 휴리스틱을 적용할 수 있었지만, 그 정책은 알고리즘이 아니었습니다. 따라서 능력, 선택 정책, 관측된 결과는 서로 다른 계층으로 남았습니다.

90바이트는 관찰이지 법칙이 아니었다

RFC는 Calgary Corpus에 대한 비공식 테스트를 보고했습니다. 대략 90바이트 미만의 페이로드는 평균적으로 확장될 수 있었기 때문에, 구현은 그 크기 이하에서는 LZS 시도를 하지 않기로 선택할 수 있었습니다. 부록은 데이터그램 크기가 커질수록 압축 비율이 올라가는 모습도 보여주었습니다. 해당 코퍼스에서 64바이트에서 약 1.18, 16,384바이트에서 2.14였습니다.

이 수치들은 메커니즘을 설명했습니다. 매 패킷마다 리셋하는 방식은 작은 데이터그램에게 큰 데이터그램이 누릴 긴 기록을 부여하지 않았습니다. 고정 마커와 헤더도 짧은 페이로드에서 더 큰 비중을 차지했습니다. 하나의 경계 안에 더 많은 바이트가 있을수록 슬라이딩 윈도우가 활용할 반복이 많아졌습니다.

그러나 그 표는 보편적인 성능 계약이 아니었습니다. Calgary Corpus는 이름이 붙은 테스트 컬렉션이었습니다. 암호화된 바이트, 이미 압축된 이미지, 짧은 이진 제어 메시지, 적대적 입력, 다른 언어 분포는 다르게 동작할 수 있었습니다. RFC 자체가 90바이트 지점을 근사치로, 테스트를 비공식으로 서술했습니다.

RFC 2394는 병행하는 DEFLATE 프로파일과 자체 구현 맥락을 제공했습니다. RFC 3051은 다른 사전 기반 알고리즘을 독립적인 IP 데이터그램에 맞출 때 리셋 비용이 왜 중요한지 뒤에 설명했습니다. 어느 문서도 하나의 코퍼스를 네트워크 상수로 바꾸지 않았습니다. 알고리즘, 워크로드, 패킷화, 구현이 함께 결과를 결정했습니다.

역사적 라이선스는 채택 표면의 일부였다

RFC 2395는 당시 Hi/fn이 LZS에 대한 특허를 보유하고 있으며, 명명된 프로토콜 사용에 대한 무료 참조 라이선스와 기타 라이선스 옵션을 설명하고 있음도 공개했습니다. 이 단락은 패킷 구문은 아니었지만 실제 채택 표면에 속했습니다. 운영자와 구현자는 구현을 둘러싼 법적·공급 조건과 기술적 적합성을 결합해야만 변환을 평가할 수 있었습니다.

그 진술은 역사적 사실로 남아야 합니다. 이는 오늘날 누가 권리를 보유하는지, 특허가 여전히 집행 가능한지, 라이선스가 여전히 이용 가능한지, 현재 어떤 제품이 무엇을 할 수 있는지 확립하지 않습니다. 1998년 RFC는 1998년에 보고한 내용을 증명할 수 있습니다. 수십 년 뒤의 법적 상태를 몰래 갱신할 수는 없습니다.

이것이 이 프로파일의 더 넓은 교훈입니다. 공유 사양은 얇았습니다. 여기서 리셋, 여기서 플러시, 여기서 종료, 이 변환 식별자를 사용하라. 그럼에도 로컬 행위자들이 워크로드가 압축을 정당화하는지, 어떤 임계값을 시도할지, 라이선스와 하드웨어가 수용 가능한지, 운영 결과가 지속 사용을 뒷받침하는지를 여전히 결정했습니다.

독립성은 상속된 상태를 거부하는 대가로 얻어졌다

가장 중요한 성과는 부정적이었습니다. 수신자는 패킷 N+1을 디코딩하기 위해 패킷 N을 필요로 하지 않았습니다. 손실은 사전 재앙이 되는 대신 손실로 남았습니다. 재정렬은 네트워크가 신뢰성 있는 스트림을 흉내 내기를 요구하지 않았습니다. 압축기는 실패 도메인을 데이터그램에 맞추기 위해 기회의 일부를 포기했습니다.

이 타협은 우연히 뒤집기 쉽습니다. 패킷 간에 기록을 이어 가지는 구현은 깨끗한 벤치마크에서 비율을 개선하는 동시에 선언되지 않은 복구 의존성을 만들 수 있습니다. 합의된 LZS 변환을 보고하는 대시보드는 올바르게 압축되지 않은 채 남은 패킷들을 실패로 계산할 수 있습니다. 성능 보고서는 코퍼스, 헤더 비용, 리셋 조건을 보존하지 않은 채 90바이트 지침을 반복할 수 있습니다.

RFC 2395의 지속적인 기여는 이 사실들을 분리해 두는 규율입니다. 사용 가능한 알고리즘, 프로파일이 부과한 기억 수명, 실제로 변환된 패킷, 올바르게 닫힌 스트림, 성공적으로 복구된 페이로드, 관측된 애플리케이션 결과. 어느 하나도 다른 것의 접수를 발행할 수 없습니다.

출처