[네트워크] HTTP 브라우저와 웹 서버 캐시 동기화하는 방법: Last-Modified, ETag 이용

 HTTP 통신에서 캐시를 관리하기 위한 헤더와 관련 프로세스를 알아보겠습니다.

 

[ Contents ]

 

 

1. 브라우저 캐시 (Browser Cache)

클라이언트의 웹 브라우저에서 저장하는 캐시

 UI/UX는 사용하기 편하고 익숙해야하기 때문에, 웹 UI는 쉽게 변하지 않습니다. 동일한 HTML, CSS, JS, 이미지 파일을 그대로 사용한다는 뜻이죠. 이러한 데이터를 매번 요청하고 응답받는 건 네트워크 자원 낭비이기 때문에, 브라우저에서 따로 캐시로 저장합니다.

 

star가 되고나서 Tistory 메인 화면 (대부분의 리소스가 메모리 캐시에서 로드됨)

 

 

 

2. HTTP 캐시 관련 헤더

cache-control: 캐시 유효기간, 검증방법 설정

 

 웹 서버와 브라우저 캐시가 서로 다르면 안되므로, 서버에서는 브라우저 캐시를 제어하는 응답 헤더를 덧붙입니다.

 

no-store: 캐시 저장 안함
no-cache: 매번 캐시 유효성 검증 필수 (origin 서버에게 유효한 캐시인지 물어봄)
must-revalidate: 만료된 캐시만 유효성 검증
public/private: public은 중계서버(CDN) 사용가능, private는 브라우저 캐시만 가능
max-age: 캐시 유효기간 설정

 

 cache-control에서는 위와 같은 속성을 부여할 수 있습니다.

 no-store는 해당 데이터는 캐시를 저장하지 말라는 뜻으로, 주로 민감정보(주민번호, 계좌번호)를 no-store로 설정합니다.

 no-cache는 캐시를 사용하지 말라는 뜻이 아니라, 매번 서버에 캐시를 사용해도 되는지 물어보라는 설정입니다. 이때 서버는 실제 서비스를 제공하는 원 서버(Origin Server)입니다. [중계서버, CDN 등이 아님]

 

 

 

3. 캐시 동기화

1) 변경일시 이용

Last-Modified: 최근 수정된 일시

 

 유효기간이 만료된 캐시는 갱신하기 위해, 서버에게 해당 캐시를 요구합니다. 이때 데이터가 변경되지 않았으면 캐시를 그대로 쓰라고 응답을 보내고, 해당 캐시의 유효기간을 연장합니다.

 캐시 데이터 변경여부 판별에 '변경일시'가 쓰이며, 캐시 생성일시가 서버 파일의 Last-Modified보다 이르면 갱신하지 않습니다.

 

 

2) 헤시값 이용

ETag: 캐시 데이터의 헤시값 혹은 버전

 

 헤시값 혹은 버전 정보를 이용해서 캐시 갱신여부를 판별하기도 합니다.

 로컬 캐시와 서버 파일의 헤시값 혹은 버전이 같으면 갱신하지 않고 유효기간을 연장합니다.

 

 

 서버에서 캐시 갱신이 필요없을 때, 304 Not Modified 상태코드를 사용합니다. 클라이언트에서 새 데이터를 요청했지만, 필요치 않으니 데이터를 보내지 않은 경우입니다. 따라서 200 OK가 아니라 304 Not Modified로 응답합니다.

(Body는 비어있으며, 응답 헤더에는 Etag, Last-Modified 등의 캐시 유효성 검증정보를 포함합니다.)