HTTP
HTTP 응답 캐싱
수색…
비고
응답은 각 URL 및 각 HTTP 메소드에 대해 별도로 캐시됩니다.
HTTP 캐싱은 RFC 7234에 정의되어 있습니다.
어휘
- 신선한 - 아직 만료되지 않은 캐시 된 응답의 상태입니다. 일반적으로 새로운 응답은 응답이 시작된 서버에 연결할 필요없이 요청을 만족시킬 수 있습니다.
- 부실 - 만료 날짜를 지난 캐시 된 응답의 상태입니다. 일반적으로 오래된 반응은 여전히 유효 여부 서버와 확인하지 않고 요구를 충족하는 데 사용할 수 없습니다.
- 만족 된 캐시 된 응답은 요청의 모든 조건이 캐시 된 응답과 일치 할 때 요청을 만족시킵니다 . 예를 들어, HTTP 메서드와 URL이 같거나 응답이 신선하거나 요청이 부실 응답을 허용하거나 요청 헤더가 응답의
Vary
헤더에 나열된 헤더와 일치 할 때 . - revalidation - 캐쉬 된 응답이 새로운 것인지 여부를 확인합니다. 이것은 대개
If-Modified-Since
또는If-None-Match
및 응답 상태304
포함하는 조건부 요청 으로 수행됩니다. - 개인용 캐시 - 단일 사용자 (예 : 웹 브라우저) 용 캐시. 개인 캐시는 개인화 된 응답을 저장할 수 있습니다.
- 공용 캐시 - 많은 사용자간에 공유되는 캐시 (예 : 프록시 서버). 이러한 캐시는 여러 사용자에게 동일한 응답을 보낼 수 있습니다.
모든 사람에게 1 년 동안 캐시 응답
Cache-Control: public, max-age=31536000
public
은 응답이 모든 사용자에게 동일하다는 것을 의미합니다 (개인화 된 정보는 포함하지 않음). max-age
은 지금부터 초입니다. 31536000 = 60 * 60 * 24 * 365.
이는 결코 변경할 필요가없는 정적 자산에 권장됩니다.
1 분 동안 맞춤 응답을 캐시하십시오.
Cache-Control: private, max-age=60
private
은 응답을 자원을 요청한 사용자에 대해서만 캐시 할 수 있으며 다른 사용자가 동일한 자원을 요청할 때 다시 사용할 수 없음을 지정합니다. 이는 쿠키에 의존하는 응답에 적합합니다.
먼저 서버로 확인하지 않고 캐싱 된 자원의 사용을 중지하십시오.
Cache-Control: no-cache
클라이언트는 응답이 캐시되지 않은 것처럼 작동합니다. 이는 언제든지 예기치 않게 변경 될 수있는 리소스와 최신 버전에서 항상 볼 수 있어야하는 리소스에 적합합니다.
no-cache
를 사용하면 서버를 사용할 때마다 서버에 문의해야하므로 응답 속도가 느려집니다 (대기 시간이 길어집니다).
그러나 대역폭을 절약하기 위해 클라이언트 는 여전히 이러한 응답을 저장할 수 있습니다. no-cache
를 사용하는 응답은 캐시 된 응답을 다시 사용할 수 있는지 여부를 확인하기 위해 매번 서버에 접속하지 않고 요청을 충족시키는 데 사용되지 않습니다.
응답을 전혀 저장하지 말 것을 요청하십시오
Cache-control: no-store
클라이언트에게 어떤 식 으로든 응답을 저장하고 가능한 한 빨리 잊어 버리라고 지시합니다.
이 지시문은 원래 민감한 데이터 용으로 설계되었지만 (현재는 HTTPS를 사용해야 함) 재사용 할 수없는 응답으로 인해 캐시가 오염되는 것을 방지하는 데 사용할 수 있습니다.
응답 데이터가 항상 다른 특수한 경우, 예를 들어 큰 난수를 반환하는 API 끝점에서만 적합합니다. 그렇지 않으면 no-cache
및 revalidation을 사용하여 "uncacheable"응답의 동작을 유지하면서 일부 대역폭을 절약 할 수 있습니다.
폐기 된 중복 헤더 및 비표준 헤더
Expires
- 자원이 오래되어 버린 날짜를 지정합니다. 정확한 시계와 시간대를 올바르게 지원하는 서버와 클라이언트에 의존합니다.Cache-control: max-age
은Expires
보다 우선하며 일반적으로 더 신뢰할 수 있습니다.post-check
및pre-check
지시문은 부실 응답을 사용할 수있는 비표준 Internet Explorer 확장입니다. 표준 대안은stale-while-revalidate
입니다.Pragma: no-cache
- 1999 년에 폐기되었습니다. 대신Cache-control
사용해야합니다.
캐시 된 리소스 변경
캐시를 우회하는 가장 쉬운 방법은 URL을 변경하는 것입니다. 이것은 URL에 리소스의 버전이나 체크섬이 포함 된 경우 (예 :
http://example.com/image.png?version=1
http://example.com/image.png?version=2
이 두 URL은 별도로 캐시되므로, …?version=1
이 영원히 캐시 된 경우에도 새 복사본을 …?version=2
로 즉시 검색 할 수 있습니다.
임의의 URL을 사용하여 캐시를 우회하지 마십시오. Cache-control: no-cache
또는 Cache-control: no-store
대신 사용하십시오. 무작위 URL을 가진 응답이 no-store
지시어없이 전송되면 캐시에 불필요하게 저장되어 캐시에서 더 유용한 응답을 푸시 (push out)하여 전체 캐시 성능을 저하시킵니다.