[HTTP] 쿠키와 세션 그리고 캐시(2)

우리가 어떤 웹사이트에 들어갔다고 생각해보자

그러면 이미지를 비롯한 수많은 데이터들을 내려받게 될 것이다

 

네트워크상에서 무언가를 가져오는 것은 우리가 생각하는 것보다

굉장히 느리고 (로컬디스크에 비해선) 비용도 상당하다

 

 물론 그게 새로운 것이라면 느리고 비용이 나간다고 하더라도 필수적인 부분이다

하지만 똑같은 리소스를 매번 받아야 한다면?

굉장한 낭비가 될 것이다

 

이때 사용하는 것이 바로 캐시(Cache)이다

 

캐시(Cache)

캐시 저장

이때 데이터에 캐시를 적용하게 되면 브라우저에 있는 캐시 저장소에 저장이 된다.

또한 max-age를 통하여 캐시의 유효기간을 설정 할 수 있다

Cache-Control:max-age=600

이렇게 되면 유효기간내에 동일한 데이터를 요청하였을 경우 캐시 저장소에서 데이터를 꺼내와 사용한다

(유효기간을 초과하면 다시 내려받게 된다)

캐시 사용

데이터가 동일하다는 상황이라면 캐시저장소에서

데이터를 꺼내 써도(유효기간 내에) 무방하다

하지만 유효기간이 지났어도 서버가 동일한 데이터를 제공한다거나

유효기간이 지나지 않았는데 서버가 기존 데이터와 다른  데이터를 제공한다면 어떻게 해야 할까

 

캐시의 조건부 요청

캐시를 효율적으로 사용하기 위한 조건부 요청이 있다

데이터에서 발생하는 상황별로 알아보자

 

1. 데이터가 변하지 않은 경우

이런 경우 데이터가 변하지 않았기 때문에, 유효기간이 지났어도 기존 캐시를 사용할 수 있다

검증 헤더를 사용하면 기존 캐시를 매우 효율적으로 사용할 수 있다

 

서버가 응답할 때 Last-Modified라는 헤더를 같이 보낸다

클라이언트는 받은 이 캐시를 캐시 저장소에 저장한다

Last-Modified

이후 클라이언트가 서버에 요청할 때 if-modified-since라는 헤더에

캐시에 저장되어 있는 데이터가 해당 일시 이후로 수정된 적이 있는지 묻는다

if-modified-since

그리고 서버에서 이 둘을 비교하여 만약 같다면

같은 데이터를 요청하는 것이니 빈 Body와 함께 304 HTTP Status를 보내

클라이언트에게 기존 데이터를 사용하라고 응답한다

이로서 캐시의 유효기간과 상관없이 서버의 데이터가 갱신되지 않으면

클라이언트는 기존에 저장되어 있는 캐시 데이터를 재활용할 수 있다

헤더 검증

하지만 이 방법도 문제가 있다 만약에 서버에서 데이터를 수정하였으나

결국에는 캐시에 저장되어 있던 기존 데이터와 같은 데이터를 응답한다면?

데이터는 동일하다

이러한 단점을 보완하는 것이 ETag이다

날짜를 저장하는 것이 아니라 데이터에 ETag라는

고유의 값을 캐시용 데이터에 담아 응답하는 것이다

고유한 ETag 값을 담아 보낸다

이후 클라이언트는 if-none-match 헤더를 활용하여

캐시의 데이터가 같은지 서버에 검증을 요청할 때 ETag를 같이 보낸다

ETag를 이용하여 검증

이렇게 하면 수정된 날짜와 상관없이 기존의 데이터

그 자체와 비교할 수 있기 때문에 좀 더 효율적으로 캐시 저장소를 활용할 수 있다

 

2. 데이터가 변한 경우

그 반대의 상황인 데이터가 변한 경우가 있을 것이다

정말 간단하게 기존 설명에서의 Last-Modifed나 ETag등을 검증하여

새로운 데이터를 내려받으면 될 것 같지만 그리 단순하지는 않다

 

원서버(Origin Server)

이유는 캐시 서버는 보통 원서버(Origin)서버와

프록시(Proxy)캐시 서버로 나뉘기 때문이다

 

만약 우리가 유튜브를 볼 때 미국에 원서버에 직접 접근한다고 가정해보자

인터넷의 속도는 우리가 생각하는 것보다 그렇게 빠르지 않기 때문에

클라이언트들은 꽤 오랜 시간 통신을 한다

원서버에 직접 접근

허나 한국에 프록시 캐시 서버를 놓고 클라이언트들이

이 프록시 서버에 접근을 한다면 비교적 빠른 통신이 가능하다

 

프록시 서버의 특징은 누군가 사용하는 데이터가 프록시 캐시 서버에 저장이 되기 때문에

많이 사용하는 데이터의 통신 속도가 보통 더 빠르다

프록시 서버에 접근

 

Cache-Control

이제 원서버에 대해서도 알았으니 캐시를 지시하는

캐시 지시어(driectives)에 대해 살펴보자

 

• Cache-Control: public

응답이 public 캐시에 저장되어도 된다

 

• Cache-Control: private (default)

응답이 해당 사용자만을 위한 것임으로 private 캐시에 저장해야 한다

 

• Cache-Control: s-maxage

프록시 캐시에만 적용된다

 

• Age:60 (초)

원서버에서 응답한 후 프록시 캐시 내에 머문 시간을 나타낸다

 

• Cache-Control: no-cache

데이터는 캐시 해도 되지만 항상 원서버에 검증하고 사용하여야 한다

 

• Cache-Control: no-store

데이터에 민감한 정보가 있으므로 저장하면 안 된다 (즉 메모리에서 사용하고 최대한 빨리 삭제되어야 한다)

 

• Cache-Control: must-revalidate

캐시가 만료되면 최초 조회 시 원서버에 검증해야 한다

만약 원서버 접근을 실패하면 반드시 오류가 발생하여야 한다(504 Gateway Timeout)

 

여기서 주의해야 할 점은 no-cache와 must-revalidate의 차이이다

 

• no-cache

no-cache의 경우 원서버에 검증해야 하지만 만약 원서버에 접근을 할 수 없을 시(에러 등등의 이유로)

프록시 캐시에서 오래된 데이터라도 받아와 클라이언트에게 응답한다 (200 OK 응답)

 

• must-revalidate

must-revalidate도 원서버에 검증을 해야 하는데 만약 원서버에 접근할 수 없을 시

프록시 캐시와 상관없이 클라이언트에게 꼭 에러를 응답해야 한다 (504 Gateway Timeout)

 

핵심정리

쿠키와 세션 그리고 캐시의 요점은

무상태 프로토콜인 HTTP에서 상태를 유지시켜 주어 클라이언트에게 더 나은 UX를 제공하고

캐시를 통하여 효율적인 네트워크 통신을 하게 하기 위함이다

 

 

---

개인 학습을 위해 작성되는 글입니다.

제가 잘못 알고 있는 점에 대한 지적 / 더 나은 방향에 대한 댓글을 환영합니다.

 

참조 링크:

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

https://developer.mozilla.org/ko/docs/Web/HTTP/Caching

https://pjh3749.tistory.com/264