본문 바로가기
HTTP

캐시와 검증 헤더

by o3oppp 2024. 2. 21.

캐시

자주 사용하는 데이터나 값을 미리 복사해 놓는 임시 장소로 저장 공간이 작고 비용이 비싼 대신 빠른 성능을 제공

  • 캐시가 없는 경우
    • 데이터가 변경되지 않아도 계속 네트워크를 통해서 데이터를 다운로드 받아야 함
    • 인터넷 네트워크는 매우 느리고 비쌈
    • 브라우저 로딩 속도가 느림
    • 느린 사용자 경험을 줌
  • 캐시가 있는 경우
    • 캐시 가능 시간동안 네트워크를 사용하지 않아도 됨
    • 비싼 네트워크 사용량을 줄일 수 있음
    • 브라우저 로딩 속도가 매우 빠름
    • 빠른 사용자 경험을 줌
  • 캐시 시간 초과
    • cache-control: max-age=캐시 유효 시간(초) 로 표현
    • 캐시 유효 시간이 초과하면 서버를 통해 데이터를 다시 조회하고 캐시를 갱신
    • 다시 네트워크 다운로드 발생
  • 캐시 유효 시간 초과
    • 캐시 유효 시간이 초과 후 서버에 다시 요청 시 다음 2가지 상황이 나타남
    1. 서버에서 기존 데이터를 변경
    2. 서버에서 기존 데이터를 변경하지 않음
    • 캐시 만료후에도 서버에서 데이터를 변경하지 않는 경우 데이터를 캐시에서 재사용 가능
    • 단, 클라이언트의 데이터와 서버의 데이터가 같다는 사실을 확인할 수 있는 방법이 필요

검증 헤더와 조건부 요청

클라이언트의 데이터와 서버의 데이터가 같다는 사실을 확인할 수 있는 방법으로 조건부 요청 헤더와 같이 사용

  • 검증 헤더 : 캐시 데이터와 서버 데이터가 같은지 검증하는 데이터
    • Last-Modifined, ETag
  • 조건부 요청 헤더 : 검증 헤더로 조건에 따른 분기
    • if-modified-since
      • 조건 만족(캐시에 있던 데이터와 서버에 요청한 데이터가 다름)시 200 OK
      • 조건 불만족(캐시에 있던 데이터와 서버에 요청한 데이터가 같음)시 304 Not Modified

 

 

 

 

  • 검증 헤더의 값과 조건부 요청의 값의 조합으로 서버에 요청한 데이터가 갱신되지 않았으면 서버는 헤더만 전송
    • 캐시에 원하는 데이터가 있으므로 HTTP Body를 전송하지 않음
    • HTTP Body를 전송하지 않음으로써 결과적으로 네트워크 다운로드가 발생하지만 용량이 적은 헤더 정보만 다운로드
    • 네트워크 부하 줄어듬
    • 클라이언트는 캐시에 저장되어 있는 데이터 재활용 가능
    • 매우 실용적

단점

  • 1초 미만 단위로 캐시 조정이 불가능
  • 날짜 기반의 로직 사용으로 같은 데이터를 수정해서 데이터 결과가 같지만 날짜가 다른 경우 존재
  • 최종적으로 데이터는 변경되지 않았으나 날짜 변경으로 인해 전체 데이터 다운로드
  • 이를 극복하기 위해 ETag 사용

ETag

캐시용 데이터에 임의의 고유한 버전 이름을 달아두는 것

  • ex. ETag: "v1.0", ETag: "abc" 등
  • 데이터 변경 시 이 이름을 바꾸어서 변경(Hash를 다시 생성)
  • 단순하게 ETag만 보내서 같으면 유지, 다르면 다시 받음
  • 캐시 제어 로직을 서버에서 완전히 관리

 

 

 

 


프록시 캐시


클라이언트와 서버 사이에 대리로 통신을 수행하는 중계 기능을 가진 서버

  • 외국 영상을 보려면 오래 걸리니, 한국에 프록시 서버를 두어 한국인들은 프록시 서버에서 데이터를 다운받음

'HTTP' 카테고리의 다른 글

상태코드  (0) 2024.02.12
메서드의 속성  (0) 2024.02.06
메서드 종류  (0) 2024.02.06
HTTP 메시지 구조  (0) 2024.02.05
HTTP  (0) 2024.02.05