목차
캐시 기본 동작
캐시가 어떻게 동작하는지 기본 동작을 통해 알아보자
캐시가 없을 때 첫 번째 요청
•
클라이언트에서 star.jpg 이미지를 요청한다.
•
서버에서는 해당 이미지가 있으면 응답을 줘야하는데, 이미지의 HTTP 헤더+바디를 합쳐 대략 1.1M정도 용량의 데이터를 응답한다.
•
클라이언트에서는 해당 이미지를 응답 받아 사용한다.
캐시가 없을 때 두 번째 요청
•
클라이언트에서는 star.jpg 이미지를 다시 한 번 요청한다.
•
서버에서는 동일한 이미지를 다시 1.1M정도 용량의 데이터를 응답해준다.
•
클라이언트에서는 해당 이미지를 응답 받아 사용한다.
•
동일한 이미지를 요청하는데 네트워크를 통해 같은 데이터를 또 다운받아야 한다.
•
용량이 클 수록 비용이 커지고 브라우저의 로딩속도가 느려진다.
•
이제는 캐시를 적용해서 어떻게 나아지는지 확인해보자.
캐시를 적용한 첫 번째 요청
•
헤더에 cache-controll 속성을 넣어주어 캐시가 유효한 시간을 넣어준다.
위에서는 60초로 설정해 60초 동안은 해당 캐시가 유효하다는 의미다.
•
그럼 브라우저 캐시에 응답 결과를 저장하며 60초간 유효하다.
캐시를 적용한 두 번째 요청
•
두 번째 요청할때는 우선 캐시를 조회한다.
•
캐시가 존재하고 아직 60초 이내이기에 유효한 캐시가 있어서 해당 캐시에서 자료를 가져온다.
•
유효시간이 초과한다면 어떻게 될까?
⇒ 이 경우에는 다시 서버에 요청을하고 60초간 유효한 star.jpg 이미지를 응답받아서 캐시를 업데이트 해준다.
⇒ 이때 다시 네트워크 다운로드가 발생한다.
캐시 적용
•
캐시 덕분에 캐시 가능 시간동안 네트워크를 사용하지 않아도 된다.
•
비싼 네트워크 사용량을 줄일 수 있다.
•
브라우저 로딩 속도가 매우 빠르다.
•
사용자는 매우 빠른 경험을 할 수 있다.
캐시 유효시간이 지나서 다시 요청을 해야하는 경우...
특정 자료가 필요해 요청을 해야하는 경우 캐시를 조회할 때 유효시간이 지났지만, 변경이 없기때문에 해당 데이터를 써도 되는 상황이라면 어떻게 해야할까? 이를 검증 헤더와 조건부 요청에서 알아본다.
검증 헤더와 조건부 요청1
•
캐시 유효 시간이 초과해 서버에 다시 요청하면 다음과 같은 상황이 생긴다.
1.
서버에서 기존 데이터를 변경한 경우 (노란색 별이 초록색 별이 된 경우)
2.
서버에서 기존데이터가 변경되지 않은 경우
캐시 시간 초과
캐시 만료후에도 서버에서 데이터를 변경하지 않은 경우 서버에서 동일한 데이터를 요청해서 응답받는 것은 여러모로 비용낭비다.
이럴때는 저장해 둔 캐시를 재사용 할 수 있으면 좋은데, 어떻게 클라이언트의 데이터와 서버의 데이터가 동일하다는 것을 알 수있는지에 대해 알아야 한다.
그래서 검증 헤더가 들어가게 된다.
검증 헤더 추가 첫 번째 요청
•
데이터가 마지막으로 수정된 시간정보를 헤더에 작성해준다
⇒ Last-Modified: 2020년 11월 10일 10:00:00
⇒ UTC 표기법으로 적어준다.
•
응답 결과를 캐시에 저장할 때 데이터 최종 수정일도 저장된다.
검증 헤더 추가 두 번째 요청(캐시 시간 초과)
•
캐시 시간이 초과해서 다시 요청을 해야하는데, 캐시에 최종 수정일 정보(Last-Modified)가 있다면 요청 헤더에 if-modified-since에 해당 날짜를 담아서 서버에 보낸다.
•
서버의 해당 자료의 최종 수정일과 비교해서 데이터가 수정이 안되었을 경우 응답 메세지에 이를 담아서 알려준다.
◦
HTTP Body는 응답 데이터에 없다.
◦
상태코드는 304 Not Modified로 변경된것이 없다는 것을 알린다.
◦
그래서 전송 데이터는 바디가 빠졌기에 헤더만 포함된 0.1M만 전송된다.
◦
클라이언트에서는 해당 응답을 받은 뒤 캐시를 갱신해주고 다시 일정시간(60초) 유효하게 된다.
정리
•
캐시 유효 시간이 초과해도, 서버의 데이터가 갱신되지 않으면
•
304 Not Modified + 헤더 메타 정보만 응답한다.
•
클라이언트는 서버가 보낸 응답 헤더 정보로 캐시의 메타 정보를 갱신한다.
•
클라이언트는 캐시에 저장되어 있는 데이터 재활용
•
결과적으로 네트워크 다운로드가 발생하지만 용량이 적은 헤더 정보만 다운로드받으면 된다.
•
매우 실용적인 해결책
검증 헤더와 조건부 요청2
검증헤더란 캐시데이터와 서버 데이터가 같은지 검증하는 데이터로 위에서는 Last-Modified를 사용해봤는데 그밖에는 ETag가 있다.
그리고 이런 헤더를 이용해서 클라이언트에서 서버로 요청할 때 검증부 요청 헤더를 만들어서 보내면 된다.
•
검증 헤더로 조건에 따른 분기
•
If-Modified-Since: Last-Modified 사용
•
If-None-Matach: ETag 사용
•
조건이 만족하면 200 OK
•
조건이 만족하지 않으면 304 Not Modified
If-Modified-Since 이후에 데이터가 수정이 되었다면?
•
데이터 미변경인 경우
◦
캐시 2020년 11월 10일 10:00:00 vs 서버: 2020년 11월 10일 10:00:00
◦
304 Not Modified, 헤더 데이터만 전송(Body 없음)
◦
전송 용량 0.1M(헤더 0.1M, 바디 1.0M)
•
데이터가 변경된 경우
◦
캐시: 2020년 11월 10일 10:00:00 vs 서버: 2020년 11월 10일 11:00:00
◦
200 OK, 모든 데이터 전송(Body 포함)
◦
전송 용량 1.1(헤더 0.1M, 바디 1.0M)
Last-Modified, If-Modified-Since 의 단점
•
1초 미만(0.x초)단위로 캐시 조정이 불가능하다.
•
날짜 기반의 로직을 사용한다.
•
데이터를 수정해 날짜가 다르지만, 같은 데이터를 수정해 데이터 결과가 똑같은 경우
◦
test.txt 파일의 내용을 A→B로 수정했지만, 다시 B→ A로 수정한 경우
•
서버에서 별도의 캐시 로직을 관리하고 싶은 경우
◦
예) 스페이스나 주석처럼 크게 영향이 없는 변경에서 캐시를 유지하고 싶은 경우
ETag, If-None-Match
서버에서 완전히 캐시를 컨트롤하고 싶은 경우 ETag 를 사용하면 된다.
•
ETag(Entity Tag)
•
캐시용 데이터에 읨의의 고유한 버전 이름을 달아둔다
⇒ ETag: "v1.0", ETag: "a2jiodwjekjl3"
•
데이터가 변경되면 이 이름을 바꾸어서 변경한다(Hash를 다시 생성)
⇒ ETag:"aaaa" → ETag:"bbbb"
•
단순하게 ETag만 보내서 같으면 유지하고 바르면 다시 받는다.
ETag를 사용한 첫 번째 요청
•
헤더에 ETag 를 작성해서 응답해준다.
•
클라이언트의 캐시에선 ETag 값을 저장한다.
ETag를 사용한 두 번째 요청
캐시 시간 초과
•
캐시시간이 초과되서 다시 요청을 해야하는 경우이다.
•
이때 If-None-Match를 요청 헤더에 작성해서 보낸다.
•
서버에서 데이터가 변경되지 않았을 경우 ETag는 동일하다. 그래서 If-None-Match는 실패다.
•
이 경우 서버에서는 304 Not Modified를 응답하며 이때 역시 HTTP Body는 없다.
•
브라우저 캐시에서는 응답 결과를 재사용하고 헤더 데이터를 갱신한다.
정리
•
ETag만 서버에 보내 동일하면 유지하고 다르면 다시 받는다.
•
캐시 제어 로직을 서버에서 관리한다.
•
클라이언트는 단순하게 이 값을 서버에 제공한다
◦
캐시 매커니즘을 알 필요가 없다.
•
예)
◦
서버는 베타 오픈 기간 3일간 파일이 변경되어도 ETag를 동일하게 유지
◦
애플리케이션 배포 주기에 맞춰서 ETag를 모두 갱신
캐시와 조건부 요청 헤더
캐시와 관련된 헤더들과 조건부 요청 헤더를 정리하는 시간을 가져본다.
캐시 제어 헤더
캐시 지시어(directives)
•
Cache-Control: max-age
⇒캐시 유효 시간이고 초 단위이다.
•
Cache-Control: no-cache
⇒ 데이터는 캐시해도 되지만, 항상 원(origin) 서버에 검증하고 사용해야 한다.
•
Cache-Control: no-store
⇒ 데이터에 민감한 정보가 있기에 저장하면 안된다.
(메모리에서 사용하고 최대한 빨리 삭제)
Pragma
캐시 제어(하위 호환)
•
Pragma: no-cache
•
HTTP 1.0 하위 호환
•
현재는 거의 사용되지 않는다.
Expires
캐시 만료일 지정(하위 호환)
•
expires: Mon, 01 Jan 1990 00:00:00 GMT
•
캐시 만료일을 정확한 날짜로 지정
•
HTTP 1.0부터 사용
•
지금은 더 유용한 max-age를 권장한다.
•
그래서 max-age와 동시에 사용되면 Expires는 무시된다.
프록시 캐시
Origin 서버
⇒ 한국에있는 클라이언트에서 별 이미지가 필요한상황인데 해당 이미지의 원서버가 미국에 있다고 가정해보자. 한국에서 미국까지 직접 접근하여 이미지를 가져오는데 0.5초가량 걸린다고하면 여러 클라이언트는 모두 0.5초 가량을 기다려야 해당 이미지를 받을 수 있다. 이것도 매우 긍정적인 상황이고 실제로는 더 많은 시간이 걸릴 수 있다. 그래서 이를 해결하기 위해 프록시 캐시가 도입되었다.
프록시 캐시 도입 - 첫 번째 요청
•
한국에 프록시 캐시서버를 두고 한국의 클라이언트는 프록시 캐시서버를 통해 자료를 가져오도록 한다.
•
여러 사람이 찾은 자료일수록 이미 캐시에 등록되어있기에 빠른 속도로 자료를 가져올 수 있다.
⇒같은 국내에 있기에 원서버에 접근하는것보다 훨씬 빠른 속도에 자료를 가져올 수 있다.
⇒ 예) 유튜브에서 고용량의 영상도 빨리 볼 수 있는 이유.
•
클라이언트에서 사용되고 저장되는 캐시를 private캐시라 하고 프록시 캐시서버의 캐시를 public 캐시라 한다.
Cache-Control
캐시 지시어(directives) - 기타
•
Cache-Control: public
⇒ 응답이 public 캐시에 저장되어도 된다.
•
Cache-Control: private
⇒ 응답이 해당 사용자만을 위한 것으로 private 캐시에 저장해야 한다(default)
•
Cache-Control: s-maxage
⇒ 프록시 캐시에만 적용되는 max-age
•
Age:60(HTTP 헤더)
⇒ 오리진 서버에서 응답 프록시 캐시 내에 머문 시간(초)
캐시 무효화
Cache-Control: no-cache, no-store, must-revalidate
Pragma: no-cache
정말 캐시를 무효화를 확실하게 해야하는 경우 위와같이 적용을 하면된다.
캐시를 적용안해도 임의로 캐시를 적용하는 경우도 있는데, 특정 페이지에서 정말 캐시가 되면 안된다고 할때 위 내용을 다 넣어주면 된다.
예) 통장 잔고
캐시 지시어(directives) - 확실한 캐시 무효화
•
Cache-Control: no-cache
⇒ 데이터는 캐시해도 되지만, 항상 원 서버에 검증하고 사용해야 한다.
⇒ 이름때문에 캐시를 사용안한다고 생각할 수 있으니 주의하자.
•
Cache-Control: no-store
⇒ 데이터에 민감한 정보가 있기에 저장하면 안되니 메모리에서 사용하고 최대한 빨리 삭제
•
Cache-Control: must-revalidate
⇒ 캐시 만료후 최초 조회시 원 서버에 검증해야한다.
⇒ 원 서버 접근 실패시 반드시 오류가 발생해야 한다. - 504(Gateway Timeout)
⇒ must-revalidate 는 캐시 유효시간이라면 캐시를 사용한다.
•
Pragma: no-cache
⇒ HTTP 1.0 하위 호환
어째서 no-cache와 must-revalidate를 같이 써야 하는가?
둘 다 원 서버에 검증해야 하는데 어째서 혼용해서 써야할까?
•
no-cache 기본 동작
⇒캐시 서버 요청을 하면 프록시 캐시 서버에 도착하면 no-cache인 경우 원 서버에 요청을 하게된다. 그리고 원 서버에서 검증 후 응답을하게 된다.
⇒ 하지만, 어떠한 이유라도 프록시 캐시 서버와 원 서버간 네트워크 연결이 단절되어 접근이 불가능 하다면, no-cache에서는 응답으로 오류가 아닌 오래된 데이터라도 보여주자라는 개념으로 200OK으로 응답을 한다.
•
must-revalidate 기본 동작
⇒ 캐시 서버요청을 해 프록시 캐시 서버로 갔을때 캐시 서버와 원 서버간의 연결이 단절되어 접근이 불가능하다면 must-revalidate에서는 원 서버에 접근이 불가능한 경우 항상 오류가 발생해야 한다.(504 Gateway Timeout)
정리
그래서 위에 작성한 확실한 캐시 무효화 응답으로 작성한 헤더를 사용하게 되면
no-cache로 무조건 원 서버에서 검증을 하게하고 must-revalidate로 원 서버와 검증이 안되면 오류가 발생하도록 한다. 그리고 Pragma를 사용해서 혹시모를 1.0 이하 버전의 하위호환도 적용해준다.
