HTTP 헤더 - 캐시①(캐시와 조건부 요청)

이번 글에서는 캐시와 관련된 해더에 대해 이야기 하겠다.

 

먼저 캐시에 대한 설명을 하자면 다음과 같다.

캐시

• 리소스(데이터)의 복사본을 클라이언트에 저장하는 것
• 리소스는 HTTP 문서, 이미지, 파일, JSON 등이 될 수 있다.
• 유효시간 동안 사용가능하며, 유효시간 만료 시 서버에 새로운 리소스를 요청해야함

 

그렇다면 캐시를 사용하는 이유는 뭘까?

캐시를 사용할 때와 사용하지 않을 때를 비교해보겠다

 

캐시를 사용하지 않을 때

• 데이터 내용이 변경되지 않아도 매번 네트워크를 통해서 리소스를 요청해야 한다
• 인터넷 네트워크는 매우 느리고 비싸다
• 브라우저 로딩 속도가 느리다

 

캐시를 사용할 때

• 캐시 유효시간 동안 네트워크를 사용하지 않아도 된다
• 비싼 네트워크 사용량을 줄일 수 있다
• 브라우저 로딩 속도가 빠르다

 

캐시에는 유효기간이 존재한다

아래와 같이 최초 서버응답시에 HTTP Message 안에 유효기간 정보와 함께 데이터를 받는다.

최초 요청 시 서버응답

 

만약, 캐시 유효기간이 초과됐을 경우

아래와 같은 동작이 실행된다.

• 서버에 데이터 요청을 보낸다
• 새로운 데이터 다운로드
• 새로운 데이터를 캐시에 저장

 

캐시 유효기간이 초과되지 않았을 경우

• 서버에 데이터 요청을 보낸다
• 캐시 데이터 조회(Redirect)

 

근데, 과연 캐시 유효기간이 초과됐다고 해서

무조건 서버에 새로운 데이터를 다운로드 받아야 하는가?

 

만약 유효기간이 초과되었지만 파일 내용은 변경되지 않았다면?

그럴 경우, 파일을 다운로드 받는 것은 불필요한 작업이 될 수 있다

 

그런 경우를 위해 검증헤더와 조건부 요청 헤더를 사용한다

 

검증헤더와 조건부 요청 헤더

 

검증헤더

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

 

조건부헤더

• 검증헤더 사용 시, 조건에 따른 분기를 위해 사용
• if-Modified-Since: Last-Modified 사용
  • 최근 수정일 비교
  • 서버 측 데이터의 최근 수정일이 최신일 경우 True
• if-None-Match: ETag 사용
  • 데이터 버전명(ID) 비교
  • 데이터 버전명(ID)이 일치하지 않을 경우 True
• 조건이 만족하면 200 OK 응답
• 조건이 만족하지 않으면 304 Not Modified 응답

 

검증헤더 및 조건부 헤더 상세설명

1. Last-Modified & if-Modified-Since

• 유효기간은 초과했지만, 데이터 변경 여부를 판단하기 위해 사용
• 날짜 기반의 로직 사용
• 클라이언트 측과 서버 측 데이터의 최근 변경일이 다를 경우, 변경이 발생된 것으로 판단
• 변경 발생 시, 서버로부터 데이터 다운로드
• 1초 단위로만 최근 변경일 저장 가능
• 단, 최근 수정일이 다르지만 데이터가 동일한 경우는 구별할 수 없음

데이터 미변경 예시

• 클라이언트 측과 서버 측 데이터의 최근 변경일 비교
• 클라이언트 측과 서버 측 데이터의 최근 변경일이 동일함을 확인
• 서버에서 304 Not Modified 응답을 보낸다.
• 클라이언트 측의 캐시 데이터 재사용(Redirect)
• 캐시 유효기간 갱신
• 헤더만 전송받음(바디 X)
• 전송용량 0.1MB(헤더 0.1MB, 바디 1.0MB)

 

데이터 변경 예시

• 클라이언트 측과 서버 측 데이터의 최근 변경일 비교
• 클라이언트 측과 서버 측 데이터의 최근 변경일이 다름을 확인
• 새로운 데이터를 받는다
• 새로운 데이터를 캐시에 저장한다
• 바디에 데이터를 담아 다운로드
• 전송용량 1.1MB(헤더 0.1MB, 바디 1.0MB)

 

2. ETag & if-None-Match

• ETag(Entity Tag)
• 헤더에 파일버전을 알 수 있는 고유한 식별자(ETag) 존재
  • 예) "ETag: v1.0" 혹은 "ETag: a2jiodwjekjl3"
• 유효기간은 초과했지만, 데이터 변경 여부를 판단하기 위해 사용
• 클라이언트 측과 서버 측 데이터의 ETag 값이 다를 경우, 변경이 발생된 것으로 판단
• 변경 발생 시, 서버로부터 데이터 다운로드
• Last-Modified와 달리, 최근 수정일이 달라도 동일한 데이터 경우 구별가능
• 캐시 제어 로직을 서버에서 완전히 관리
• 클라이언트는 ETag 값만 전달하면 데이터 변경여부를 알 수 있음

 

데이터 미변경 예시

• 클라이언트 측과 서버 측 데이터의 ETag 비교
• 클라이언트 측과 서버 측 데이터의 ETag가 동일함을 확인
• 동일한 버전의 데이터로 간주
• 서버에서 304 Not Modified 응답을 보낸다.
• 클라이언트 측의 캐시 데이터 재사용(Redirect)
• 캐시 유효기간 갱신
• 헤더만 전송받음(바디 X)
• 전송용량 0.1MB(헤더 0.1MB, 바디 1.0MB)

 

데이터 변경 예시

• 클라이언트 측과 서버 측 데이터의 ETag 비교
• 클라이언트 측과 서버 측 데이터의 ETag가 다름을 확인
• 다른 버전의 데이터로 간주
• 새로운 데이터를 받는다
• 새로운 데이터를 캐시에 저장한다
• 바디에 데이터를 담아 다운로드
• 전송용량 1.1MB(헤더 0.1MB, 바디 1.0MB)

 

정리

검증헤더(Validator)

• ETag -> "데이터 내용이 변경되었는가?" 
• Last-Modified -> "데이터의 최근 수정일이 일치하는가?"

 

조건부 요청 헤더

• If-Match, If-None-Match: ETag 값 사용(Etag 값 비교)
• If-Modified-Since, If-Unmodified-Since: Last-Modified 값 사용(최근 수정일 비교)