[Http Cache] 캐시(Cache)의 동작 원리와 조건부 요청 - 1편

서론

---

이전 글에서 캐시의 기본 개념에 대해 알아보았다.

 

이번 글에서는 캐시(cache)의 동작과 조건부 요청 등에 대해 학습 해보려한다. 바로 시작하자.

 

---

 

캐시 기본 동작

---

캐시가 없을 때

첫번째 요청

(캐시 없을 떄) 첫 번째 요청

(캐시 없을 떄) 첫 번째 요청

 

두번째 요청

(캐시 없을 떄) 두 번째 요청

(캐시 없을 떄) 두 번째 요청

위에 첨부한 이미지를 보면 알 수 있듯 캐시가 없을 경우에는  star.jpg가 필요할 경우 계속 서버로 요청하게 된다. 이렇게 캐시가 없다면 서버 부하가 생길 수 있다. 캐시가 없을 경우 발생하는 단점에 대해 정리하면 다음과 같다.

 

• 데이터가 변경되지 않아도 계쏙 네트워크를 통해서 데이터를 다운로드 받아야한다.
• 인터넷 네트워크는 매우 느리고 비싸다.
• 브라우저 로딩 속도가 느리다.
• 사용자가 필요로 하는 부분에 대해 느린 속도를 경험할 수 있다.

 

 

이제 아래에서 캐시를 사용하면 어떤 효과가 생기는지 알아보자.

 

캐시 적용

첫 번째 요청

(캐시 적용) 첫 번째 요청

(캐시 적용) 첫 번째 요청

 

두 번째 요청

(캐시 적용) 두 번째 요청

위와 같이 캐시를 적용했을 경우에는 브라우저 캐시에 저장을 해놓았다가 필요한 부분을 거기서 다시 가져올 수 있다. 이러한 행위로 생기는 장점은 다음과 같다.

 

• 캐시 가능 시간동안 네트워크를 사용하지 않아도 된다.
• 비싼 네트워크 사용량을 줄일 수 있다.
• 브라우저 로딩 속도가 매우 빠르다.
• 사용자가 캐싱된 데이터를 이용하여 보다 빠른 경험을 할 수 있다.

첫번째에서 말햇듯 캐시에는 가능 시간을 설정(cache-control : max-age)할 수 있는데 캐시 시간이 다 되면 어떻게 진행되는지 다음 예시 이미지로 보자.

 

 

캐시 시간 초과

(캐시 적용)세 번째 요청 - 캐시 시간 초과

(캐시 적용)세 번째 요청 - 캐시 시간 초과

(캐시 적용)세 번째 요청 - 캐시 시간 초과

 

위와 같이 기본적으로 cache-control : max-age를 통해 60초라는 유효 시간이 초과하면 서버를 통해 데이터를 다시 조회하고 캐시를 갱신하게 된다. 물론 이 때 다시 네트워크 다운로드가 발생한다.

 

근데 만약 시간이 초과가 되었지만 브라우저의 데이터는 변하지 않았을 경우에도 서버로 요청을 해서 데이터와 캐시를 갱신을 해야하는데 이것은 비효율적이지 않은가?

 

그래서 다음과 같이 유효시간이 초과해서 서버에 요청 했을 때 다음과 같은 두 가지 상황이 나타난다.

 

 

1. 서버에서 기존 데이터를 변경함

데이터 변경

유효시간이 초과될 동안 실제 데이터가 변경되었을 경우에는 다음과 같이 새로운 데이터로 변경해주면 된다. 그러나 문제는 다음 2번과 같이 유효 시간이 지나도 데이터가 변경이 되지 않았을 때 이다. 한번 알아보자.

 

2. 서버에서 기존 데이터를 변경하지 않음

데이터 변경 X

위의 이미지는 캐시 만료 후에도 서버에서 데이터를 변경하지 않았을 때의 상황이다.

 

유효 시간이 지났을 때 데이터가 같다면 이미 저장해 두었던 캐시를 재사용하기 위해선 클라이언트 데이터와 서버 데이터가 같다는 사실을 확인할 수 있는 방법이 필요하다. 방법은 다음과 같다.

 

브라우저의 캐시 데이터와 서버 데이터가 같은지 확인하는 방법은 무엇이 있을까?

Check -> 클라이언트 데이터 = 서버 데이터

확인 방법

1. 검증 헤더 추가

위와 같이 Last-Modified라는 속성을 추가하여 최종 수정일을 헤더에 추가하는 방법이다.

최종 수정일을 추가했을 경우 프로세스는 다음과 같다.

 

[첫 번째 요청]

첫 번째 요청 시 데이터 최종 수정일의 헤더가 담겨있는 데이터를 캐시에 저장한다.

 

[두 번째 요청]

캐시 데이터 요청을 했는데 요청 시간이 초과되었다. 이제 다시 서버로 해당 데이터를 요청(데이터 및 캐시 갱신 요청)한다.

 

위와 같이 서버로 요청할 때 if-modified-since라는 데이터 최종 수정일 데이터도 같이 담아 요청한다.

 

위와 같이 서버의 데이터 최종 수정일의 시간과 캐시에 담겨져있던 데이터 최종 수정일이 같은 것을 확인하여 데이터가 아직 수정되지 않았다는 사실을 알게되었다.

 

이제 다음과 같이서버에서는 304 Not Modified라는 변화가 없다는 리다이렉트 코드를 전송한다. 이 때 저장되어있던 캐시를 사용하라고 할 것이기에 HTTP Body가 없다!

 

304 Not Modified가 담긴 요청 헤더만 클라이언트로 보내어 캐시의 유효시간을 갱신해준다. 그리고 이제 클라이언트는 304라는 코드를 받은 후 다음과 같이 행동한다.

 

최종으로 클라이언트는 서버에서 변화가 없다는 304 코드를 받았기 때문에 캐시에서 마지막 데이터를 가져와서 사용한다.

 

이렇게 요청 시간이 지난 후 서버에게 요청은 하되 HTTP Body로 star.jpg의 데이터는 받은 것이 아니기에 부하가 덜한 프로세스를 만들 수 있다.

 

지금 이러한 과정들을 간략히 정리해보면 다음과 같다.

 

캐시 유효 시간 초과 시 프로세스 정리

1. 캐시 유효시간이 초과해도, 서버의 데이터가 갱신되지 않으면,

2. 서버에서는 304 Not Modified + 헤더 메타 정보만 응답해준다 (HTTP Body는 X)

3. 클라이언트는 서버가 보낸 응답 헤더 정보로 캐시의 메타 정보를 갱신한다.

4. 클라이언트는 캐시에 저장되어 있는 데이터를 재활용한다.

5. 결과적으로 네트워크 다운로드가 발생하지만 용량이 적은 헤더 정보만 다운로드(갱신)할 수 있다.

--> 캐시는 매우 실용적이다.

 

---

 

마무리

---

캐시에 대해 이번 포스팅에서 다 정리하려했는데, 내용이 생각보다 너무 많아서 편을 쪼개서 만드려고한다. 

이번 글에서는 if-modified-since를 이용한 데이터 최종 수정일을 이용한 캐시의 검증과 요청에 대해 알아보았다면 다음편에서 알아볼 내용은 다음과 같다.

 

만약 최종 수정일은 다르지만 클라이언트의 데이터와 서버의 데이터가 같을 경우에는 어떻게할까?

 

다음편에서 만나자.