HTTP 캐시

HTTP 캐시

반복된 요청에 대해서 리소스를 다시 다운로드 받지 않도록 브라우저 스토리지에 저장된 데이터를 사용하도록 하는 기법

캐시를 저장하는 시간안에 다시 같은 요청이 올 시 저장된 데이터를 사용함

데이터 사용량을 줄이고 데이터 전송 속도를 높일 수 있음

캐시 시간이 초과되면 다시 데이터를 보내주고 캐시 유효시간이 갱신되고 다시 캐시시간이 조회된다.

캐시를 갱신하는 기준이 필요함

 

검증 헤더와 조건부 요청

캐시가 시간초과과 되었을 시라도 데이터가 변경되지 않을 수 있음

클라이언트와 서버의 데이터가 일치한다는 사실을 확인 할 수 있는 방법이 필요함

1) Last Modifed

1. 클라이언트의 리소스 요청에 따라 서버측에서 Last Modified : UTC (20201112010101) 이라고 보냄

2. 클라이언트가 60(캐시 유효시간)초 후에 다시 요청함, 이 때 가지고 있는 리소스의 Last Modfied를 요청헤더에 같이 보냄

3. 서버에서 리소스가 변경되지 않았다는 내용을 확인하고 304 not modifed 에 HTTP BODY가 없는 메세지를 전달함

4. 적은량의 데이터만 전송하며 클라이언트는 서버의 응답(304 not modifed)을 보고 저장되어 있는 캐시를 사용함

단점

1. 1초 미만 단위로 캐시 조정 불가능 

2. 날짜 기반의 로직 사용 (A -> B -> A와 같이 실질적으로 변경은 없는 경우)

 

2) ETAG

캐시 데이터에 임의의 고유한 번호를 달아둠 ("data v1")

ETAG만 확인하고 다르면 다시 보내고 같으면 유지

캐시에 관련된 로직은 서버에서 완전히 관리

 

If-match, if-none-match : ETAG 값 사용

If-modifed-Since, If-None-modifed-Since : LastModified 사용

 

캐시 제어 헤더

1. Cache-Control : max-age : 유효시간

2. Cache-Control : no-Cache : 데이터는 캐시해도 되지만 항상 원(캐시 프록시서버를 거쳐서 진짜 어플리케이션 서비스) 서버에서 검증하고 사용

3. Cashe-Control : no-store : 캐시 하지 않는다.

4. Expires : 캐시 만료일을 직접 지정해둠

5. Cache Control : must-revalidate : no cache 상황에서 프록시 서버가 orgin으로 가능상황에서 장애가 발생하여 그냥 프록시 서버의 캐시로 응답하는 상황이 발생할 수 있다. 이럴때 프록시서버의 데이터를 보낼 수도 있지만 must-revalidate를 명시하면 504 timeout을 보내게 된다.

6. Pragma: no-cache : Http 1.0 에서 위의 캐시 무효화 제어 헤더을 모르기 때문에 이전 버전 캐시 무효화를 위한 헤더

 

 

프록시 서버

Origin 서버에 접근하기까지 중간단계에 데이터를 저장하는 서버

중간에 저장하기 떄문에 물리적으로 가까운 거리의 데이터를 받아 성능을 높일 수 있다.

브라우저에 저장되는 캐시를 Private 캐시 ,프록시에 저장되는 캐시를 Public 캐시

 

Cache Control

Cache Control: public : 캐시를 공용 프록시 서버에서 저장

Cache Control : private : 캐시를 브라우져 스토리지에 저장 ,기본값