HTTP 304 오류에 대한 자세한 설명_기본지식

수정되지 않음 클라이언트가 문서를 버퍼링하고 조건부 요청을 발행했습니다. 일반적으로 클라이언트가 지정된 날짜보다 최신 문서만 원한다는 것을 나타내기 위해 If-Modified-Since 헤더를 제공합니다. 서버는 클라이언트에게 원래 버퍼링된 문서를 계속 사용할 수 있음을 알려줍니다.

클라이언트가 파일을 요청할 때 캐시된 파일에 마지막 수정 날짜가 있음을 발견하면 요청에는 If Modified Since 가 포함되며 이 시간은 캐시된 파일의 마지막 수정 날짜입니다. 따라서 요청에 If Modified Since가 포함되어 있으면 클라이언트에 이미 캐시되어 있음을 의미합니다. 이번 시간과 현재 요청된 파일의 수정 시간을 판단하여 304를 반환할지 200을 반환할지 결정하세요. CSS 및 이미지와 같은 정적 파일의 경우 서버는 자동으로 마지막 수정 날짜와 이후 수정 날짜를 비교하여 캐싱 또는 업데이트를 완료합니다. 그러나 동적으로 생성된 페이지인 동적 페이지의 경우 마지막 수정 정보가 포함되지 않는 경우가 많으므로 브라우저, 게이트웨이 등은 이를 캐시하지 않습니다. 즉, 요청될 때마다 200 요청이 완료됩니다.

따라서 동적 페이지의 캐싱 가속을 위해서는 먼저 응답의 HTTP 헤더에 마지막 수정 정의를 추가한 다음 요청의 If Modified Since와 요청된 업데이트 시간에 따라 200 또는 304를 반환해야 합니다. 콘텐츠. 304를 반환할 때 데이터베이스 쿼리가 이루어졌지만 후속 데이터베이스 쿼리를 피할 수 있으며 페이지 콘텐츠는 반환되지 않고 HTTP 헤더만 반환되므로 대역폭 소비가 크게 줄어들고 사용자 경험이 향상됩니다.

이러한 캐시가 유효한 경우 HttpWatch를 통해 요청을 보면 다음과 같은 결과가 나타납니다.

첫방문 200

마우스 클릭으로 2차 접속(캐시)

304를 새로 고치려면 F5를 누르세요

Ctrl F5를 눌러 200을 강제로 새로 고치세요

이런 경우에는 캐시가 정말 효과적이라는 뜻입니다. 위 내용은 HTTP 304에 대한 나의 이해입니다.