웹 브라우저의 캐시
•
운영체제에서의 캐시(Cache)는 주기억 장치에서 자주 사용되는 데이터를 임시 저장소에 저장해두고 빠르게 액세스하여 사용하는 기술이다.
•
임시 저장소에 저장해두고 빠르게 액세스하여 처리 속도를 높인다는 캐시 개념을 인터넷에 적용하여, HTTP에서 제공하는 Cache-Control 헤더를 사용하여 서버의 부하와 네트워크 트래픽을 줄일 수 있다.
HTTP 캐시 제어
•
Cache-Contorl 헤더
◦
캐시의 생명 주기를 명시하는 응답 헤더
◦
max-age : 캐시 유효 시간(초 단위)
◦
no-cache : 데이터는 캐싱해도 되지만, 항상 Origin 서버에 검증 후 사용
◦
no-store : 데이터에 민감한 정보가 포함되어 있어 저장하지 말고 사용 후 빠르게 삭제
◦
public : public 캐시(프록시 캐시 서버)에 저장 가능
◦
private : public 캐시에 저장 불가
◦
s-maxage : 프록시 캐시 서버에서의 유효 시간(초 단위)
◦
Age : Origin 서버의 응답이 프록시 캐시 서버에 머문 시간(초 단위)
◦
must-revalidate : 캐시 만료 후 최초 조회 시 Origin 서버에 검증 필요
•
Expires 헤더
◦
캐시 만료일을 정확한 날짜로 지정하는 헤더로, 현재는 Cache-Control: max-age가 더 권장되어 잘 사용되지 않는다.
◦
Cache-Control: max-age와 함께 사용되면 Expires는 무시된다.
•
Last-Modified 헤더
◦
데이터의 최종 수정 시각을 명시하며 If-Modified-Since 요청 헤더와 함께 사용된다.
◦
클라이언트가 캐시 유효 시간이 초과된 데이터를 요청할 필요가 있는 경우, 캐시에 저장되어 있는 Last-Modified 헤더의 시각을 기준으로 If-Modified-Since 헤더를 보내 데이터 변경 여부를 확인한다.
◦
데이터가 변경되지 않았다면 서버에서 304 Not Modified에 바디 없이 헤더 메타 정보만 담아 응답을 보낸다.
◦
데이터가 변경되었다면 200 OK로 새로운 데이터를 바디에 담아 응답을 보낸다.
•
ETag 헤더
◦
데이터 버전의 이름이나 해시값과 같은 문자열을 통해, 리소스의 버전을 식별하는 고유 식별자이다.
◦
서버에서 파일이 변경될 때마다 ETag 값을 새로 생성하고 이전 ETag 값을 보관한다. 클라이언트에서 보낸 ETag 값이 다르다면 데이터를 새로 보내고 아니라면 그대로 유지하도록 한다.
◦
데이터 변경 없이 수정 날짜만 바뀌어도 클라이언트에서 요청 시에 데이터를 다시 보내는 Last-Modified 헤더의 한계를 극복하기 위한 리소스 검증 헤더이다. 주석 변경이나 파일 변경 후 롤백과 같은 경우에 새로 데이터를 보내지 않으며 베타 테스트 중 ETag 업데이트를 하지 않고 배포 시에 업데이트하는 상황에서 사용된다.
◦
If-None-Match 요청 헤더와 함께 사용된다.
no-cache vs must-revalidate
•
아래 그림과 같이 원서버와 프록시 캐시 서버가 존재하는 경우에서 원서버와 프록시 캐시 서버 간의 연결이 끊기는 상황을 가정해보자.
•
no-cache의 경우에는 프록시 서버의 정책에 따라 이미 저장되어있던 오래된 캐시 데이터를 반환하거나 캐시 데이터가 없다고 응답할 수있다.
•
must-revalidate의 경우에는 원서버의 검증을 꼭 해야하기 때문에 클라이언트에 504 Gateway Timeout을 보내게 된다.
