[Network] HTTP (4-1) - HTTP 캐시 제어
웹 브라우저의 캐시 원리와 HTTP의 캐시 제어에 대한 개념 정리
웹 브라우저의 캐시(Cache) 원리
컴퓨터 운영 체제에서의 캐시(Cache)는 주기억장치에서 자주 사용하는 프로그램과 데이터를 하드디스크로부터 가져오는데 시간이 많이 걸리기 때문에 캐시 저장소에 임시로 적재해두고 빠르게 접근하기 위한 기술이다.
캐시는 비단 컴퓨터 OS에만 국한된 기술이 아니다.
임시 저장소에 적재해놓고 빠르게 액세스함으로써 처리 성능을 높인다는 개념 자체는 어디에서나 적용이 가능하다.
이는 인터넷(Internet)에서도 적용된다.
웹 브라우저는 서버와 HTTP 프로토콜을 통해 리소스를 서버에게 요청을 하여 가져오고, 이를 사용자에게 리소스를 화면으로 보여주거나 제공한다.
이러한 통신 과정을 거치면서 클라이언트는 네트워크를 거치는 시간이 소비되며, 서버는 요청을 처리하는데 시간이 소비된다.
만약 클라이언트가 이전에 받은 데이터와 똑같은 데이터를 서버에 재요청을 할 때, 똑같은 통신 과정을 거치게된다면, 이 과정은 낭비라고 할 수 있다.
따라서 이러한 낭비를 줄이기 위한 해결책으로 캐시의 개념을 웹 브라우저에 그대로 적용한, HTTP에서 제공하는 헤더(Headers)인 Cache-Control이다.
브라우저는 이 Cache-Control 헤더를 적절하게 사용함으로써, 상황에 따라 서버의 부하를 줄일 수 있으며, 클라이언트는 네트워크 통신 기간이나 트래픽의 양을 줄일 수 있게 되었다.
하지만 캐시(Cache)는 다루기가 까다로운게, 캐싱을 잘못하면 불일치한 리소스를 받게 되거나 서비스 의도와는 다른 동작을 할 수 있게 되기 때문에 캐시를 다루는 기술을 확실하게 알아둘 필요는 있다.
HTTP 캐시 제어
캐시 제어 헤더의 종류
Cache-Control 헤더
캐시의 유효 시간(생명 주기)을 명시하는 응답(Response) 헤더로, 헤더 값의 파라미터 종류로는 아래와 같다.
max-age- 캐시 유효 시간을 의미하며, 초 단위
no-cache- 데이터는 캐시해도 되지만, 항상 Origin Server에 검증 후 사용
no-store- 데이터에 민감한 정보가 포함되어 있어서 저장 불가 혹은 최대한 빠르게 삭제해야함
public- public 캐시(프록시 캐시 서버)에 저장이 가능
private- public 캐시에 저장 불가
s-maxage- 프록시 캐시 서버에 적용되는
max-age
Age- Origin Server의 응답이 프록시 캐시 서버에 머문 시간으로, 초 단위
must-revalidate- 캐시 만료 후 최초 조회시, Origin Server에 검증
위와 같은 다양한 캐시를 아래의 예시처럼 ,(콤마)로 여러 파라미터를 열거해서 사용이 가능하다.
max-age=86400응답은 최대 1일(60초 $\times$ 60분 $\times$ 24시간) 동안 브라우저 및 중간 캐시가 캐싱할 수 있다.
private, max-age=600응답은 최대 10분(60초 $\times$ 10분) 동안 (중간 캐시가 아닌) 브라우저가 캐싱할 수 있다.
public, max-age=31536000응답은 1년 동안 모든 캐시가 저장할 수 있다.
Pragma 헤더
1
2
HTTP/1.1 200 OK
Pragma: no-cache
HTTP/1.0 하위 호환을 위해 사용하는 캐시 제어 헤더이며, Cache-Control과 동일한 역할을 수행하지만 권장되지 않는다.
Expires 헤더
1
2
HTTP/1.1 200 OK
Expires: Wed, 21 Oct 2015 07:28:00 GMT
캐시의 만료일을 명시하는 헤더로, 정확한 날짜를 지정해야 한다.
Cache-Control 헤더에도 max-age로 유효 시간을 명시하는 것이 더 추천되기 때문에, 현재는 사용이 권장되지 않고 하위 호환을 위해 사용된다.
만일 max-age와 동시에 사용되면 Expires는 무시된다.
웹 브라우저의 캐시 기본 동작
캐시가 없을 경우 X
만일 캐시가 없을 경우에 똑같은 이미지를 요청한다면, 서버에서는 동일한 이미지를 매번 1.1M 용량의 데이터로 응답해야 한다.
용량이 작은 리소스라면 큰 문제가 되지는 않겠지만, 용량이 커질 수록 통신 비용이 늘어나게 되고 로딩 속도도 느려지는 문제가 생긴다.
캐시가 없을 경우, 요청/응답 시나리오
- 클라이언트에서
star.jpg이미지를 요청한다. - 서버에서는 해당 이미지가 있으면 응답을 줘야하는데, 이미지의 HTTP 헤더 + 바디를 합쳐 대략 1.1M 정도 용량의 데이터로 응답한다.
- 클라이언트에서는 해당 이미지를 응답받아 사용한다.
- 클라이언트에서는
star.jpg이미지를 다시 한 번 더 요청한다. - 서버에서는 동일한 이미지를 다시 1.1M 정도 용량의 데이터로 응답한다.
- 클라이언트에서는 해당 이미지를 응답받아 사용한다.
- 동일한 이미지를 요청하는데 네트워크를 통해 같은 데이터를 또 다운받아야 한다.
캐시를 이용한 요청 O
그렇다면 캐시를 웹 브라우저에 적용하면 얼마나 이점이 있는지를 시나리오를 통해 알아보도록 한다.
클라이언트에서
star.jpg이미지를 요청한다.서버에서는 해당 이미지를 응답해준다.
이때, HTTP 메시지에 Cache-Control 헤더를 넣어주어 캐시의 유효 시간을 설정한다.
그림에서는 60초로 설정해서 60초 동안 해당 캐시가 유효하다는 의미이다.서버로부터 응답을 받게 되면, 클라이언트에서는 Cache-Control 헤더를 이해하고 웹 브라우저 캐시에 응답 결과를 60초 동안 저장한다.
클라이언트가
star.jpg이미지를 재차 요청한다.
이때, 서버에게 가는 것이 아닌 우선 캐시 저장소를 조회하게 된다.만일 캐시되어있고, 60초 이내에 요청한 상태라면, 캐시에서 자료를 가져오게 된다.
해당 이미지에서 볼 수 있듯이, 캐시를 시용하게 되면, 한 번 응답받았던 데이터는 브라우저의 캐시 저장소에 남아 일정 시간 내에 계속해서 참조할 수 있기 때문에 서버로부터 불필요한 네트워크 다운로드를 효과적으로 줄일 수 있다.
사용자는 빠른 서비스를 경험할 수 있고, 서버는 네트워크 사용량을 줄여 비용을 아낄 수 있게 된다.
캐시 유효 시간이 지날 경우 △
그렇다면 만약에 60초가 지나게 되어 캐시 유효 기간이 만료된 후에 클라이언트가 그 자료를 요청할 경우 어떻게 작동하는지 다음 시나리오를 통해 확인해보도록 한다.
앞의 과정은 위의 캐시를 이용한 요청과 동일하기에 생략
클라이언트가
star.jpg이미지를 재차 요청하지만, 60초의 캐시 유효 시간이 지나서 더 이상 가져올 수 없게 되었다.
그러면 클라이언트는 다시 서버에게 처음과 같이 요청한다.
다시 네트워크 다운로드가 발생한다.서버는 똑같이 Cache-Control 헤더를 응답하고, 브라우저는 다시 자료를 캐시에 저장한다.
위의 시나리오에서 볼 수 있듯이, 캐시 유효 기간이 지났을 경우 처음과 같이 서버에 요청을 보내야 한다.
그러면 캐시 유효 기간을 길게 늘리면 되지 않을까하는 생각이 들 수 있다.
하지만 이는 좋은 방법이 아니다.
왜냐하면, 오랜 기간 변경되지 않아도 무방한 데이터가 있는 반면, 짧은 변경 주기를 갖는 데이터도 존재하기 때문이다.
만료 기간이 길 경우, 캐시 데이터 또한 오래된 데이터일 가능성이 높다는 것이다.
따라서, 비록 캐시 유효 기간이 지났더라도, 오랜 기간 변경되지 않아도 되는 데이터일 경우에는 처음부터 요청을 하는 것이 낭비이다.
그래서 더욱 더 효율적인 캐시 전략을 위해 웹 브라우저에는 별도의 캐시 검증 로직을 수행하게 된다.
“캐시를 얼마나 오래 유지해야 하는가?”에 대한 답은 없다고 봐야한다.
정해진 답이 있다기 보다는, 데이터의 성격과 데이터 사용에 대한 상황 등 복합적으로 생각해서 설정해야 한다.