내가 틀렸다면 저를 고치십시오. 그리고 이것은 오래된 게시물이라는 것을 알고 있습니다. 그러나 나는 새로운 행인들에게 논평하고 싶습니다. ETag를 사용할 때 리버스 프록시 캐시가 원하는만큼 도움이되지 않는다고 생각합니다.
유효성 검사 캐싱 메커니즘은 원본 서버를 사용하여 요청의 ETag (또는 마지막 수정 날짜)가 여전히 유효한지 (사용 된 헤더에 따라 또는 리소스 etag와 일치하거나 일치하지 않는지) 헤더의 유효성을 검사합니다. 요청에 제공된 날짜 이후).
이는 Varnish와 같은 리버스 프록시 캐시가 여전히 해당 요청을 원래 서버로 전달 함을 의미합니다. 서버가 요청을 처리하지 않고 요청으로 응답 할 수 있지만, 원 서버로의 왕복을 저장하지 않았습니다.
브라우저는 어떤 경우에도 응답을 캐시하고 304 응답을 처리 할 수 있으므로 사용자의 개인 캐시는 리버스 프록시 (YMMV, 특히 규모 및 사용 사례에 따라)를 사용하는 것보다이를 처리하는 것이 더 적합 할 수 있습니다. 앱에 대한 가정을 만들고 싶습니다).
사양 13.3에서 :
캐시에 클라이언트 요청에 대한 응답으로 사용하려는 오래된 항목이 있으면 먼저 캐시 된 항목을 계속 사용할 수 있는지 확인하기 위해 원래 서버 (또는 새로운 응답이있는 중간 캐시)를 확인해야합니다. . 이것을 캐시 항목을 "유효성 검사"라고합니다. 캐시 된 항목이 양호하면 전체 응답을 다시 전송하는 오버 헤드를 지불하지 않아도되고 캐시 된 항목이 유효하지 않은 경우 추가 왕복의 오버 헤드를 지불하지 않기 위해 HTTP / 1.1 프로토콜이 지원합니다. 조건부 방법의 사용.
그런 다음 13.3.4 참고 :
캐시 수정 자로 Last-Modified 날짜와 하나 이상의 엔티티 태그를 모두 포함하는 조건부 요청을 수신 한 HTTP / 1.1 캐싱 프록시는 캐시 된 응답이 모든 캐시와 일치하지 않는 한 클라이언트에 로컬로 캐시 된 응답을 반환해서는 안됩니다 (MUST NOT). 요청의 조건부 헤더 필드
따라서 Varnish는 응답을 반환 할 수 있지만 여전히 서버 왕복이 있습니다. APC 또는 memcache와 같은 앱 캐시를 사용할 수 있다면 여전히 가치가 있습니다. 그러나 유효성 검사 캐싱은 일반적으로 서버 리소스 절약보다 대역폭 절약에 더 좋습니다.
유효성 검사 캐싱은 클라이언트 (브라우저 또는 API 코드)에게 맡기는 것이 가장 좋습니다.
캐싱에 만료 모델을 사용하면 리버스 프록시 캐시가 실제로 빛납니다. 이를 통해 오리진 서버에 대한 적중을 건너 뛸 수 있습니다. 사용하여 Expires, Cache-Control, Date, 등, 지금까지 원본 서버를 타격하지 않고, 그 오래된없는 가정, 응답을 반환 할 수 있습니다 캐시와 같은 리버스 프록시 캐시 메커니즘 (IMO 다시) 최고입니다.