사이트의 index.html에 현재 다음 헤더가있는 클라이언트가 있습니다.
수락 범위 : 바이트 연결 : 연결 유지 콘텐츠 인코딩 : gzip 내용 길이 : 3658 콘텐츠 유형 : text / html 날짜 : 2013 년 10 월 10 일 목요일 07:36:27 GMT ETag : "4aa95e1-2ed2-4e721324728b7" 연결 유지 : 시간 초과 = 5, 최대 = 100 최종 수정 : 2013 년 9 월 24 일 화요일 GMT 13:34:30 서버 : Apache / 2.2.22 다름 : 수락 인코딩, 사용자 에이전트
분명히 추가 Expires하거나 Cache-Control적절하게 권장 할 것이지만 혼란 스럽습니다 .Chrome 은이 리소스를 캐시하고 몇 시간이 지난 후에도 ( 요청 을 전혀 보내지 않고) 캐시에서 사용합니다 (예 : 사본 재사용) 어제 오전 1시 30 분에 오전 8시 30 분에 캐시되었습니다.) 나는 그것이 요청을 보여주고있는 크롬 콘솔의 네트워크 탭에 아주 명확하게 볼 수 있습니다 200 (OK)회색의 상태 열과 (from cache)의 크기 열입니다. (Chrome의 캐싱 기본값을 변경하지 않았습니다.)
이 사양을 통해 사용자 에이전트 는 헤더의 지시가없는 자체 결정을 내릴 수 있습니다. 그게 무슨 일이야? Chrome은 며칠 전에 마지막으로 수정 된 것을 확인하고 최신 버전 (예 : 최신 버전)을 자유롭게 사용하고 있습니까? 아니면 내가 놓친 것이 있습니까?
답변
“Expires”및 “Cache-Control”헤더가 지정되어 있지 않지만 “Last-Modified”헤더 가 지정되면 브라우저는 문서를 캐시에 보관해야하는 시간을 추측해야합니다. 일부 브라우저 는 페이지를 하루 이상 캐시에 유지할 수있는 알고리즘을 사용합니다.
Google 캐싱 모범 사례 가이드 상태 :
Last-Modified는 브라우저가 휴리스틱을 적용하여 캐시에서 항목을 가져올 지 여부를 결정한다는 점에서 “약한”캐싱 헤더입니다. 휴리스틱은 브라우저마다 다릅니다.
Mozilla (Firefox)에는 이 상황에 대한 알고리즘을 설명 하는 HTTP 캐싱 FAQ 가 있습니다 (문서 날짜가 2002 년 이후 알고리즘이 변경되었을 수 있음).
… “마지막으로 수정 된”헤더를 찾습니다. 이 헤더가 있으면 캐시의 최신 상태 수명은 “날짜”헤더 값에서 “마지막으로 수정 된”헤더 값을 10으로 나눈 값과 같습니다.
따라서 수정 된 것과 현재의 차이가 15 일인 경우 Firefox는 1.5 일 동안 리소스를 캐시합니다.
모든 주요 브라우저는 Firefox에서 구현하는 것과 동일한 10 % 규칙을 사용하는 것으로 보입니다. 문제는 이러한 추론을 요구 StackOveflow에 요청하고있다 . 다른 브라우저에 대한 다른 답변은 모두 유사한 구현을 가지고 있음을 보여줍니다. Internet Explorer 및 Webkit (Chrome 및 Safari)에 대한 답변이 있습니다.
브라우저의 캐시 크기는 캐싱 알고리즘이 하루 이상 보관할 수 있다고 결정한 파일의 제한 요소 일 것입니다. 브라우저는 일반적으로 캐시에 사용하는 디스크 공간 크기를 설정합니다. 많은 사용자는 브라우저를 닫을 때 캐시를 비 웁니다. 따라서 이러한 파일이 캐시되는 시간은 일반적으로 다음에 따라 다릅니다.
- 브라우저가 할당 한 캐시 공간
- 사용자가 방문한 웹 사이트 수 및 해당 사이트의 크기
- 사용자가 브라우저를 닫았는지 여부