HTTP 표현 헤더 - 캐시

캐시란?

웹 페이지 요소를 저장하기 위한 임시 저장소입니다. 이러한 요소들은 그림 파일이나 문서 파일 등이 될 수 있는데요.

캐시는 웹 페이지가 빠르게 렌더링 할 수 있도록 도와줍니다.

 

이 전에 포스팅한 쿠키와 다른점이 있다면,

쿠키는 보통 사용자의 인증을 도와주는 정보를 저장하기 위해 사용되는데,

기본적으로 서버에서 클라이언트로 보내는 작은 파일들을 저장합니다. 

 

쉽게 말해 쿠키는 서버에 접속할 때 서버에서 내려주는 사용자의 접속 인증 기록을 남겨 다음번에 또 서버에 접속할 때 쿠키에 저장된 데이터를 이용하는 것이고, 캐시는 클라이언트가 웹 페이지에 접속했을 때, 서버에서 매번 같은 데이터를 전송해주는 일을 줄이기 위해 캐시에 저장된 데이터를 사용하는 것입니다.

 

캐시 기본동작

캐시가 없을 때 Request-Response

1. 첫 번째 요청

 

2. 두 번째 요청

 

> 데이터가 변경되지 않아도 계속 네트워크를 통해서 데이터를 다운받아야 합니다.

> 매번 같은 데이터를 같은 속도로 받아야 하니 답답하겠죠?

 

캐시를 사용할 때 Request-Response

1. 첫 번째 요청

2. 두 번째 요청

> 캐시 덕분에 캐시 가능 시간동안 네트워크를 사용하지 않고 파일을 받을 수 있습니다.

> 덕분에 서버입장에서는 서버 트래픽을 줄이고 사용자 입장에서는 빠른 속도로 로딩할 수 있겠죠?

3. 세 번째 요청 - 시간 초과

> 캐시 유효 시간 ( Cache-Control : max-age = 60s )가 지나면 다시 서버를 통해 데이터를 조회하고 캐시를 갱신합니다.

> 이때 다시 네트워크 다운로드가 발생합니다.

---

검증 헤더

캐시 유효 시간이 초과해서 서버에 다시 요청한 경우 두 가지 상황이 나타날 수 있습니다.

 

1. 서버가 기존 데이터를 변경한 경우

2. 서버가 기존 데이터를 변경하지 않은 경우 

 

서버가 기존 데이터를 변경했는지의 여부를 통해 캐시 데이터를 이용할 지, 서버 데이터를 이용할지 결정을 내려야 합니다.

이 결정을 하기 위한 검증 헤더가 있습니다. 

검증 헤더 - Last-Modified, if-modified-since

바로 수정날짜로 검증하는 방법입니다.

서버에서는 최초로 데이터를 보낼 때, 헤더에 Last-Modified로 최종 수정 날짜를 request 메시지에 포함시켜 보내줍니다.

그렇다면 캐시 저장소에도 최종 수정날짜가 포함된 데이터가 저장되겠죠.

 

캐시의 유효기간이 유효한 경우, 이전과 마찬가지로 캐시저장소에서 꺼내서 로딩합니다.

그런데 만약 캐시의 유효기간이 만료된 경우, 사용자는 우선 캐시저장소의 캐시를 살펴본 후 찾고자 하는 캐시가 유효기간이 만료되었다면 해당 캐시 데이터의 유효기간만 if-modified-since로 가지고와서 서버에 전송합니다.

 

캐시 유효기간이 만료된 경우 1

만약 데이터가 수정이 되었다면 message body를 포함하여 데이터를 다시 보내겠죠? 하지만 수정이 안되었다면 304 Not Modified 를 응답 메시지로 보내 캐시에 있던 데이터가 수정되지 않았음을 사용자에게 알려주고 해당 데이터의 캐시 데이터의 max-age를 설정값으로 재가동시켜 사용자가 캐시데이터를 이용할 수 있게 해줍니다.

캐시 유효기간이 만료된 경우 2

> 이렇게 해서 응답 메시지를 이용해 헤더데이터를 갱신하고 캐시에 있는 데이터를 사용합니다.

> 캐시 유효 시간이 초과해도, 서버의 데이터가 갱신(수정)되지 않으면 304 Not modified + 헤더 메타 정보만 응답 메시지로 보냅니다.

> 클라이언트는 서버가 보낸 응답 헤더 정보로 캐시를 갱신하고 해당 캐시를 재활용합니다.

> 결과적으로 네트워크 다운로드가 발생하지만 용량이 적은 헤더정보만 다운로드 하기 때문에 매우 실용적이죠.

검증 헤더 - ETag, if-none-match

Last-Modified, If-modified-Since 단점 

1. 1초 미만 단위로 캐시 조정이 불가능합니다. 

2. 데이터를 수정해서 날짜가 다르지만, 데이터 내부 내용은 똑같은 경우도 서버에서 데이터를 내려주어야 함.

 

이 때 ETag, if-none-match 를 사용하면 해결할 수 있습니다.  

 

ETag는 캐시용 데이터에 hash를 이용해 임의의 고유한 버전 이름을 달아두는 방식입니다.

일반적으로 데이터가 변경되면 ETag를 바뀌기 때문에, 실제 데이터 내용이 변경되었는지 여부로 캐시를 이용할지 서버 데이터를 다시 리로드할지 결정할 수 있어요.

 

전체적인 플로우는 앞서 설명한 Last-Modified, if-modified-since와 동일하기 때문에 그림으로 설명하지 않도록 하겠습니다.

 

+ ETag는 서버에서 변경 및 유지할수 있기 때문에 캐시 제어 로직을 서버에서 완전히 관리하기 때문에, 서버 입장에선 캐시를 제어해서 트래픽을 낮출 수 있습니다. 

ex) 서버에서는 파일이 변경되어도 ETag를 동일하게 유지시켜 클라이언트가 캐시를 사용하도록 유도.

 

---

캐시 제어 헤더 

Cache-Control 

Cache-Contorl : max-age

• 캐시 유효시간 / 초단위

Cache-Contorl : no-cache

• 데이터는 캐시해도 되지만, 항상 원(origin) 서버에 검증하고 사용
• 원 서버에 문제가 생겨 접근 불가 시 오류보다는 오래된 데이터라도 돌려줍니다.

Cache-Contorl : no-store

• 데이터에 민감한 정보가 있으므로 캐시에 저장하지 않음 (메모리에서 사용하고 최대한 빨리 삭제)

Cache-Control : must-revalidate

• 캐시 만료 후 최초 조회 시 원 서버에 검증해야함
• 원 서버 접근 실패 시 오류 메시지를 리턴합니다. 오래된 데이터를 보여주지 않습니다.
• must-revalidate는 캐시 유효 시간이라면 캐시를 사용하도록 합니다.
• 원 서버에 문제가 생겨 접근 불가 시 반드시 오류를 돌려줍니다.

만약 아예 캐시를 이용하지 못하게 하고 싶은 경우

Cache-Control: no-cache, no-store, must-revalidate 로 설정.

Expires 

• max-age 하위 호환으로 날짜로 캐시 만료일 지정
• HTTP 1.0부터 사용
• 지금은 더 유연한 Cache-control : max-age 를 권장
• 우선순위가 Cache-control : max-age보다 낮아 같이 쓰면 expires는 무시됨.

---

프록시 캐시 서버

프록시 서버는 클라이언트가 자신을 통해 다른 네트워크에 간접적으로 접속할 수 있게 해주는 Origin 서버의 중계 서버입니다.

클라이언트와 서버간의 거리가 멀어 상호 통신이 오래 걸리는 경우 프록시 서버를 사용합니다.

프록시 캐시 서버는 원 서버에 요청된 내용들을 캐시를 이용해 저장해 두어 클라이언트가 요청할 때 프록시 캐시 서버의 캐시 데이터를 보여줍니다.

Cache-Control : public

> 프록시 서버에는 public 캐시로 저장합니다.

Cache-Control : private

> 해당 사용자만을 위한 캐시로 private 캐시에 저장합니다.

Cache-Control: s-maxage 

> 프록시 서버 캐시에만 적용되는 max-age

---

<참고 자료>

https://zorba91.tistory.com/163

캐시(Cache)와 쿠키(Cookie)의 차이점(알기 쉽게 표 정리)

https://www.inflearn.com/course/http-%EC%9B%B9-%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC/dashboard

모든 개발자를 위한 HTTP 웹 기본 지식 - 인프런 | 강의

https://toss.tech/article/smart-web-service-cache

웹 서비스 캐시 똑똑하게 다루기