RFC 2186는 빠른 캐시 힌트와 증명 사이에 엄격한 경계를 그렸다

요약

• ICPv2는 가벼운 캐시 이웃 힌트 프로토콜로 정의되었으며, 그 유용성은 어떤 객체를 어디서 가져올지 판단에 영향을 줄 만큼 빠르게 답변하는 데 달려 있었다.
• 응답, 요청 상관관계, 에코 결과, 선택적 RTT 측정은 각각 제한된 사실만을 증명한다. 이들만으로 인증된 신원, HTTP 신선도, 오리진 권한, 성공적인 애플리케이션 전송을 입증할 수 없다.
• 객체를 포함하는 응답은 힌트를 전송 쪽으로 확장하는 비용을 드러낸다. 이후 HTTP 요청을 피할 수 있지만, HTTP 인가와 나이 검증을 우회하며 교환을 추가적인 단편화 및 스푸핑 위험에 노출시킨다.

D. Wessels와 K. Claffy가 1997년 9월에 발행한 Informational 문서는 하나의 단순한 제약을 중심으로 ICPv2를 규정했다. 객체를 어디서 가져올지 결정하는 캐시는 더 많은 정보를 무한정 기다릴 수 없다는 것이었다. 이웃 선택 프로토콜은 질문 자체가 답변의 이득을 지워버리지 않을 만큼 저렴해야 했다.

이 제약은 프로토콜과 그 증거의 의미를 함께 형성했다. 질의와 응답은 대략 1~2초 안에 완료되어야 했다. 이웃이 침묵하면 요청자는 혼잡, 끊긴 경로, 캐시 장애 또는 다른 시스템 장애 중 무엇이 원인인지 판단할 필요 없이 조치를 취할 수 있었다. 이 서로 다른 원인들은 의도적으로 같은 즉각적인 운영 결정으로 수렴했다: 지금은 그 이웃을 선택하지 않는다.

따라서 프로토콜은 진단과 조치를 분리했다. 침묵이 유용한 이유는 통신 실패의 원인을 밝혀주기 때문이 아니라, 확실성을 기다리지 않고 요청자가 다음으로 넘어갈 수 있게 하기 때문이었다.

패킷 구조 역시 마찬가지로 경제적이었다. 각 메시지는 고정 20옥텟 헤더와 페이로드로 구성되며, 전체 메시지는 16,384옥텟으로 제한된다. Request Number는 질의에서 응답으로 복사되고, 정확한 URL은 교환을 논의 대상인 리소스와 연결시킨다. 이 필드들은 상관관계를 가능하게 한다. 그러나 응답자를 인증하지는 않는다.

이 구분은 근본적이다. 일치하는 Request Number는 응답이 질의와 같은 불투명한 상관관계 값을 담고 있음을 보여줄 수 있다. URL은 응답이 어떤 요청된 리소스를 가리키는지 보여줄 수 있다. 어느 필드도 패킷을 보낸 사람이 누구인지, 발신자가 오리진을 대신해 말할 권한이 있는지, 객체가 신선한지, 이후 전송이 성공했는지를 증명하지 못한다.

응답 어휘 역시 마찬가지로 좁다.

HIT는 해당 URL이 응답 캐시에 존재하고 이 요청자가 그것을 가져올 수 있음을 의미한다. 그것은 그 순간의 캐시 상태와 요청자 권한에 관한 증거다. 객체가 이미 전송되었다는 뜻이 아니다. 일반적인 경로에서는 이후 HTTP 요청이 여전히 필요하다.

따라서HIT는 그 자체로 오리진 권한, HTTP 규칙에 따른 신선도, 성공적인 애플리케이션 수신, 안전한 렌더링, 미래 가용성, 또는 이 이웃이 최선의 소스라는 사실을 증명하지 않는다. 더 작은 질문에 답할 뿐이다: 이 캐시가 URL을 갖고 있다고 말하며 이 요청자의 검색을 허용하는가?

MISS는 URL이 없음을 의미한다. 그조차 이웃을 후보에서 반드시 제외하지는 않는다. 관계가 허용하는 경우 요청자는 여전히 그 피어를 통해 객체를 가져올 수 있다. 피어의 로컬 캐시에 없다는 것과 검색 참여를 거부한다는 것은 다르다.

MISS_NOFETCH는 또 다르다. 캐시는 실행 중이지만 그 시점에 미스 처리를 원하지 않는다는 뜻이다. 스토어 재구축이 한 예다. 이 신호는 애플리케이션 가용성과 특정 작업 수행 의사를 분리한다.

DENIED는 더욱 좁게 범위가 한정된다. 이 요청자, 이 URL, 이 시점에만 적용된다. 매우 높은 거부 비율은 이웃 간 설정 문제를 시사할 수 있지만, 적대적 의도를 증명하지는 않는다. 개별 응답은 거부를 보고할 뿐이며, 반복되는 패턴은 동기를 제공하지 않고 조사를 정당화할 수 있다.

주소 필드에는 자체적인 증거 한계가 있다. Sender Host Address는 전송 인터페이스를 통해 관찰된 피어 주소보다 신뢰하지 않는 것이 명시적이다. 그 목적은 모호하며 실제로는 사용되지 않았다. 신원 주장으로 격상시켜서는 안 된다.

Requester Host Address는 별개다. 질의에서 모두 0일 수 있으며, 이는 요청자 주소가 지정되지 않았음을 의미한다. 이 전부 0인 값은 요청자 주소 의미론에 속한다. 유효한 신원이 아니며, 신뢰할 수 없는 Sender Host Address와 혼동해서는 안 된다.

선택적 소스 RTT 정보 역시 범위가 제한된 힌트로 설계되었다. 응답자는 URL이 가리키는 호스트에 대해 저장된 왕복 시간 측정값을 제공할 수 있다. 값은 없거나 0일 수 있으며, 이를 얻는 것이 응답을 지연시켜서는 안 된다. 따라서 프로토콜은 결정을 늦출 새로운 측정보다 즉시 이용 가능한 기존 지식을 선호한다.

반환된 RTT는 옵션 순위를 정하는 데 도움을 줄 수 있지만, 현재의 종단 간 성능, 미래 전송 시간 또는 객체의 최선의 소스를 확립하지는 않는다. 응답자가 보고할 수 있도록 그 측정값을 저장해 두었다는 사실만을 말한다.

에코 연산도 유사한 경계를 만든다.SECHO와DECHO는 도달 가능성에 관한 정보를 제공할 수 있다. 그러나 캐시 소프트웨어 자체가 다운된 상태에서도 에코 서비스는 응답할 수 있다. 성공적인 에코는 에코 메커니즘이 작동했음을 증명할 뿐, 캐시 애플리케이션이 서빙할 준비가 되었음을 증명하지 않는다.

가장 중대한 경계는HIT_OBJ에 나타난다. 이 응답은 객체 바이트를 담을 수 있어 이후 HTTP 요청을 피할 수 있다. 그 편의성은 증거와 위험 모델을 바꾼다. 객체가 일반적인 HTTP 검색 단계를 우회하기 때문에 HTTP 인가와 나이 검증도 함께 우회된다.

이는 ICP 응답 자체가 인증되지 않는다는 사실과 별개이다. 한쪽은 객체 바이트가 캐시 힌트 교환 안에서 전송될 때 더 이상 수행되지 않는 HTTP 검사에 관한 것이고, 다른 쪽은 ICP 응답 자체가 발신자의 신원을 증명하는지에 관한 것이다. 이 둘은 별개의 한계이며 분석에서도 별개로 남아 있어야 한다.

객체를 포함하는 응답은 전송 가정에도 부담을 준다. 큰 UDP 데이터그램은 경로 MTU를 초과해 단편화될 수 있다. 그 이유로 이 기능은 권장되지 않으며, 질의에서 명시적으로 옵트인해야 한다.

선언된 객체 길이조차 스스로를 증명하지는 않는다. 지정된 객체 바이트 수가 온전히 도착하지 않으면 수신자는 응답을 일반HIT로 취급한다. 따라서 바이트 수는 실제 수신한 바이트와 대조해 확인해야 할 주장이지, 완전한 객체가 전송되었다는 증명이 아니다.

보안 결과는 이 좁은 의미론에서 직접 따라 나온다. 위조 응답은 피어 사용을 강제하거나 차단함으로써 이웃 선택을 조작할 수 있다. 설정되지 않은 이웃의 멀티캐스트 질의에 대한 응답은 무시해야 한다. 스푸핑이 객체를 포함하는 응답과 결합되면 위험은 나쁜 선택 결정에서 캐시 오염으로 격상된다. 무효한 객체 데이터가 유입될 수 있기 때문이다.

이 프로토콜의 역사적 가치는 이러한 경계들의 규율에 있다. 제시간에 도착한 UDP 응답은 응답이 제시간에 도착했다는 사실만 증명한다. 요청 번호 일치는 상관관계를 뒷받침한다. 에코 응답은 제한된 도달 가능성을 증명한다. 저장된 RTT는 응답자가 이미 갖고 있던 측정값을 보고한다.HIT는 제한된 캐시 상태와 권한을 보고한다. 옵트인된 객체 포함 응답의 완전한 객체 바이트는 그 바이트들이 그 교환에서 도착했다는 것을 증명한다.

그중 어떤 사실도, 그것만으로는 인증된 신원, 오리진 권한, HTTP 신선도, 완전한 애플리케이션 처리, 안전한 렌더링, 최선의 소스, 미래 가용성 또는 비즈니스 결과를 증명하지 못한다. 이 프로토콜이 여전히 교훈적인 이유는 모든 질문에 답했기 때문이 아니라, 하나의 좁은 질문을 다음 조치를 안내할 만큼 빠르게 답할 수 있었기 때문이다.