[HTTP] HTTP 헤더 - (2) 캐시와 조건부 요청

📌 캐시 기본 동작

✅ 캐시가 없다면?

• 데이터가 변경되지 않아도 매번 새로 데이터를 다운로드 받아야 한다
• 인터넷 네트워크는 매우 느리고 비쌈 > 브라우저 로딩 속도가 느림 > 느린 사용자 경험

 

✅ 캐시 적용 후

1️⃣ 첫번째 요청

• 서버는 응답 메세지 헤더의 cache-control에서 캐시의 유효한 시간을 지정해서 응답 결과를 보낸다.
• 이 때 응답 결과는 브라우저 캐시에 저장된다.

 

 2️⃣ 두번째 요청

 

• 클라이언트에서 이전에 사용했던 리소스에 대한 요청 메세지가 발생하면 먼저 브라우저 캐시에서 캐시 유효 시간을 검증한다.
• 브라우저 캐시에 유효한 데이터가 있으면 서버에 요청메세지를 보낼 필요 없이 바로 브라우저 캐시에서 리소스를 조회한다.
• 캐시 시간이 초과되면 서버에 재요청하고 캐시를 갱신한다. (네트워크 다운로드 발생)

 

✅ 캐시 적용 장점

• 캐시 가능 시간 동안 네트워크를 사용하지 않아도 됨
• 비싼 네트워크 사용량을 줄일 수 있음
• 브라우저 로딩 속도 매우 빠름
• 빠른 사용자 경험

 

📌 검증 헤더와 조건부 요청

• 캐시 유효 시간이 초과해서 서버에 재요청할 경우 두가지 상황이 발생할 수 있음
  • 서버에서 기존 데이터를 변경함
  • 서버에서 기존 데이터를 변경하지 않음

→ 캐시 만료 후에도 기존 데이터를 변경하지 않았다면 데이터를 재전송하지 않고 캐시를 재사용할 수 있다! 하지만 데이터의 변경 여부를 판단할 수 있는 방법 필요

 

✅ 검증 헤더 사용

1️⃣ 서버에서 데이터 전송 시 검증 헤더 추가

• 서버에서 처음 데이터를 전송할 때 검증 헤더를 추가하여 메세지 바디와 함께 최종적으로 수정된 날짜를 함께 보낸다. (Last-Modified)
• 웹 브라우저는 브라우저 캐시에 응답 결과와 함께 최종 수정일을 저장한다.

 

2️⃣ 유효 시간이 만료된 캐시와 서버 데이터의 최종 수정일 비교

• 캐시의 유효 시간이 만료되면 클라이언트는 캐시의 최종 수정일 정보와 함께 요청메세지를 보낸다. (if-modified-since)
• 서버는 전달받은 최종 수정일 정보와 서버에 저장된 데이터의 최종 수정일을 비교한다.

 

3️⃣ 데이터가 수정되지 않은 경우 서버는 응답 메세지에 헤더만 포함해서 보낸다.

 

• 데이터가 수정되지 않았음을 확인한 서버는 304 Not Modified 상태코드와 함께 응답 메세지를 보낸다.
• 이때 HTTP Body가 없고 헤더 정보만 있기 때문에 전송되는 데이터의 용량이 적다.
• 클라이언트는 서버의 응답 메세지를 받고 브라우저 캐시에 저장된 리소스를 재사용하며 헤더 데이터를 갱신한다. (다시 60초 유효)

 

 

✅ 검증 헤더

• 캐시 데이터와 서버 데이터가 같은지 검증하는 데이터
• Last-modified, ETag

 

✅ 조건부 요청 헤더

• 검증 헤더로 조건에 따른 분기
• If-Modified-Since, If-Unmodified-Since : Last-Modified 사용
• If-Match, If-None-Match : ETag 사용
• 조건이 만족하면 200 OK, 만족하지 않으면 304 Not Modified

 

✅ Last-Modified, If-Modified-Since 단점

• 1초 미만 단위로 캐시 조정 불가
• 날짜 기반의 정해진 로직 사용
• 날짜가 다르지만 같은 데이터를 수정해서 데이터 결과가 같은 경우 사용 불가
• 서버에서 별도의 캐시 로직을 관리하고 싶은 경우 사용 불가 e.g. 스페이스나 주석처럼 크게 영향 없는 변경에서 캐시를 유지하고 싶은 경우

 

✅ ETag, If-None-Match 헤더 사용

🔻 ETag (Entity Tag)

• 캐시용 데이터에 임의의 고유한 버전 이름을 달아둠
• 데이터가 변경되면 서버가 이름을 바꿔서 생성 (Hash 다시 생성)
• 컨텐츠가 같으면 해시값은 똑같이 나옴
• ETag만 보내서 같으면 유지, 다르면 다시 받기 > 검증 헤더 (If-None-Match)
• 캐시 제어 로직을 서버에서 완전히 관리
• 클라이언트는 단순하게 이 값을 서버에 제공(클라이언트는 캐시 매커니즘 모름)
• e.g. 애플리케이션 배포 주기에 맞추어 ETag 모두 갱신

 

📌 캐시와 조건부 요청 헤더 정리

✅ 캐시 제어 헤더

Cache-Control : 캐시 제어 > 가장 중요

Pragma : 캐시 제어 (하위 호환)

Expires : 캐시 유효 기간 (하위 호환)

 

✅ Cache-Control

🔻 Cache-Control: max-age

캐시 유효 시간을 지정함(초 단위)

 

🔻 Cache-Control: no-cache

데이터는 캐시해도 되지만 항상 origin 서버에 검증하고 사용

 

🔻 Cache-Control: no-store

데이터에 민감한 정보가 있으므로 저장하면 안됨 (메모리에서 사용 후 최대한 빨리 삭제)

 

🔻 Cache-Control: must-revalidate

캐시 만료후 재조회시 원 서버에 검증해야 함

원 서버 접근 실패시 반드시 오류가 발생해야 함 -> 504(Gateway Timeout)

캐시 유효시간 이라면 캐시를 사용

 

📌 프록시 캐시

• origin 서버와 클라이언트 간에 프록시 캐시 서버를 두어 더 빠르게 데이터 전송이 가능
• 한번 다운로드 받아놓으면 다음 로딩부터는 빠르게 이루어짐
• 중간에서 공용으로 사용하는 캐시 -> public 캐시 (Cache-Control: public)
• 개인 로컬에서 사용하는 캐시 -> private 캐시 (Cache-Control: private)

 

📌 캐시 무효화

웹 브라우저가 임의로 캐시를 사용할 수 있기 때문에 절대 캐시해서는 안되는 데이터의 경우 무효화 캐시 지시어를 지정 한다.

 

• Cache-Control : no-cache, no-store, must-revalidate
• Pragma : no-cache (HTTP 1.0 하위 호환) -> 과거 버전까지 지원

→ 다 넣어주면 캐시를 절대 저장하지 않음 (확실한 캐시 무효화 응답)

 

✅ no-cache vs must-revalidate

• no-cache : 원서버에 접근할 수 없는 경우 캐시 서버 설정에 따라 캐시 데이터를 반환할 수 있음 (오류보다는 오래된 데이터)

 

• must-validate : 원서버에 접근할 수 없는 경우 항상 오류 발생 (504 Gateway Timeout)

 

 

---

강의 자료

모든 개발자를 위한 HTTP 웹 기본 지식 - 인프런 | 강의