요약

  • RFC 2187은 부모(parent) 캐시와 형제(sibling) 캐시를 주로 미스 이후에 무엇을 할 수 있는지로 정의했습니다. 부모는 캐시되지 않은 객체를 가져올 수 있었고, 형제는 이미 보유한 객체만 제공할 수 있었습니다.
  • 이 관계는 ICP에 인코딩되는 것이 아니라 로컬에서 구성되었습니다. 따라서 하나의 이웃이 어떤 요청에는 부모로, 다른 요청에는 형제로 취급될 수 있었고, 도메인·메서드·캐시 가능성·접근 제어 규칙이 실질적인 계층 구조를 바꾸었습니다.
  • ICP HIT 및 MISS 응답은 로컬 선택 결정의 근거였을 뿐, 상호 권한, 신선도, 인증된 신원, 최적 전달, 미래 용량 또는 최종 성공의 증명이 아니었습니다.
  • 이후의 캐시 문서들은 프로토콜 의미론과 배포 정책의 구분을 명확히 하면서도, 지연 시간에 민감한 피어 선택이 대역폭 및 역할 적합성과 충돌할 수 있음을 보여주었습니다.

RFC 2187의 어휘에서 기만적인 부분은 겉보기 기하학입니다. 부모는 상류처럼 들립니다. 형제는 측면처럼 들립니다. 하나의 라벨이 네트워크 위치와 운영 책임을 모두 담는 안정적인 토폴로지를 상상하기 쉽습니다.

그것은 유용한 독법이 아닙니다.

RFC 편집기의 RFC 2187 항목에 기록된 대로 1997년 9월 D. Wessels와 K. Claffy가 Informational RFC로 발표한 이 문서는 미스 처리가 결정적인 구분인 웹 캐시 계층 구조를 설명했습니다. 부모는 객체가 이미 캐시되어 있는지와 무관하게 객체를 가져올 수 있었습니다. 반면 형제는 자신이 이미 보유한 객체만 제공하는 것으로 여겨졌습니다. 형제가 요청된 객체를 갖고 있지 않다면, 요청자가 원점(origin)을 향해 계속 나아가야 하는 캐시는 그 형제가 아니었습니다.

이것은 권한 경계이지 물리적 거리에 대한 진술이 아닙니다.

이 구분이 중요한 이유는 응답이 히트일 때 두 역할이 비슷해 보일 수 있기 때문입니다. 어느 이웃이든 객체를 보유하고 있다고 보고하면 요청 캐시는 그곳에서 가져올 수 있었습니다. 역할이 갈라지는 지점은 캐시된 사본이 없을 때였습니다. 부모는 여전히 트랜짓 역할을 할 수 있었습니다. 형제는 그럴 수 없었습니다.

또한 이는 역할이 원격 기계의 영구 속성이 아닐 수 있음을 의미했습니다. RFC 2187은 동일한 이웃을 어떤 클래스의 요청에는 형제로, 다른 클래스에는 부모로 취급하는 것을 허용했습니다. 배포는 부모 관계를 특정 도메인으로 제한할 수 있었습니다. 캐시 가능하다고 간주되는 요청만 전달할 수도 있었습니다. 로컬 목적지, 다른 요청 클래스, GET이 아닌 요청 또는 스톱 리스트에 올라간 URL은 계층 구조를 우회하거나 ICP 처리 자체를 피할 수 있었습니다.

따라서 실질적인 계층 구조는 개별 요청에 적용된 정책에서 나왔습니다. 라벨은 허용된 행동을 요약했을 뿐, 그 행동을 독립적으로 확립하지는 않았습니다.

관계는 양쪽 모두에 존재해야 했다

구성된 피어 관계는 서로 다른 두 가지 행정적 결정에 의존했습니다.

요청 캐시는 이웃을 어떻게 분류하고 사용할지 결정해야 했습니다. 원격 캐시는 그 의도된 역할과 일치하는 접근 제어를 적용해야 했습니다. 원격 측이 미스 전달도 허용하는 방식으로 HTTP와 ICP 접근을 허용했다면, 운영 결과는 실질적으로 부모 동작이었습니다. 형제 관계를 강제하려면 원격 측에 미스 거부(deny-miss) 정책이 필요해서, 잘못되었거나 낡은 히트 가정 뒤에 도착한 요청이 조용히 트랜짓이 되지 않도록 해야 했습니다.

따라서 관계를 의미 있게 만드는 데는 관리자 간의 의사소통이 일부였습니다. 로컬 라벨만으로는 상대 캐시가 대응하는 제한을 적용한다는 보장이 없었습니다.

부모와 형제를 네트워크에서 발견되는 사실로 취급하면 이 세부 사항을 놓치기 쉽습니다. 이들은 ICP 메시지 안에 관계 선언으로 담기지 않았습니다. 프로토콜은 객체 조회에 대한 정보를 보고할 수 있었지만, 요청자는 여전히 이웃에 대한 자신의 지식을 통해 응답을 해석해야 했습니다.

이웃 캐시의 역할은 구성과 접근 정책에서 나왔습니다.

ICP는 관계가 아니라 신호를 제공했다

동반 문서인RFC 2186은 ICPv2의 메시지 형식과 오피코드를 설명했습니다. RFC 2187은 다른 문제, 즉 캐시가 계층 구조 내에서 ICP를 어떻게 사용할 수 있는지를 다뤘습니다.

이 구분이 중요합니다. 이웃의 ICP HIT는 “나는 이러한 계약적 권한 아래 당신의 형제다”라고 말하지 않았고, MISS도 “나는 이 요청을 계속 전달할 권한이 있다”고 말하지 않았습니다. 메시지는 관계를 인코딩하지 않았습니다. 요청 캐시는 신호를 자신이 구성한 역할 정보와 결합해야 했습니다.

형제의 HIT는 형제가 캐시된 사본을 제공할 수 있도록 허용되어 있었기 때문에 유용했습니다. 같은 형제의 MISS는 일반적으로 그 형제를 고려 대상에서 제외시켰는데, 형제는 미스 트랜짓을 제공할 것으로 여겨지지 않았기 때문입니다. 부모의 MISS는 반대 의미를 가질 수 있었습니다. 부모가 당장 객체를 보유하지 않을 수 있지만 여전히 그것을 가져올 수 있었기 때문입니다.

따라서 동일한 프로토콜 결과가 구성된 관계에 따라 서로 다른 다음 행동으로 이어질 수 있었습니다.

이것은 일부 요청이 ICP를 우회하는 이유도 설명해 줍니다. 로컬 캐시 히트에는 이웃 검색이 필요 없었습니다. 구성된 로컬 원점은 직접 선택될 수 있었습니다. GET이 아닌 요청과 스톱 리스트에 올라간 URL은 ICP 결정 경로 밖에서 처리될 수 있었습니다. 사용 가능한 부모가 하나뿐이라면, 캐시는 다음 홉 선택을 실질적으로 바꾸지 못할 ICP 교환을 기다리는 데 시간을 쓰는 대신 그냥 요청을 전달할 수 있었습니다.

프로토콜은 정책의 입력이었지, 모든 요청 앞의 필수 의식이 아니었습니다.

캐시 불가(no-cache) 사례가 형제 경계를 드러냈다

RFC 2187의Pragma: no-cache처리는 권한 구분을 이례적으로 명확하게 보여줍니다.

이 지시어를 담은 요청은 일반적인 형제 조회 논리를 통해 안전하게 보낼 수 없었습니다. 형제를 사용하는 요점은, 형제에게 캐시되지 않은 요청에 대한 책임을 부여하지 않으면서 확인된 캐시 객체를 그곳에서 가져올 수 있다는 것이었습니다. 그러나 no-cache 요청은 형제의 저장 사본을 넘어서는 동작을 필요로 할 수 있었습니다. 그런 경우 형제를 조회하면 이 역할이 금지하려 했던 바로 그 트랜짓 동작으로 향하는 경로가 만들어질 수 있었습니다.

따라서 계층 구조를 “가까운 캐시를 먼저 물어본다”로 환원할 수 없었습니다. 이웃이 상담 대상이 될 수 있는지조차 요청이 요구하는 처리 유형에 달려 있었습니다.

이것이 RFC 2187의 더 오래 지속되는 교훈입니다. 자원 탐색은 권한에 의해 제약되었습니다.

적격한 출처 가운데 고르는 것은 별개의 문제였다

정책이 적격한 이웃을 좁힌 뒤에도, 캐시는 그중에서 선택해야 했습니다.

RFC 2187은 여러 입력을 논의했습니다. 응답 지연은 피어 선택에 영향을 줄 수 있었습니다. 구현은 출처 왕복 시간(RTT) 정보를 보관할 수 있었습니다. 관리자는 구성된 가중치를 적용할 수 있었습니다. 멀티캐스트 응답은 선택에 영향을 주는 순서로 도착할 수 있었습니다.

그런 측정 어느 것도 미래의 전달 경로에 대한 증명이 아니었습니다.

빠른 ICP 응답은 이어지는 객체 전송이 최고 처리량을 가질 것이라고 확립하지 않았습니다. 저장된 RTT는 이전 통신에 대한 근거이지 다음 전송에 대한 보장이 아니었습니다. 구성된 가중치는 현재 요청의 관찰된 속성이 아니라 운영자의 선호를 나타냈습니다. 멀티캐스트 순서는 시간 정보를 드러낼 수 있었지만, 시간은 용량, 혼잡 상태 또는 종단 간 완료와 동등하지 않았습니다.

RFC 2187 자체가 두 가지 목표 사이의 모호성을 기록했습니다. 객체를 찾는 것과 피어 중에서 선택하거나 부하를 분산하는 것입니다. 이 작업들은 겹치지만 동일하지는 않습니다. 누가 객체를 갖고 있다고 말하는지 발견하도록 돕는 프로토콜이 자동으로 최적 출처 선택의 완전한 옵티마이저가 되는 것은 아닙니다.

이 한계는RFC 3143에서 더 명시적으로 드러났습니다. 이 문서의 알려진 HTTP 프록시 및 캐싱 문제 논의는, 다른 피어가 더 유용한 대역폭을 제공하더라도 첫 응답 기반의 선택이 낮은 지연 시간을 선호할 수 있다고 관찰했습니다. 또한 높은 대역폭의 캐시를 부모로 매력적으로 만드는 특성이 반드시 형제로서 똑같이 적합한 것은 아니라고 지적했습니다.

이것이 가족 라벨을 토폴로지로 읽지 말아야 할 또 하나의 이유입니다. 유용한 피어는 권한과 성능 양쪽에 달려 있으며, 이 두 차원은 서로 다른 방향을 가리킬 수 있습니다.

HIT는 포괄적인 신뢰 진술이 아니었다

ICP의 제한된 의미가 가장 중요해지는 것은, 응답이 무엇을 확립하지 않았는지를 생각할 때입니다.

HIT는 응답 캐시가 관련 프로토콜 조건 아래 객체가 존재한다고 주장했다는 것을 나타냈습니다. 그 캐시가 인증된 신원이라는 증명이 아니었습니다. 객체가 안전하다는 것을 확립하지 않았습니다. 응답이 모든 신선도 요건을 충족할 것이라고 확립하지 않았습니다. 전송이 완료되겠다고 약속하지 않았습니다. 상호 정책, 여분의 미래 용량, 가장 저렴한 경로 또는 유리한 사업 결과를 확립하지 않았습니다.

이것들은 별개의 질문들입니다.

RFC 2187은 또한 잘못된 정보가 선택 과정을 왜곡할 수 있는 구체적인 방식을 밝혔습니다. 위조된 응답은 이웃의 선택을 강제하거나 막을 수 있었습니다. 조작된 RTT 정보도 마찬가지로 선택을 왜곡할 수 있었습니다. 거짓 HIT는 그 출처가 형제라고 여겨질 때 특히 곤란했습니다. 요청자는 객체가 존재한다는 가정 아래 HTTP 요청을 그곳으로 보낼 수 있고, 형제는 자신의 정책이 트랜짓을 올바르게 금지하기 때문에 그 결과 나오는 미스를 거부할 수 있었기 때문입니다.

그 실패에서 형제 역할도, 미스 거부 정책도 모순이 아닙니다. 실패는 부정확한 선택 신호를 자원 상태의 보장처럼 취급하는 데 있습니다.

프로토콜 의미론과 응용 정책은 구분된 채로 있었다

인터넷 웹 복제 및 캐싱 용어를 설명한 이후의RFC 3040은 ICP의 의미론을 응용 정책과 구분할 필요를 재확인합니다. 와이어 수준의 표시는 운영자가 전달, 인가 또는 폴백을 어떻게 구성해야 하는지에 대한 완전한 진술이 아닙니다.

RFC 2187은 이미 그 구분을 운영적으로 구현하고 있었습니다. 관리자가 어떤 이웃이 부모이고 어떤 이웃이 형제인지, 어떤 요청 클래스가 그들을 사용하는지, 부모가 어떤 도메인을 서비스할 수 있는지, 어떤 접근 제어가 적용되는지, 얼마나 기다릴지, 멀티캐스트가 유용한지, 방화벽이 통신에 어떤 영향을 미치는지, 선호하는 결정 경로가 실패하면 무슨 일이 일어나는지를 결정했습니다.

프로토콜은 그 결정 시스템 안에서 근거를 제공했습니다.

이것이RFC 9211이 서로 다른 근거 단계에 속하는 이유이기도 합니다. 이 문서의 전달 관측 가능성 메커니즘은 전달 이후 또는 전달 중 캐시 처리에 관한 정보를 다룹니다. RFC 2187의 문제는 요청이 캐시 계층 구조를 어떻게 이동해야 하는지 선택하는 것이었습니다. 한 단계에서 만들어진 근거는 다른 단계에 대한 증명으로 승격되어서는 안 됩니다.

이 구분은 역사적 메커니즘이 실제로 확립한 것 이상으로 늘어나는 것을 막아 줍니다. RFC 2187은 오늘날 CDN 경제에 대한 주장을 지지하지 않으며, 일반적인 HTTP 캐시 제어 규칙을 특정 계층 관계의 증거로 바꾸지도 않습니다. 더 정확한 기여는 더 좁습니다. 분산 캐시 시스템이 구성된 권한과 가벼운 네트워크 근거를 결합하면서 두 개념을 분리된 채로 유지할 수 있었음을 보여준다는 것입니다.

바로 이 좁음이 이 문서를 유용하게 만듭니다.

부모/형제 언어는 요청을 캐시에서 답할 수 없을 때 이웃이 무엇을 할 수 있도록 허용되었는지를 설명했습니다. ICP는 객체가 어디에 있을 수 있는지, 어떤 구현에서는 어떤 적격 출처가 더 바람직해 보이는지 추정하는 데 도움을 주었습니다. 어느 층도 다른 층을 대체하지 않았습니다. 정책이 유효한 선택을 결정했고, 프로토콜 신호가 그 안에서 판별을 도왔으며, 이후의 HTTP 동작이 선택된 경로가 실제로 요청자가 필요한 것을 전달했는지 결정했습니다.

따라서 계층 구조는 발견되기를 기다리는 지도가 아니었습니다. 구성하고, 강제하고, 해석해야 하는 운영 배열이었습니다.