캐싱에 리버스 프록시를 사용하는 전자 상거래 플랫폼 용 캐싱 시스템을 개발 중입니다. 적절한 HTTP / 1.1 헤더를 사용하여 무효화를 처리 할 계획입니다. 즉, 1 세대 컨텐츠에 ETag를 설정하고 해당 ETag 값을 애플리케이션에 캐시합니다. Cache-Control 헤더는 “must-revalidate”를 지정하므로 프록시는 ETag를 사용한 후속 요청에서 If-None-Match 헤더를 설정해야합니다. 응용 프로그램은 캐시 된 ETag 값을 조회하고 일치하면 304 응답을 보내며, 그렇지 않으면 전체 200 응답을 생성합니다.
나는 nginx를 사용하기를 희망했지만 그것이 ETag를 지원한다는 것을 확신 할 수 없다 (문서는 그것이 그렇지 않다는 것을 나타낼 수있다?). 바니시는 또 다른 옵션이지만 여기에서도 긍정적이지 않습니다.
ETag를 완벽하게 지원하는 리버스 프록시 서버는 무엇입니까? 실제로 여러 버전을 캐시하여 캐시를 비활성화하지 않고도 분할 테스트와 같은 작업을 수행하고 싶습니다. 즉, HTTP / 1.1은 클라이언트가 여러 ETag 값으로 If-None-Match를 보낼 수 있으며 서버는 어떤 ETag가 일치하는지 (있는 경우) 응답해야합니다. 리버스 프록시가 마지막으로 본 값이 아닌 여러 사본을 보관하고 서버가 사용할 각 요청에 대해 서버에 지정하게하는 것이 이상적입니다.
답변
방금 Varnish 소스 코드를 체크인했지만 지원 If-Modified-Since하고 If-None-Match헤더를 지원하지만 must-revalidate에서 지원하지 않습니다 Cache-Control. 에서 지원되는 유일한 속성 Cache-Control은 max-age및 s-max-age입니다.
참고 문헌 :
bin/varnishd/cache/cache_rfc2616.c에 RFC2616_Do_Cond ()bin/varnishd/cache/cache_rfc2616.c에 RFC2616_Ttl ()include/tbl/http_headers.h
답변
답변
내가 틀렸다면 저를 고치십시오. 그리고 이것은 오래된 게시물이라는 것을 알고 있습니다. 그러나 나는 새로운 행인들에게 논평하고 싶습니다. 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 다시) 최고입니다.
답변
필요한 것으로 보이는 Apache TrafficServer를 볼 수 있습니다 .
답변
지금 까지이 HTTP 사양을 완벽하게 지원하는 프록시는 아직 없다고 생각합니다. 약 1 년 전에 Node.js와 MongoDb를 사용하여 직접 작성하기로했습니다.