Cache-Control : private이란 무엇입니까?


148

chesseng.herokuapp.com을 방문하면 다음과 같은 응답 헤더가 나타납니다.

Cache-Control:private
Connection:keep-alive
Content-Encoding:gzip
Content-Type:text/css
Date:Tue, 16 Oct 2012 06:37:53 GMT
Last-Modified:Tue, 16 Oct 2012 03:13:38 GMT
Status:200 OK
transfer-encoding:chunked
Vary:Accept-Encoding
X-Rack-Cache:miss

그런 다음 페이지를 새로 고치고

Cache-Control:private
Connection:keep-alive
Date:Tue, 16 Oct 2012 06:20:49 GMT
Status:304 Not Modified
X-Rack-Cache:miss

캐싱이 작동하는 것 같습니다. 이것이 캐싱에 효과적이라면 ExpiresCache-Control : max-age 의 요점은 무엇입니까 ? 혼란을 더하기 위해 https://developers.google.com/speed/pagespeed/insights/ 에서 페이지를 테스트하면 "브라우저 캐싱 활용"이라는 메시지가 표시됩니다.


이 다이어그램을 확인하십시오 stackoverflow.com/a/49925190/3748498
pravdomil

답변:


74

웹 서버에 헤더가 포함되어 있지 않더라도 캐싱이 작동하는 이유에 대한 질문에 대답하려면 다음을 수행하십시오.

  • 만료 : [a date]
  • 캐시 제어 : max-age =[seconds]

서버는 중간 프록시에게 내용을 캐시하지 않도록 친절하게 요청했습니다 (즉, 항목은 개인 캐시 에만 캐시해야합니다 (예 : 자신의 로컬 컴퓨터에만)).

  • 캐시 제어 : 개인

그러나 서버는 모든 종류의 캐싱 힌트를 포함하는 것을 잊었습니다.

  • 그들은 Expires 를 포함하는 것을 잊었 으므로 브라우저는 그 날짜까지 캐시 된 사본을 사용하는 것을 알고 있습니다.
  • 그들은 Max-Age 를 포함하는 것을 잊었 으므로 브라우저는 캐시 된 항목이 얼마나 오래 지속되는지 알고 있습니다.
  • 브라우저가 조건부 요청을 수행 할 수 있도록 E-Tag 를 포함하는 것을 잊었습니다.

그러나 응답에 Last-Modified 날짜 가 포함 되었습니다.

Last-Modified: Tue, 16 Oct 2012 03:13:38 GMT

브라우저는 파일이 수정 된 날짜를 알고 있기 때문에 조건부 요청을 수행 할 수 있습니다 . 서버에 파일을 요청하지만 2012/10/16 3:13:38 이후 파일이 수정 된 경우에만 파일을 보내도록 서버에 지시합니다.

GET / HTTP/1.1
If-Modified-Since: Tue, 16 Oct 2012 03:13:38 GMT

서버는 요청을 받고 클라이언트가 최신 버전을 이미 가지고 있음을 인식합니다. 클라이언트를 보내고 200 OK페이지의 내용을 보내는 대신 캐시 된 버전이 양호 함을 알려줍니다.

304 Not Modified

브라우저는 서버에 요청을 보내는 데 시간이 걸리고 응답을 기다리는 데 어려움을 겪었지만 정적 콘텐츠를 다시 다운로드해야하는 비용을 절감했습니다.

최대 연령 ? 왜 만료 됩니까?

때문에 마지막으로 수정 안됐다.

서버의 모든 날짜와 관련된 날짜 있는 것은 아닙니다 . 나는 즉시 페이지를 짓고 있어요 경우, 그것과 관련된 일이 없다 - 그것의 지금 . 그러나 사용자가 15 초 동안 홈페이지를 캐시하도록 완벽하게 기꺼이합니다.

200 OK
Cache-Control: max-age=15

사용자가 망치면 F515 초 동안 캐시 된 버전을 계속 얻습니다. 회사 프록시 인 경우 동일한 15 초 동안 동일한 페이지를 방문하는 모든 67198 명의 사용자는 모두 동일한 내용을 얻습니다. 모두 캐시에서 제공됩니다. 모두를위한 성능 승리.

추가의 미덕은 Cache-Control: max-age브라우저가 조건부 요청 을 수행 할 필요가 없다는 것 입니다.

  • 지정한 경우에만 Last-Modified브라우저가 요청을 수행 If-Modified-Since하고 304 Not Modified응답을 감시해야합니다.
  • 을 지정 max-age하면 브라우저가 네트워크 왕복을 겪을 필요조차 없습니다. 내용은 캐시에서 바로 나옵니다.

"Cache-Control : max-age"와 "Expires"의 차이점

Expires현대 (c. 1998) Cache-Control: max-age헤더 와 동등한 유산입니다 .

  • Expires: 당신은 날짜를 지정합니다 (요)
  • max-age: 초를 지정합니다 (양호)
  • 그리고 둘 다 지정되면 브라우저는 다음을 사용합니다 max-age.

    200 OK
    Cache-Control: max-age=60
    Expires: 20180403T192837 
    

1998 년 이후에 작성된 웹 사이트는 Expires더 이상 사용 하지 말고 대신 사용하십시오 max-age.

ETag 란 무엇입니까?

ETagLast-Modified 와 비슷하지만 날짜 일 필요는 없습니다. 단지 무언가 일뿐 입니다.

데이터베이스에서 제품 목록을 가져 오는 경우 서버는 rowversion날짜가 아닌 ETag로 마지막 을 보낼 수 있습니다 .

200 OK
ETag: "247986"

내 ETag는 정적 리소스 (예 : 이미지, js, css, 글꼴) 또는 캐시 된 렌더링 된 페이지의 SHA1 해시 일 수 있습니다.

200 OK
ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4"

Last-Modified 기반의 조건부 요청의 경우와 정확히 같습니다 .

GET / HTTP/1.1
If-Modified-Since: Tue, 16 Oct 2012 03:13:38 GMT

304 Not Modified

ETag를 기반으로 조건부 요청을 수행 할 수 있습니다 .

GET / HTTP/1.1
If-None-Match: "33a64df551425fcc55e4d42a148795d9f25f89d4"

304 Not Modified

파일 이외의 것 또는 날짜 개념이있는 것에서 작동 ETag하기 Last-Modified때문에 An 이 더 우수 합니다 . 그것은 단지 입니다


1
대박! 이 답변에 현상금을 지급했습니다. cache-control존재하지 않으면 어떻게됩니까 ? 그리고 Etag 만 있습니까? 여전히 서버에 대해 '조건부 요청'을 할 필요가 없습니까? 오프라인 상태 일 때보고있는 동작은 캐시에서 돌아 오는 것입니다. 그러나 오프라인 상태에서는 조건부 요청을 할 수 없습니다. 오프라인 상태를 유지하면 무기한 캐시 될 것입니까? 나는 이미이 질문을 여기 에서 자세히 물었다 . 당신은 볼 수 있습니까?
Honey

167
Cache-Control: private

응답 메시지의 전체 또는 일부가 단일 사용자를위한 것이며 프록시 서버와 같은 공유 캐시에 의해 캐시되어서는 안됨을 나타냅니다.

에서 RFC2616 섹션 14.9.1


14
브라우저에서 캐시했기 때문입니다. 응답하려는 단일 사용자입니다.
Dan D.

13
아닙니다. Cache-Control:private공유 캐시 (예 : 프록시 캐시)가 응답을 캐시해서는 안된다고 설명하기 때문이 아닙니다.
Dan D.

5
@Trejkaz 아니요, 실제로는 단일 사용자를 의미합니다. 사용자는 캐시가 상주하는 자체 홈 디렉토리가있는 계정입니다. 동일한 사용자가 소유 한 프로파일은 캐시를 공유 할 수 있습니다. 당신이 발견 한대로. 그러나 다른 사용자가 소유 한 동일한 컴퓨터의 두 프로파일은 캐시가 공유 캐시로 처리되지 않는 한 캐시를 공유해서는 안됩니다.
Dan D.

2
아, 그래서 그것은 사용자 수준에서 OS 수준입니다. 예, 궁금한 이유는 Chrome의 시크릿 창과 시크릿이 아닌 창 사이의 명백한 정보 유출로 인해 캐시를 사용하여 정보 유출이 발생하기 때문입니다.
Trejkaz

2
@didibus proxy-revalidate는 프록시가 항상 액세스 할 때마다 항상 재확인 되도록 요구합니다. private프록시가 캐싱 되는 것을 방지합니다.
Dan D.

20

RFC 2616, 섹션 14.9.1 :

응답 메시지의 전부 또는 일부가 단일 사용자를위한 것이며 공유 캐시에 의해 캐시되어서는 안됨을 나타냅니다.


브라우저는이 정보를 사용할 수 있습니다. 물론 현재 "사용자"는 OS 사용자, 브라우저 사용자 (예 : Chrome의 프로필) 등 여러 가지를 의미 할 수 있습니다. 지정되지 않았습니다.

나를 위해, 좀 더 구체적인 예 의는 Cache-Control: private프록시 서버 (일반적으로 많은 사용자를 가지고있는)를 캐시하지 것입니다. 최종 사용자를위한 것이며 다른 사람은 없습니다.


참고로, RFC는 이것이 보안을 제공하지 않음을 분명히합니다. 내용을 보호하는 것이 아니라 올바른 내용을 보여주는 것입니다.

개인용이라는 단어의 사용은 응답이 캐시 될 수있는 위치 만 제어하며 메시지 컨텐츠의 개인 정보를 보호 할 수 없습니다.


5
비공개 (비공유) 캐시는 응답을 캐시 할 수 있습니다. 이 부분이 핵심입니다. 감사.
Oliver

0

Expires entity-header 필드는 응답이 오래된 것으로 간주 된 날짜 / 시간을 제공합니다.

위의 헤더 필드는 클라이언트에게 서버로 요청을 보낼지 여부를 결정하는 메커니즘을 제공합니다. 어떤 조건에서 클라이언트는 서버에 요청을 보내고 응답의 연령 값이 maxage 값보다 큰 경우 서버가 리소스를 클라이언트에 보내야합니까? 어쩌면 자원이 바뀌지 않았을 것입니다.

이 문제를 해결하기 위해 HTTP1.1은 마지막으로 수정 된 헤드를 제공합니다. 서버는 클라이언트에게 응답의 마지막 수정 날짜를 제공합니다. 클라이언트가이 리소스를 필요로하는 경우 If-Modified-Since 헤드 필드를 서버로 보냅니다. 이 날짜가 resouce의 수정 된 날짜 이전 인 경우 서버는 리소스를 클라이언트에 보내고 200 개의 코드를 제공합니다. 그렇지 않으면 클라이언트에 304 개의 코드를 반환하므로 클라이언트는 캐시 된 리소스를 사용할 수 있습니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.