nginx는 페이지 캐싱을 제어하는 ​​방법을 만료합니다.

구문: 만료 [time|epoch|max|pff] 기본값: offexpires 지시문은 http 응답의 "expires" 및 "cache-control" 헤더 정보를 제어하고 페이지 캐시 시간 제어 기능을 시작합니다. 양수 또는 음수. "expires" 헤더의 값은 설정된 시간 값에 현재 시스템 시간을 더하여 설정됩니다. 시간 값은 "cache-control" 값도 제어합니다. 음수는 캐시 없음을 나타내고, 양수 또는 0은 max-age=time epoch를 나타냅니다. "expires" 값을 1january,1970,00:00으로 지정합니다. :01 gmtmax: "만료"를 지정합니다. ""cache-control"의 값은 31december2037 23:59:59gmt이고, "cache-control"의 값은 10년입니다. -1: "expires" 값을 현재 서버 시간의 -1초로 지정합니다. 즉, 영원히 만료된다는 의미입니다. off: "expires" 및 "cache-control" 값을 수정하지 마세요.
expires는 특정 시간을 사용하며 서버와 클라이언트 간의 엄격한 동기화가 필요합니다.
cache-control은 max-age 지시문을 사용하여 구성 요소가 캐시되는 기간을 지정합니다.
http1.1을 지원하지 않는 브라우저의 경우 만료를 제어해야 합니다. 따라서 두 개의 응답 헤더를 지정하는 것이 가장 좋습니다. 그러나 http 사양에서는 max-age 지시문이 만료 헤더를 다시 작성하도록 규정합니다.

프록시 또는 브라우저가 캐시하는 것을 원하지 않는 경우 no-cache 매개변수 또는 개인 매개변수를 추가하세요.
#은 1d를 만료합니다.
add_header 캐시 제어 no-cache;
add_header 캐시 제어 개인;
이런 식으로 , 브라우저 f5가 새로 고쳐지면 여전히 304가 아닌 200이 반환됩니다.

nginx 제어 캐시의 예를 기록하세요.
           expires 1d;
      add_header 캐시 제어 no-cache;  만약 ( !-e $request_filename) {
다시 쓰기 ^(.*) http://test.zhaopin.com/index.html break;
# add_header 캐시 제어 no-cache;
# add_header 캐시 제어 private;
When 다시 작성한 후 add_header를 작성했는데 add_header가 작동하지 않는 것을 발견했습니다. . if에 기록되어 있기 때문입니다...


apache의 mod_expires 모듈을 사용하면 만료 헤더를 사용할 때 max-age와 같은 상대적인 방식으로 날짜를 설정할 수 있으며 이는 만료 기본값 지시어를 통해 완료됩니다. 예: 이미지의 만료 시간은 요청이 시작된 후 10년입니다

expiresdefault "access plus 10years"

응답 만료 헤더 및 캐시 제어 최대 수명 헤더 보내기와 같습니다.

expires|etag는 페이지 캐시 차이 만료를 제어합니다. 위 기사에서 언급했듯이 만료 지시문은 http 응답의 "expires" 및 "cache-control" 헤더 정보를 제어하고 페이지 캐시 시간을 제어하는 ​​기능을 시작합니다. : 올바른 숫자나 음수를 사용할 수 있습니다. "expires" 헤더의 값은 설정된 시간 값에 현재 시스템 시간을 더하여 설정됩니다. 시간 값은 "cache-control" 값도 제어합니다. 음수는 캐시 없음을 나타내고, 양수 또는 0은 max-age=time epoch를 나타냅니다. "expires" 값을 1january,1970,00:00으로 지정합니다. :01 gmtmax: "만료"를 지정합니다. "값은 31december203723:59:59gmt이고, "cache-control" 값은 10년입니다. -1: "expires" 값을 현재 서버 시간의 -1초로 지정합니다. 즉, 영원히 만료된다는 의미입니다. off: "expires" 및 "cache-control" 값을 수정하지 마십시오.

expires는 특정 시간을 사용하며 서버와 클라이언트 간의 엄격한 동기화가 필요합니다.
cache-control은 max-age 지시문을 사용하여 구성 요소가 캐시되는 기간을 지정합니다.
http1.1을 지원하지 않는 브라우저의 경우 만료를 제어해야 합니다. 따라서 두 개의 응답 헤더를 지정하는 것이 가장 좋습니다. 그러나 http 사양에서는 max-age 지시문이 만료 헤더를 다시 작성하도록 규정합니다. 일반적으로 페이지가 매우 빠르게 변경되지 않을 때 사용됩니다. 캐시가 만료되면 브라우저는 이를 재사용하기 전에 먼저 유효한지 확인합니다. 유효한 경우 304를 반환합니다. 상태 코드. 만료는 마지막으로 수정된 응답 헤더를 통해 결정됩니다. 사진과 같이:
첫 번째 방문:
요청:


반환:


두 번째 방문:
요청:


반환:


이번에 반환된 상태 코드는 304이며, 요청에 처음보다 if-modified-since 헤더가 많아지고 원래 서버의 마지막 수정 헤더와 비교하여 브라우저 캐싱이 구현되고 만료 여부가 결정됩니다.
간단히 말해서 last-modified와 if-modified-since는 모두 페이지의 마지막 수정 시간을 기록하는 데 사용되는 http 헤더 정보이지만, last-modified는 서버에서 클라이언트로 보내는 http 헤더이고 if-modified는 -since는 클라이언트가 서버로 보낸 헤더에서 로컬에 존재하는 캐시 페이지를 다시 요청하면 클라이언트가 if-modified-를 통해 이전 서버에서 보낸 마지막 수정 타임스탬프를 다시 보내는 것을 알 수 있습니다. 서버가 이 타임스탬프를 사용하여 클라이언트의 페이지가 최신인지 확인하기 위한 것입니다. 최신이 아닌 경우 새 콘텐츠가 반환됩니다. 클라이언트에게 로컬 캐시에 있는 페이지가 최신임을 알려줍니다. 그러면 클라이언트가 로컬에서 직접 페이지를 로드할 수 있으므로 네트워크에서 전송되는 데이터가 크게 줄어들고 서버의 부담도 줄어듭니다.

프록시나 브라우저가 캐시되는 것을 원하지 않는 경우 no-cache 매개변수 또는 개인 매개변수를 추가하세요.
#expires 1d;
add_header 캐시-제어 no-cache;
add_header 캐시-제어 개인;




etag: 엔터티 태그는 웹 서버 및 브라우저 캐시의 유효성을 확인하는 데 사용되는 메커니즘입니다. 원본 서버는 etag 응답 헤더를 사용하여 구성 요소의 etag를 지정하고 브라우저는 if-none-match 헤더를 통해 etag를 원본 서버로 다시 전달합니다. 일치하면 다음과 같이 304
를 반환합니다.
첫 번째 방문:
요청:


반환:


두 번째 요청:


반환:


반환된 상태 코드는 304입니다. 거기 처음보다 요청에 if-none-match 헤더가 더 많습니다. 따라서 브라우저 캐싱을 구현하십시오. 이 값이 일치하지 않으면 캐시가 만료됩니다.
etags 및 if-none-match는 리소스가 변경되었는지 확인하는 데 일반적으로 사용되는 방법입니다. last-modified 및 http-if-modified-since와 유사합니다. 그러나 차이점은 last-modified 및 http-if-modified-since는 리소스의 마지막 수정 시간만 결정하는 반면 etags 및 if-none-match는 리소스의 모든 속성이 될 수 있다는 점입니다.
etags 및 if-none-match 작업은 httpresponse에 etags 정보를 추가하여 작동합니다. 클라이언트가 리소스를 다시 요청하면 if-none-match 정보(etags 값)가 httprequest에 추가됩니다. 서버가 리소스의 etag가 변경되지 않았음을 확인하면(리소스가 변경되지 않음) 304 상태를 반환하고, 그렇지 않으면 서버는 200 상태를 반환하고 리소스와 새 etag를 반환합니다.
IIS의 etag 형식을 수정해야 합니다.

위 내용은 nginx는 페이지 캐싱을 제어하는 ​​방법을 만료합니다.의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!