요약

  • RFC 3485는 모든 구현체가 하나의 불변이며 바이트 단위로 동일한 정적 상태를 가지도록 요구함으로써, SigComp가 첫 메시지에서 공통 SIP/SDP 자료를 참조할 수 있게 했다.
  • 문서의 정보성 단어 목록은 그 자료의 출처를 설명했지만, 상호운용성은 규범적 이진 값, 식별자, 길이, 정확한 오프셋/길이 슬라이스에 의존했다.

압축은 보통 과거로부터 학습한다. 첫 SIP 메시지에는 과거가 없었다. 이전 헤더나 세션 기술이 링크를 건넌 적이 없으므로, 압축기는 수신 측에서 메시지에서 파생된 상태를 아직 가리킬 수 없었다. RFC 3485는 공유된 과거를 미리 만들어냈다. 양쪽 끝점은 동일한 정적 사전이 이미 설치된 상태에서 시작하게 된 것이다.

이 편의는 이례적으로 엄격한 헌법적 규칙을 요구했다. SIP/SDP 사전은 유일했고, 이러한 프로토콜과 함께 사용되는 SigComp 구현체에 필수였으며, SIP나 SDP가 진화하더라도 함께 진화하지 않도록 설계되었다. 한 번 정의되고 그대로 유지될 것이었다. 이 경직성은 그렇지 않으면 최악의 순간에 되돌아올 질문을 피하게 해주었다. 첫 압축 메시지를 보내기 전에, 상대 끝점은 어느 버전의 사전을 가지고 있는가?

답은 “제3판” 같은 협상된 라벨이 아니었다. 그것은 특정한 SigComp 상태였다. 섹션 3은 그 식별자, 길이, 최소 접근 길이, 그리고 값의 모든 바이트를 고정했다. SigComp 상태 조회가 일치 규칙을 제공했기 때문에, 압축기는 표시된 STATE-ACCESS 연산에서 여섯 바이트짜리 부분 상태 식별자를 사용할 수 있었다. 객체 전체는 스무 바이트 값과0x12E4라는 상태 길이로 식별되었다.

이 때문에 문서의 편집 구조가 중요해진다. 부록 A와 B는 SIP와 SDP 입력 문자열, 우선순위, 오프셋, 길이, 포함 근거가 된 참조를 나열한다. 이 표들은 읽기 쉽고 유용하지만 정보성이다. 규범적 사전은 섹션 3의 이진 표현이다. 부록의 이름에는 동의하면서 한 바이트를 다르게 배치한 두 구현체는 동일한 상태를 가지지 않는다.

이진 객체는 연결된 두 영역으로 구성되었다. 문자열 부분집합은 기여된 각 문자열이 부분 문자열로 존재하도록 자료를 저장했고, 테이블 부분집합은 각 항목마다 1바이트 길이와 2바이트 오프셋을 저장하며, 오프셋에 1024를 더해 UDVM 주소 1024에 적재된 사전을 직접 가리킬 수 있게 했다. 알고리즘은 문자열 자료를 직접 사용할 수 있었고, LZ78 계열 방법은 테이블의 토큰으로 시작할 수도 있었다.

배치는 공간을 공격적으로 재사용했다. 공통 부분 문자열이 허용하는 곳에서는 여러 문자열이 겹치는 영역을 차지할 수 있었다. 예를 들어 익숙한Proxy-접두어는 공유되고, 남은 조각들은 인증과 인가 헤더를 각각 표현할 수 있었다. SIP 응답 코드는 규범적 코드 하나와 코드에 제안된 이유 구문만 붙은 것 하나, 두 항목을 가질 수 있었는데, 두 항목 모두 공유 바이트를 가리켰다.

따라서 서식 자체가 증거의 일부였다. 사전 문자열은 대소문자를 구분했다. 헤더 자료는 종종 앞선 CRLF, 콜론, 예상되는 공백까지 포함했다. SIP 메시지는 문법에 맞는 다른 합법적 공백을 사용하면서 사전으로부터 얻는 이득이 줄어들 수 있었다. “토큰이 사전에 존재한다”로는 충분하지 않았다. 메시지의 바이트가 참조된 바이트 시퀀스와 일치해야 했다.

우선순위는 또 하나의 계층을 더했다. 1에서 5까지의 값은 자료가 얼마나 자주 나타날지에 대한 저자들의 추정을 표현했으며, 숫자가 작을수록 예상 빈도가 높았다. 자주 나오는 자료는 일부 압축 알고리즘이 효율적으로 참조할 수 있는 위치에 배치되었다. 이 우선순위는 설계 판단이었지, 이후 네트워크 트래픽에 대한 측정이 아니었다.

우선순위는 경계가 있는 적재도 가능하게 했다. RFC 3485는 우선순위 1만, 우선순위 1~2, 그리고 점점 더 큰 슬라이스로 모두 5까지, 각각에 대해 정확한 문자열 및 테이블 오프셋과 길이를 제공했다. 메모리가 제한된 UDVM은 사전을 다른 진화 중인 버전으로 취급하지 않고도 더 작고 가치 높은 영역에 접근할 수 있었다. 완전한 불변 상태가 참조 객체였고, 피연산자는 그 안에서 바이트 범위를 선택했을 뿐이었다.

이 구분은 감사에서 놓치기 쉽다. “정적 사전 사용됨”만 기록한 로그는 부분 식별자, 선택된 오프셋, 길이, 프로그램이 문자열 영역과 테이블 중 어느 쪽에 접근했는지를 생략한다. 들어온 바이트가 실제로 디코딩되었는지도 생략한다. 사전의 가용성은 전제 조건이자 명명 규칙이지, 압축 해제 영수증이 아니다.

또한 압축 해제가 성공했다고 해서 디코딩된 페이로드가 유효한 SIP나 SDP라는 증명은 되지 않는다. RFC 3320은 영구 상태 생성에 대해 압축 해제 이후에 애플리케이션 인가를 배치했다. RFC 3321은 나중에 동적 상태의 확인 응답과 수명을 다루었다. RFC 3322의 성능 수치는 단순화된 모델에서 나왔다. RFC 3485는 그 어느 결과도 소유하지 않았다. 그것의 주제는 즉각적인 참조를 가능하게 만든 미리 존재하는 정적 상태였다.

이후 문서들은 객체를 재작성하지 않으면서 계보를 명확히 했다. RFC 3486은 SIP가 SigComp 사용을 신호하는 방법을 기술했다. RFC 4464는 구현체에게 정적 사전을 설명했고, RFC 4465는 RFC 3485 상태에 접근하는 토처 테스트를 포함했다. RFC 4896은 더 넓은 SigComp 문제를 고치면서 배치를 다시 서술했다. RFC 5049는 SIP SigComp 구현체가 사전을 지원하도록 요구했다. RFC 5112는 프리즌스 전용의 별개 정적 사전을 정의했으며, 이 사전을 조용히 수정하지는 않았다.

보안 섹션은 의도적으로 짧았다. RFC 3320의 고려사항이 적용되며, RFC 3485는 새로 알려진 위험을 주장하지 않는다는 것이었다. 그 진술이 압축을 인증으로 바꾸지는 못했다. 올바른 사전 식별자를 안다고 해서 발신자 신원, 인가, 메시지 무결성, 전달, 성공적인 세션이 증명되지 않는다. 이것들은 별개의 영수증으로 남는다.

문서는 특정 배포나 달성된 압축률도 보고하지 않았다. 서론은 저장된 상태 없이 시작하는 것보다 더 좋은 첫 메시지 압축률과 더 짧은 설정을 기대한다고 말했지만, 표준 트랙 메커니즘은 현장 측정이 아니다. 링크 속도, 메시지 서식, 알고리즘 선택, 슬라이스 선택, 실제 내용이 모두 결과에 영향을 미칠 수 있었다.

Lu Heng의 실재 계층 방법은 올바른 재구성 순서를 제시한다. 먼저 완전한 규범 상태를 해시하고 고정된 메타데이터를 확인하라. 그다음 부분 식별자와 모든 STATE-ACCESS 피연산자를 보존하라. 가리켜진 바이트와 우선순위 슬라이스를 해석하라. 이것들을 압축 메시지와 압축 해제기 트레이스와 비교하라. 그 후에야 프로토콜 파싱, 인증, 전달, 세션 증거를 연결하라.

RFC 3485의 역사적 거래는 검소하고 강력했다. 어느 쪽 끝점도 말하기 전에 공통 기억을 제조함으로써 첫 메시지를 더 작게 만들었다. 그러나 공유 기억이 작동한 것은 편집 가능한 책이 아니었기 때문이다. 그것은 봉인된 바이트 배열이었고, 첫 메시지가 상대편에 어느 판이 있는지 묻지 않고도 빌려올 수 있을 만큼 영구적이었다.

출처