1. 캐시 기본 동작
🧐 캐시가 어떻게 동작하는지 기본 동작을 통하여 알아보자.
📁 캐시가 없을 때 첫 번째 요청
- 클라이언트에서 star.jpg 이미지를 요청한다.
- 서버에서는 해당 이미지가 있으면 응답을 주어야 한다.
위 사진에서는 이미지의 HTTP 헤더+바디 = 1.1M정도 용량의 데이터로 응답한다. - 클라이언트에서는 해당 이미지를 응답받아 사용한다.
📁 캐시가 없을 때 두 번째 요청
- 클라이언트에서 star.jpg 이미지를 다시 요청한다.
- 서버에서는 같은 이미지를 다시 1.1M 정도 용량의 데이터로 응답해준다.
- 클라이언트에서는 해당 이미지를 응답받아 사용한다.
❗❗단점
- 같은 이미지를 요청하는데 네트워크를 통하여 같은 데이터를 다시 다운받아야 한다.
- 용량이 클수록 비용이 커지고 브라우저의 로딩속도가 느려진다(=느린 사용자 경험).
🧐 그렇다면, 캐시를 적용했을 때는 어떻게 나아지는지 확인해보자.
📁 캐시를 적용했을 때 첫 번째 요청
- 헤더에 cache-control 속성을 넣어 캐시가 유효한 시간을 넣어준다.
위 사진에서는 60초로 설정하여 60초 동안 해당 캐시가 유효하도록 설정해주었다. - 브라우저 캐시에 응답 결과를 저장하며 60초간 유효하다.
📁 캐시를 적용했을 때 두 번째 요청
- 두 번째 요청할 때는 우선 캐시를 조회한다.
- 캐시가 존재 ⭕, 아직 60초 이내이다.
👉 유효한 캐시가 있어서 해당 캐시에서 자료를 가져온다.
💡 유효시간이 초과한다면?
다시 서버에 요청하고 60초간 유효한 star.jpg 이미지를 응답받아서 캐시를 업데이트 해준다.
👉 이때 다시 네트워크 다운로드가 발생한다.
📌 캐시 적용의 특징
1. 캐시 덕분에 캐시 가능 시간 동안 네트워크를 사용하지 않아도 된다.
2. 비싼 네트워크 사용량을 줄일 수 있다.
3. 브라우저 로딩 속도가 매우 빠르다.
4. 빠른 사용자 경험
✅ 캐시 유효시간이 지나서 재요청하는 경우+
특정 자료가 필요해 요청해야 하는 경우 캐시를 조회할 때 유효시간이 지났지만, 변경이 없기 때문에 해당 데이터를 써도 되는 상황이라면 어떻게 해야 할까? 이를 검증 헤더와 조건부 요청에서 알아본다.
2. 검증 헤더와 조건부 요청1
✅ 캐시 유효 시간이 초과해서 서버에 다시 요청하면 다음 두 가지 상황이 나타난다.
1. 서버에서 기존 데이터를 변경함
2. 서버에서 기존 데이터를 변경하지 않음
📌 캐시 시간 초과
캐시 만료 후에도 서버에서 데이터를 변경하지 않은 경우, 동일한 데이터를 다시 전송하는 대신 저장해 두었던 캐시를 재사용 할 수 있다.
이때. 클라이언트의 데이터와 서버의 데이터가 같다는 사실을 확인할 방법이 필요하다.
⚡ 그래서 검증 헤더가 들어가게 된다.
📁 검증 헤더 추가 첫 번째 요청
- 데이터가 마지막으로 수정된 시간을 헤더에 작성해준다
👉 Last-Modified: 2020년 11월 10일 10:00:00
👉 UTC 표기법으로 적어준다.
- 응답 결과를 캐시에 저장할 때 데이터 최종 수정일도 저장된다.
📁 검증 헤더 추가 두 번째 요청(캐시 시간 초과)
- 캐시 시간이 초과하여 다시 요청을 보낼 때, 캐시에 최종 수정일 정보(Last-Modified)가 있다면 요청 헤더 내 if-modified-since에 해당하는 날짜를 담아서 서버로 보낸다.
- 서버의 해당 자료의 최종 수정일과 비교해서 데이터가 수정되지 않았을 경우, 아래와 같이 응답 메시지에 이를 담아서 알려준다.
- 응답 데이터에 HTTP Body가 없다.
- 전송 데이터는 바디가 없으므로 헤더만 포함된 0.1M만 전송된다.
- 상태코드는 304 Not Modified로 변경된 것이 없다는 것을 알려준다.
- 클라이언트는 해당 응답을 받은 뒤 캐시를 갱신해주고 다시 일정 시간(60초) 유효하게 된다.
📚 정리
- 캐시 유효 시간이 초과해도, 서버의 데이터가 갱신되지 않으면 304 Not Modified + 헤더 메타 정보만 응답한다.
- 클라이언트는 서버가 보낸 응답 헤더 정보로 캐시의 메타 정보를 갱신한다.
- 클라이언트는 캐시에 저장되어 있는 데이터를 재활용한다.
- 결과적으로 네트워크 다운로드가 발생하지만 용량이 적은 헤더 정보만 다운로드받으면 된다.
👉 매우 실용적인 해결책이다.
3. 검증 헤더와 조건부 요청2
📌 검증 헤더
검증 헤더란 캐시 데이터와 서버 데이터가 같은지 검증하는 데이터이다.
Last-Modified , ETag를 활용하여 클라이언트에게 요청할 때, 조건부 요청 헤더를 만들어서 보내면 된다.
📖 예시)
ETag: "v1.0", ETag: "asid93jkrh2l"
Last-Modified: Thu, 04 Jun 2020 07:19:24 GMT
📌 조건부 요청 헤더
- 검증 헤더로 조건에 따른 분기를 서버에 요청한다
- If-Modified-Since: Last-Modified 사용
- If-None-Match: ETag 사용
- 조건이 만족하면 200 OK, 조건이 만족하지 않으면 304 Not Modified
📖 예시)
- If-Match, If-None-Match ➡️ ETag 값 사용
- If-Modified-Since, If-Unmodified-Since ➡️ Last-Modified 값 사용
🧐 If-Modified-Since 이후에 데이터가 수정되었다면?
✅ 데이터 미변경인 경우
- 캐시 2020년 11월 10일 10:00:00 vs 서버: 2020년 11월 10일 10:00:00
👉 데이터 미변경
👉 If-Modified-Since ➡️ 조건: 수정되었는가? => 아니요(=false), 조건 만족 ❌ - 304 Not Modified, 헤더 데이터만 전송(Body 없음)
- 전송 용량 0.1M(헤더 0.1M, 바디 1.0M)
✅ 데이터가 변경된 경우
- 캐시 2020년 11월 10일 10:00:00 vs 서버: 2020년 11월 10일 11:00:00
👉 데이터 변경
👉 If-Modified-Since ➡️ 조건: 수정되었는가? => 예(=false), 조건 만족 ⭕ - 200 OK, 모든 데이터 전송(BODY 포함)
- 전송 용량 1.1M(헤더 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를 사용한 두 번째 요청(캐시 시간 초과)
- If-None-Match를 요청 헤더에 작성해서 보낸다.
- 서버에서 데이터가 변경되지 않았을 경우 ETag는 동일하다.
👉 If-None-Match는 실패다.
- 서버에서는 304 Not Modified를 응답하며 이때 역시 HTTP Body는 없다.
👉 0.1M 전송
- 브라우저 캐시에서는 응답 결과를 재사용하고 헤더 데이터를 갱신한다.
📚 ETag, If-None-Match 정리
- ETag만 서버에 보내서 동일하면 유지하고 다르면 다시 받는다.
- ⚡캐시 제어 로직을 서버에서 관리한다.
- 클라이언트는 단순하게 이 값을 서버에 제공한다
👉 클라이언트는 캐시 메커니즘을 알 필요가 없다.
예시)
서버는 베타 오픈 기간 3일간 파일이 변경되어도 ETag를 동일하게 유지
애플리케이션 배포 주기에 맞춰서 ETag를 모두 갱신
4. 캐시와 조건부 요청 헤더
📌 Cache-Control_캐시 지시어(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는 무시된다.
5. 프록시 캐시
📌 Origin 서버
🧐 한국에 있는 클라이언트에서 별 이미지가 필요한데 해당 이미지는 미국에 있다고 가정해보자. 한국 → 미국까지 직접 접근하여 이미지를 가져오는데 약0.5초가 걸린다면 클라이언트는 모두 0.5초를 기다려야 해당 이미지를 받을 수 있다.
👉 위와 같은 가정도 매우 긍정적으로 시간을 계산한 것이고 실제로는 더 긴 시간이 걸릴 수 있다. 이를 해결하기 위하여 프록시 캐시가 도입되었다.
📌 프록시 캐시 도입 - 첫 번째 요청
-
한국에 프록시 캐시 서버를 두고 한국의 클라이언트는 프록시 캐시 서버를 통하여 자료를 가져오도록 한다.
-
여러 사람이 찾는 자료일수록 이미 캐시에 등록되어 있기 때문에 빠른 속도로 자료를 가져올 수 있다.
➡️같은 국내에 있기에 원서버에 접근하는 것보다 훨씬 빠른 속도에 자료를 가져올 수 있다.
➡️ 예) 유튜브에서 고용량의 영상도 빨리 볼 수 있는 이유.
- 클라이언트에서 사용되고 저장되는 캐시를 'private 캐시'라 하고 프록시 캐시 서버의 캐시를 'public 캐시'라 한다.
📌 캐시 지시어(directives) - 기타
-
Cache-Control: public
⇒ 응답이 public 캐시에 저장되어도 된다. -
Cache-Control: private
⇒ 응답이 해당 사용자만을 위한 것으로 private 캐시에 저장해야 한다(default) -
Cache-Control: s-maxage
⇒ 프록시 캐시에만 적용되는 max-age -
Age:60(HTTP 헤더)
⇒ origin 서버에서 응답 프록시 캐시 내에 머문 시간(초)
6. 캐시 무효화
💡 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와 must-revalidate의 기본 동작에 대하여 알아보자.
📌 no-cache 기본 동작
- 캐시 서버 요청을 하고 프록시 캐시 서버에 도착한다.
- no-cache인 경우 원 서버에 요청하게 된다.
- 원 서버에서 검증 후 응답을 하게 된다.
❗❗ 하지만, 어떠한 이유로 프록시 캐시 서버와 원 서버간의 네트워크가 단절되어 접근이 불가능해진다.
👉 no-cache에서는 응답으로 오류가 아닌 '오래된 데이터라도 보여주자!'라는 개념으로 200 OK로 응답한다.
📌 must-revalidate 기본 동작
- 캐시 서버 요청으로 프록시 캐시 서버로 간다.
❗❗ 프록시 캐시 서버와 원 서버간의 네트워크가 단절되어 접근이 불가능해진다.
👉 must-revalidate에서는 원 서버에 접근이 불가능한 경우 항상 오류가 발생해야 한다. (504 Gateway Timeout)
📚 정리
위에 작성한 확실한 캐시 무효화 응답으로 작성한 헤더를 사용하게 되면
1. no-cache로 무조건 원 서버에서 검증하게 하고
2. must-revalidate로 원 서버와 검증이 안 되면 오류가 발생하도록 한다.
3. 그리고 Pragma를 사용해서 혹시 모를 1.0 이하 버전의 하위 호환도 적용해준다.
