요약

  • RFC 3321은 특히 신뢰할 수 없는 전송 환경에서 압축기가 명시적 확인 응답을, 원격 압축 해제기에 상태가 설정되었다는 증거로 사용할 수 있게 했다.
  • 그 증거는 시간이 지나면서 무의미해질 수 있다. 메모리 압박, 이후의 상태 생성 및 보존 규칙이 확인된 상태를 제거할 수 있으므로, 압축기는 원격 용량을 추적하고 이후의STATE_NOT_FOUND를 새로운 사실로 다루어야 했다.

영구 임대가 아니라 생성에 대한 영수증

RFC 3321은 2003년 1월 SigComp 이야기에 매력적인 제안과 함께 등장했다. 두 시그널링 엔드포인트가 이전 메시지를 기억할 수 있다면, 이후 메시지는 그 공유된 이력을 바탕으로 압축될 수 있다. 압축기는 더 이상 모든 SIP 또는 RTSP 메시지를 고립된 객체로 다룰 필요가 없었다. 그러나 동적 압축은 송신자가 가진 수신자 메모리 모델이 정확할 때만 동작한다. 원격 Universal Decompressor Virtual Machine이 검색할 수 없는 사전을 참조하는 것은 효율을 떨어뜨리는 데 그치지 않고 압축 해제를 실패하게 만들 수 있다.

그래서 이 문서는 압축기에 영수증을 주었다. 명시적 확인 응답은 압축 해제기가 성공적으로 저장한 상태를 식별한다. RFC 3321은 그런 참조를acked_state_id라고 부르며, 압축기는 원격 압축 해제기에 설정된 상태만 사용해야 한다고 규정한다. 상태 생성 메시지가 유실되거나 순서가 뒤바뀔 수 있는 신뢰할 수 없는 전송에서, 그 확인은 실제 증거 공백을 메운다.

그러나 이후의 모든 공백을 메우지는 못한다. 확인 응답은 사건을 보고한다. 상태가 설정되었다는 사실이다. 그것이 수신자의 메모리를 고정시키거나, 바이트를 영원히 예약하거나, 이후의 상태가 그것을 대체하지 않을 것을 약속하지는 않는다. 이 시간적 한계가 이 글의 중심 경계다. 영수증은 발급 시점에는 정확하지만, 그것에 근거해 행동하는 시점에는 낡아 있을 수 있다.

신뢰성 있는 전달은 영구 보존이 아니다

RFC 3321은 TCP 같은 신뢰성 있는 전송이 이전 메시지의 수신을 보장하는 반면, 신뢰할 수 없는 전송은 SigComp의 명시적 확인 응답 메커니즘이 필요하다고 언급한다. 이 문장은 쉽게 과도하게 읽힌다. 신뢰성 있는 전달은 메시지가 순서대로 도착했는지를 답한다. 그것만으로는 애플리케이션이 상태 저장 요청을 승인했는지, 충분한 상태 메모리가 존재했는지, 저장된 상태가 이후의 메모리 관리에서 살아남았는지를 답하지 않는다.

이 시리즈의 기초가 되는 RFC 3320 문서가 첫 번째 구분을 다루었다. 압축 해제가 성공했다는 것이 영속 상태 생성의 승인은 아니라는 점이다. RFC 3321은 그 관문 다음부터 시작한다. 승인되고, 생성되고, 확인 응답까지 받은 상태조차 수명 주기를 갖는다. 전송 전달, 상태 생성, 지속적 가용성을 하나의 '확인됨' 비트로 뭉개 버리는 압축기는 이후의 실패를 설명하는 데 필요한 구분 자체를 지워 버린다.

체크포인트는 불멸이 아니라 중요했다

RFC 3321의 체크포인트 메커니즘은 이 수명 주기를 드러나게 만든다. 압축기는 새로 생성한 상태에 자신이 보낸 최고 보존 우선순위를 표시하고 명시적 확인 응답을 요구할 수 있다. 그러나 같은 절은 참조된 상태가 존재하지 않을 수 있는 세 가지 이유를 나열한다. 생성 메시지가 유실되었거나, 메모리 부족으로 생성이 이루어지지 않았거나, 상태가 생성된 뒤 메모리가 부족해져 나중에 삭제되었기 때문이다.

세 번째 경우가 결정적이다. 유효한 확인 응답과 이후의 상태 부재는 서로 모숫되는 기록이 아니다. 둘은 서로 다른 시점을 기술한다. 체크포인트는 삭제 규칙 아래에서 선호되는 복구 앵커이지 유한한 메모리의 예외가 아니다.

압축기는 원격 엔드포인트가 어느 정도의 상태 메모리를 제공하는지 추적하도록 지시받는다.state_memory_size파라미터는 이후의 체크포인트 생성이 가용 공간을 소비했을 때 이전 체크포인트가 삭제되었다는 추론을 뒷받침할 수 있다. '추론을 뒷받침할 수 있다'는 말이 중요하다. 이 파라미터는 살아남은 모든 상태를 이름으로 나열하는 원격 조회 가능한 목록이 아니다. 압축기는 여전히 용량, 생성 순서, 나이, 보존 우선순위를 결합해 현재의 믿음을 구성해야 한다.

암묵적 확인 응답은 참조 대상보다 오래 남을 수 있다

공유 압축은 같은 문제의 더 의외를 버전을 더한다. 엔드포인트는 압축하지 않은 메시지를 공유 상태로 저장하고 상대방이 그것을 사용할 수 있음을 표시할 수 있다. RFC 3321은 그 공유 상태를 이후에 사용하는 것이, 첫 엔드포인트에게 짝이 되는 상태가 원격에서 생성되었다는 것을 암묵적으로 알려 주는 최적화를 기술한다. 이는 별도의acked_state_id를 실어 나르는 일을 피할 수 있다.

이 최적화는 메모리와의 경쟁을 안고 있다. RFC 3321은 공고 정보가 성공적으로 전달될 수 있지만, 그것이 확인하는 것처럼 보이는 상태가 상태 메모리 부족으로 이후 삭제될 수 있다고 경고한다. 이 가능성을 고려하지 않으면 다음 압축 메시지가 더 이상 존재하지 않는 상태에 의존할 수 있다. 다시 말하지만 신호가 반드시 위조된 것은 아니다. 그것의 범위가 '상태가 지금 존재한다'보다 단지 좁을 뿐이다.

이것이 프로토콜의 증거가 유형화된 상태로 남아야 하는 이유다. 반환된 식별자는 확인된 상태, 공유 상태 또는 전역 상태를 나타낼 수 있으며, RFC 3321은 확장 메시지 형식의 일부를 구현체에 맡긴다. 기본 SigComp 구현은 확장 메커니즘의 식별자를 무시할 수 있다. 따라서 피드백 필드에서 바이트를 보는 것으로는 충분하지 않다. 압축기는 그 바이트에 의미를 부여하는 메커니즘, 매핑, 현재 수명 주기 맥락을 필요로 한다.

수정은 불확실성을 명시적으로 만들었다

RFC 4896은 나중에 SigComp의 보존 규칙을 명확히 했다. 순서는 직관에 반한다. 보존 우선순위 65535는 0보다 낮고, 그다음이 1부터 65534까지다. 더 중요한 것은, 보존 우선순위가 컴파트먼트의 참조에 속하며, 최소 우선순위의 공유 상태 여러 개가 수신자의 내용을 압축기에게 모호하게 만들 수 있다는 점이다.

이 수정은 양쪽 엔드포인트가 모두 SigComp 규칙을 따르는데도 압축기가 공유 상태가 밀려나고 나서도 계속 사용 가능하다고 믿는 예를 제공한다. 그 결론은 운영적으로 엄격하다. 상태의 존재를 확신할 수 없는 한 압축기는 그 상태를 참조해서는 안 된다. 공고는 나이와 보존 우선순위 삭제 규칙으로 정의된 수명 동안의 가용성을 약속할 수 있다. 그것은 영속성의 약속이 아니다.

RFC 4077은 나중에 낙관적 모델이 실패하는 순간을 위한 부정 확인 응답을 제공했다.STATE_NOT_FOUND는 검색에 실패한 참조 상태를 식별하며, 보통 압축기가 이후 메시지에서 그 상태 사용을 중단하게 만든다. 이 NACK은 새로운 증거이지, 이전 확인 응답이 거짓이었다는 증명이 아니다. 두 기록 사이에는 보존, 축출, 믿음의 역사가 있다.

따라서 RFC 3321의 지속적인 교훈은 특정 압축률보다 시간 경계가 있는 영수증에 관한 것이다. '원격에서 생성되었다'는 유용한 사실이다. '아직 검색 가능하다'는 서로 다른 사실이다. 프로토콜은 둘 다 보존할 때만 이해 가능하다.

출처