요약

  • RFC 1977은 압축하면 패킷이 커지는 경우 적격 패킷을 일반 PPP 형태로 보낼 수 있었지만, 양 끝단은 여전히 그 패킷을 동일하게 이어지는 BSD Compress 사전에 처리해야 했다.
  • 네이티브 패킷에는 LZWCLEAR코드가 없었기 때문에, 적응적 초기화는 양 끝단의 동일한 카운터와 비율 판단에 의존했다. 버전 1과 9–16비트 상한은 그 공유 이력의 시작 매개변수에 불과했다.
  • 16비트 시퀀스 번호는 이후 압축 패킷이 디코딩되기 전에 손실이나 재정렬을 드러낼 수 있었고, Reset-Request/Reset-Ack는 이전 이력을 버리고 새 이력을 시작했다. 탐지와 복구가 이미 본 트래픽을 인증하거나 보증하지는 않았다.

가장 중요한 패킷은 압축된 것처럼 보이지 않았다

RFC 1977을 오해하는 가장 쉬운 방법은 패킷 트레이스를 BSD 압축 트래픽과 그 밖의 모든 것, 두 무더기로 나누는 것이다. 그 구분은 눈에 보이는 PPP Protocol 필드를 따르지만 상태 머신을 따르지는 않는다. 적격 네트워크 계층 데이터그램은 네이티브 캡슐화로 링크를 건너면서도 양 끝단의 압축 사전을 바꿀 수 있었다.

이는 의도된 일이었다. BSD Unixcompress는 LZW를 사용했고, 입력을 처리한 뒤에야 출력이 더 작지 않다는 것을 알 수 있었다. RFC 1977은 유용한 거부권을 보존했다. 팽창이 유의미하면 송신자는 원래 PPP 패킷을 전송해야 했다. 3바이트 미만의 증가도 보통 네이티브 형태를 선호했다. 목적은 실용적이었다. 압축 불가능한 트래픽이 더 큰 압축 래퍼를 짊어져야 한다면, 상위 계층은 링크의 MTU가 더 작은 것처럼 동작해야 했을 것이다.

그러나 송신자는 패킷을 보고 압축이 이득이 없다는 것을 알지 못했다. 압축을 시도함으로써 알았다. 시도된 인코딩은 사전에 구문을 추가하고 코드 폭 임계값을 이동시켰으며, 사전이 언제 비효율적이 되었는지 판단하는 데 쓰이는 카운터를 갱신했다. 더 큰 전선 표현을 버린다고 해서 그 변화들까지 버릴 수는 없었다. 그렇게 하면 다음 압축 데이터그램은 수신자가 한 번도 구축한 적 없는 이력에서 인코딩될 것이다.

따라서 RFC 1977은 수신자에게 적격 프로토콜 범위의 네이티브 패킷을 팽창했을 패킷으로 취급하라고 지시했다. 수신자는 출력을 만들기 위해서가 아니라 송신자의 상태 전이를 재현하기 위해 수신 바이트를 로컬에서 압축했다. 부록은 그 연산을 명확히 부른다.pf_bsd_incomp는 압축 불가능한 데이터를 압축하는 척하여 BSD Compress 사전을 갱신한다.

전선의 패킷은 네이티브였다. 프로토콜 이벤트는 그렇지 않았다.

파일 압축기가 양방향 이력이 되다

고전적인compress는 파일을 대상으로 동작했다. RFC 1977은 그 코드를 사실상 무한한 PPP 데이터그램 시퀀스에 맞게 적응시켰다. 그 변화는 자연스러운 경계를 없앴다. 코드북은 더 이상 한 파일이 끝나면 사라지는 개인 작업 기억이 아니었고, 패킷 경계를 넘어 계속되는 공유 이력이 되었다.

그 이력에는 사전 항목 이상의 것이 포함되었다. 양측은 어떤 원래 프로토콜 값이 적격인지 합의해야 했고, 해당 PPP 옵션이 협상되었는지와 무관하게 압축 전에 내부 프로토콜에 Protocol-Field-Compression을 적용해야 했으며, 동일한 임계값에서 코드 폭을 늘리고 동일한 입력 및 가상 출력 바이트를 세야 했다. 참조 코드는 9비트 코드로 시작하고, 협상된 상한에 도달할 때까지 항목을 추가하며, 이후 초기화 결정을 위해 압축 비율을 유지한다.

그래서 구성 옵션은 작지만 중대했다. CCP 옵션 유형 21은 BSD Compress를 식별했다. 세 번째 옥텟은 버전001과 9~16비트의 최대 코드 폭을 담았다. 12가 흔하다고 설명되었다. 부록 구현은 9~15를 지원했는데, 이는 구현상 한계이지 명세의 협상 범위로 오해해서는 안 된다. 수신자는 메모리가 더 많다는 이유만으로 더 큰 테이블을 안전하게 선택할 수 없었다. 사전 충만도와 초기화 시점은 공유된 사실이었다.

협상은 PPP가 Network-Layer Protocol 단계에 도달하고 CCP가Opened에 도달한 뒤 그러한 공통 시작 규칙을 확립했다. 그것이 데몬과 커널, 드라이버와 사용자 프로세스, 또는 따로 작성된 두 구현이 이후의 모든 전이를 같은 순서로 적용한다는 것을 증명하지는 않았다.

CLEAR가 전선에서 사라지다

고전적인 LZW 어휘는 코드 256을CLEAR용으로 예약했다. 압축 패킷에서 송신자는 그 코드를 끝에 넣어 디코더에게 테이블을 버리라고 알릴 수 있었다. 네이티브 캡슐화는 더 어려운 사례를 만들었다. 일반 PPP 프로토콜 번호를 담은 패킷에는CLEAR가 안정적으로 나타날 수 있는 LZW 코드 스트림이 없었다.

RFC 1977은 초기화 결정을 항상 보이게 하는 대신 재현 가능하게 만드는 것으로 답했다. 부록은 사전이 가득 찬 뒤 10,000바이트 간격으로 압축 비율을 확인했다. 새 비율이 나빠지거나 1:1 아래로 떨어지면 상태가 초기화되었다. 송신자의 시험 압축기와 수신자의 로컬 시뮬레이션은 동일한 적격 바이트와 동일한 개념상 인코딩 크기를 세었으므로, 함께 임계값을 넘을 것으로 기대되었다.

이는 결정론적 거래였다. 추가 헤더를 절약하고 네이티브 MTU를 보존했지만, 구현 동일성을 협상된 레이블 이상에 의존하게 만들었다. 카운터 경과, 패킷 적격성, 코드 할당, 코드 폭 변경, 초기화 시점이 모두 상호운용성 입력이 되었다. 네이티브 패킷은 압축 표현을 정확히 생략하면서도 그 표현의 상태 효과는 유지했다.

초기화 직후의 첫 패킷들은 모호성을 더 날카롭게 했다. 거의 빈 사전은 보통 이득이 거의 없었으므로, 그 패킷들은 압축이 활성화되기 전에 보낸 패킷과 마찬가지로 네이티브로 나타날 가능성이 컸다. 관찰자는 캡슐화만으로 활성 이력을 추론할 수 없었다. 관련 근거는 제어 상태와 모든 적격 입력의 순서 있는 스트림이었다.

16비트는 손상을 멈출 수 있지만 이력을 보증하지는 못한다

BSD 압축 패킷은 16비트 시퀀스 번호를 담았다. 이 번호는 초기화 후 0에서 시작하고, 네이티브 패킷을 포함한 모든 적격 패킷마다 한 번씩 증가하며, 65535 이후에 감쌌다. RFC 1977은 디코딩 전에 값을 확인하라고 권고했다. 다음 압축 패킷이 수신자의 예상과 다른 카운트를 알리면, 수신자는 코드를 알려진 잘못된 사전에 공급하지 않을 수 있었다.

그것은 가치 있지만 좁은 범위다. 네이티브 패킷은 BSD Compress 시퀀스 필드를 얻지 않았다. 그런 패킷 하나가 사라지면, 손실은 이후 압축 데이터그램이 그 간극을 드러낼 때에야 보일 수 있었다. 그 번호는 어떤 입력이 없었는지, 원인이 손실인지 재정렬인지, 어떤 바이트를 학습했어야 하는지, 또는 이전에 수용된 패킷이 진본인지 말해주지 않았다. 그것은 불연속 탐지기였지, 대화 기록의 서명이 아니었다.

RFC 1977은 손상된 프레임에 대해 HDLC FCS와 일반적인 폐기 메커니즘에 의존했다. 보안 고려 사항 섹션은 보안 문제를 논하지 않는다고만 말한다. 따라서 감싸는 카운터와 링크 체크섬을 종단 간 무결성, 피어 인증 또는 권한 부여로 승격할 수 없다.

리셋은 포기 프로토콜이었다

수신자가 예상치 못한 시퀀스를 처음 보았을 때, CCP Reset-Request를 보내고 Reset-Ack가 도착할 때까지 압축 패킷을 폐기해야 했다. 그러면 양측은 시퀀스를 0으로 재설정하고 사전을 초기화했다. RFC는 그 결과를 하나의 “파일” 전송을 포기하고 다른 파일을 시작하는 것으로 설명했다.

그 단어가 중요하다. 리셋은 사라진 상태를 재구성하거나 이전 상태를 보증하지 않았다. 그것은 새로운 공유 시작을 확립했다. 송신자는 이전 Reset-Ack가 수신자에게 도달했는지 알 수 없었기 때문에 모든 Reset-Request에 대해 초기화하고 응답해야 했다. 수신자도 마찬가지로, 송신자가 이미 초기화했을 것이므로 일치하는 각 확인 응답마다 초기화해야 했다.

바쁜 링크에서는 확인 응답이 돌아오기 전에 하나의 오류 뒤에 여러 개의 사용할 수 없는 압축 패킷이 이어질 수 있었다. 수신자는 하나를 통과시키기에 충분한 요청을 재전송해야 했지만, 왕복 시간보다 자주 해서는 안 되었다. 중복 요청은 중복 초기화를 뜻했다. 1초는 예시로만 등장했지 보편적인 타이머가 아니었다. 새 CCP Configure-Request가 대신 더 높은 비용으로 재협상을 강제할 수도 있었다.

패킷 뒤에는 소프트웨어 경계도 숨어 있었다. 제어 데몬이 Configure-Ack나 Reset-Ack를 처리하고 커널 코드가 데이터를 처리한다면, 초기화는 압축을 다시 연 제어 메시지와 동기화되어야 했다. 수신자는 다음 패킷을 처리하기 전에 초기화해야 했다. 완벽하게 구성된 확인 응답도 데이터 경로에 비해 운영상 늦을 수 있었다.

기록이 증명하는 것

RFC 1977은 최소 공유 메커니즘의 간결한 예이다. 적격성, 버전 1, 코드 폭 한계, 시퀀스 산술, 비율 체크포인트, 리셋 동작을 독립 구현들이 같은 이력을 시도할 수 있을 만큼 엄격하게 정의했다. IANA 레지스트리는 여전히 CCP 옵션 21을 BSD Compress로 기록하며,0x00FD와0x00FB는 각자의 위치에서 압축 데이터그램에 할당되어 있다.

Lu Heng가 실행 코드 근거를 강조한 관점에서 읽으면, 교훈은 숨은 상태가 부당하다는 것이 아니다. 선언된 구성과 관찰 가능한 실행이 서로 다른 기록이라는 점이다. 피어는 버전 1과 12비트 코드를 확인 응답할 수 있지만, 운영자는 두 코드북이 함께 움직였다는 것을 보여주기 위해 여전히 패킷 순서, 네이티브 패킷 포함 범위, 카운터 전이, 초기화 확인 기록이 필요하다.

이 글은 RFC 1962의 일반 CCP 협상, RFC 1963의 직렬 데이터 프레이밍, RFC 1990의 멀티링크 재정렬을 다시 설명하지 않는다. 현재 배포, 특정 제품, 측정된 절감에 대해 어떤 주장도 하지 않는다. 역사적 주장은 더 좁다. RFC 1977에서 “비압축”은 선택된 전선 형태를 뜻했지 압축 상태의 부재를 뜻하지 않았다. 프로토콜은 양 끝단이 정확히 같은 패킷에서 그 구분을 이해할 때만 작동했다.

출처