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
캐싱이 작동하는 것 같습니다. 이것이 캐싱에 효과적이라면 Expires 및 Cache-Control : max-age 의 요점은 무엇입니까 ? 혼란을 더하기 위해 https://developers.google.com/speed/pagespeed/insights/ 에서 페이지를 테스트하면 “브라우저 캐싱 활용”이라는 메시지가 표시됩니다.
답변
웹 서버에 헤더가 포함되어 있지 않더라도 캐싱이 작동하는 이유에 대한 질문에 대답하려면 다음을 수행하십시오.
- 만료 :
[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 란 무엇입니까?
ETag 는 Last-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 이 더 우수 합니다 . 그것은 단지 입니다
답변
Cache-Control: private
응답 메시지의 전체 또는 일부가 단일 사용자를위한 것이며 프록시 서버와 같은 공유 캐시에 의해 캐시되어서는 안됨을 나타냅니다.
답변
RFC 2616, 섹션 14.9.1 :
응답 메시지의 전부 또는 일부가 단일 사용자를위한 것이며 공유 캐시에 의해 캐시되어서는 안됨을 나타냅니다.
브라우저는이 정보를 사용할 수 있습니다. 물론 현재 “사용자”는 OS 사용자, 브라우저 사용자 (예 : Chrome의 프로필) 등 여러 가지를 의미 할 수 있습니다. 지정되지 않았습니다.
나를 위해, 좀 더 구체적인 예 의는 Cache-Control: private
프록시 서버 (일반적으로 많은 사용자를 가지고있는)를 캐시하지 것입니다. 최종 사용자를위한 것이며 다른 사람은 없습니다.
참고로, RFC는 이것이 보안을 제공하지 않음을 분명히합니다. 내용을 보호하는 것이 아니라 올바른 내용을 보여주는 것입니다.
개인용이라는 단어의 사용은 응답이 캐시 될 수있는 위치 만 제어하며 메시지 컨텐츠의 개인 정보를 보호 할 수 없습니다.
답변
Expires entity-header 필드는 응답이 오래된 것으로 간주 된 날짜 / 시간을 제공합니다.
위의 헤더 필드는 클라이언트에게 서버로 요청을 보낼지 여부를 결정하는 메커니즘을 제공합니다. 어떤 조건에서 클라이언트는 서버에 요청을 보내고 응답의 연령 값이 maxage 값보다 큰 경우 서버가 리소스를 클라이언트에 보내야합니까? 어쩌면 자원이 바뀌지 않았을 것입니다.
이 문제를 해결하기 위해 HTTP1.1은 마지막으로 수정 된 헤드를 제공합니다. 서버는 클라이언트에게 응답의 마지막 수정 날짜를 제공합니다. 클라이언트가이 리소스를 필요로하는 경우 If-Modified-Since 헤드 필드를 서버로 보냅니다. 이 날짜가 resouce의 수정 된 날짜 이전 인 경우 서버는 리소스를 클라이언트에 보내고 200 개의 코드를 제공합니다. 그렇지 않으면 클라이언트에 304 개의 코드를 반환하므로 클라이언트는 캐시 된 리소스를 사용할 수 있습니다.