HTTP Cache 동작원리 + Hash

Cache 동작의 핵심은 재검증 주기와 재검증 기준 주기와 검증 주기와 검증 주기와 검증 주기와 검증 주기와 검증 

 

HTTP Cache는 웹 성능 최적화에 중요한 역할을 하지만, 실시간 데이터를 정확하게 반영하지는 않는다. 예를 들어, 은행 계좌 잔고처럼 실시간으로 변동되는 데이터의 경우, 캐시를 통해 잘못된 정보가 제공 될 수 있다. 만약 100만 원이 캐시되어 있는 상태에서 돈을 계속 사용하면, 실제 잔고가 -500만 원이 되어도 캐시가 갱신되지 않는 한 100만원 만 보일 수 있다.

이러한 이유로 실시간성이 중요한 데이터에는 캐시 사용을 신중하게 고려해야 한다.

---

캐시의 준실시간성 보장

 

캐시는 임시(반영구적)저장을 위한 전략이다. 그러나 실시간성을 아예 포기한다는 것이 아니라, 재검증(revalidate) 과정을 통해 준실시간성을 보장한다. 이 때 중요한 요소가 재검증 주기와 재검증 기준이다.

• 준실시간: 캐시해놓은 데이터가 너무 오래된 데이터가 되지 않도록 특정 주기에 따라 재검증
• 재검증: 캐시한 데이터의 원본 주인인 웹 서버가 특정 주기에 따라, 캐시한 데이터가 오래됐는지 검증
  • 검증 방법: 조건부 요청 사용 = 재검증 기준이 되는 값을 서버에 보낸다.
    1. HTTP Cache
    2. CORS 요청 가능여부 확인

 

1. 재검증 주기(max-age)

• 캐시된 데이터를 얼마 간격으로 재검증할지 설정한다. 예를 들어, 'max-age=3600'이면 1시간마다 재검증을 수행한다.
• 주기가 너무 길면 오래된 데이터가 제공될 위험이 있고, 너무 짧으면 빈번한 재검증으로 성능이 저하될 수있음.

2. 재검증 기준: 캐시 해놓은 데이터가 오래됐는지 여부를 원본 주인인 웹 서버가 판단하기 위한 기준근거

1. Last-Modifed(수정일 기반 재검증)
2. ETag(고유값 기반 재검증)

 

 

---

 

HTTP Cache 재검증 기준 1. Last-Modified: 수정일(시간) 기반

캐시가 유효한지 여부(=원본이 바뀌었는지 여부)를 시간을 기반으로 판단한다.

→파일이 마지막으로 수정된 시간을 기준으로 재검증한다.

 

• 서버는 'Last-Modified' 헤더를 통해 파일의 마지막 수정 시간을 제공하고 브라우저는 'If-Modified-Since'헤더를 사용하여 서버에 재검증 요청을 보낸다. 서버가 파일이 수정되지 않았음을 확인하면 '304 Not Changed' 상태코드를 반환한다.
• If-Unmodified-Since는 서버에 파일이 수정되지 않았는지 확인하는 요청이다. 서버가 파일이 수정되지 않았다고 판단하면 304 Not Changed를 반환하며, 수정되었다면 412 Precondition Failed를 반환한다.

 

재검증 시 캐시 소유자 (웹브라우저): If-Modified-Since

질문: 바뀐거 있음? (GET, HEAD)

서버 답변:

• ㅇㅇ 바뀜: 200 Resource Cache + 새 응답(새로운 캐시)
• 아니 안바뀜: 304 Not Changed

재검증 시 캐시 소유자 (웹브라우저): If-UnModified-Since

질문: 안바뀜? (POST 서버 상태 변경 Method)

서버 답변:

• ㅇㅇ 안바뀜:304 Not Changed
• ㄴㄴ 바뀜:412 Precondition Failed(조건부 요청에 대한 False 부정 응답)

※ 왜 412 Precondition Failed? 조건부 요청을 했을 때 서버 상태를 변경시킬 수 있으니 일단 막는다. POST는 데이터를 변경할 수 있기 때문에, 리소스의 일관성 유지와 데이터 무결성 보호를 위해서이다. GET은 조회만 하는 것이기 때문에 이러한 상황이 발생하지 않는다.

HTTP Cache 재검증 기준 2. Etag(Entity Tag):고유값(해시) 기반

캐시가 유효한지 여부(=원본이 바뀌었는지 여부)를 고유값(해시, ID)을 기반으로 판단한다.

• Etag는 파일의 고유 해시 값을 기반으로 한 재검증 방식이다. 서버는 파일의 고유 해시 값을 'Etag'헤더로 제공하며, 브라우저는 'If-None-Match'헤더를 사용하여 서버에 재검증 요청을 보낸다. 서버가 해시 값이 변경되지 않았음을 확인하면 '304 Not Changed'를 반환하여, 캐시된 데이터를 계속 사용할 수 있게한다. 만약 해시 값이 변경되었다고 판단하면 새로운 데이터를 전송한다.
• 'If-Match'는 서버에 파일의 고유 해시값이 동일한지를 확인하는 요청이다. 서버가 해시 값이 동일하다고 판단하면 '304 Not Changed'를 반환하고, 다를 경우 '412 Precondition Faild'를 반환한다.

재검증 시 캐시 소유자 (웹 브라우저): If-None-Match

질문: 달라? = 바뀌었어?

서버 답변:

• ㅇㅇ바뀜:200 Resource Cache + 새 응답(새로운 캐시)
• ㄴㄴ 안바뀌었어:304 Not Changed(GET, HEAD)
• + 412 Precondition Failed (POST 서버 상태 변경 Method)

재검증 시 캐시 소유자 (웹 브라우저): If-Match

질문: 같아? = 안바뀌었어?

서버 답변:

• ㅇㅇ 안바뀜:304 Not Changed
• ㄴㄴ 바뀜: 412 Precondition Failed (조건부 요청에 대한 False 부정 응답)

웹 서버가 Etag 헤더를 보내줬다면, 재검증 시 If-None-Match 헤더 혹은 If-Match 헤더 전달

 

Hash란?

Hash는 객체의 고유성을 나타내는 값이다. 두 객체가 동일한지 비교하려면 모든 필드를 다 비교해야 하지만, 해시값을 생성해서 비교하면 된다.

• 객체의 모든 필드를 합쳐서 해시값을 만든다.
• 예를 들어, A 객체의 해시값이 #Ejioajd3@hd…이고, B 객체의 해시값이 U(hd9as@라면, 이 해시값을 비교해서 두 객체가 동일한지 판단할 수 있다.

고유성 검증을 위한 Hash 활용 예: HMAC

Hash는 데이터의 위변조 여부를 판단하는 데 사용될 수 있다. HMAC(Hash-based Message Authentication Code)을 사용하면 파일이나 (Open)API를 통해 받은 결과값이 변조되었는지 확인할 수 있다.

1. 파일을 다운로드하거나 API 결과를 받을 때, 서버에서 계산된 Hash 값을 함께 받는다.
2. 클라이언트와 서버가 미리 공유한 키값으로 Hash 값을 생성한다.
3. 생성된 Hash 값과 서버에서 받은 Hash 값을 비교한다.
4. 두 값이 같다면, 위조되지 않은 파일이나 API 결과임을 확인할 수 있다.

 

---

ℹ️참고

[ASAC 6기 강의자료]