캐시와 조건부 요청의 기본 동작 이해
1. 캐시 미적용
서버에 star 이미지를 요청하고, 결과로 HTTP 헤더 0.1M + 바디 1.0M 총 1.1M 이미지를 받는다.
여기서 캐시를 사용하지 않으면, 새로고침 하거나 브라우저를 닫고 다시 요청을 한다면 똑같이 1.1 M 이미지를 받게 된다.
이 경우, 데이터가 변경되지 않아도 불필요한 네트워크 사용이 발생하고, 사용자는 느린 로딩 속도를 경험하게 된다.
2. 캐시 적용
서버가 응답에 캐시 설정을 포함하여 전송
클라이언트 브라우저의 캐시 저장소에 해당 응답 데이터가 일정 시간(위 사진에서 60초) 동안 저장
클라이언트가 60초 이내에 같은 이미지를 요청할 경우 캐시에서 데이터가 제공되어 네트워크를 사용하지 않고 빠르게 로딩된다.
3. 캐시 유효 시간 초과
캐시 시간이 초과되면?
- 유효 시간이 초과하면 서버를 통해 데이터를 다시 조회하고 캐시를 갱신한다.
- 이때 다시 네트워크 다운로드가 발생한다.
서버에 다시 요청을 할 때, 두 가지 상황이 나타난다.
- 서버에서 기존 데이터를 변경
- 서버에서 기존 데이터를 변경하지 않음
캐시가 만료되었지만 서버의 데이터가 변경되지 않았다면, 서버가 데이터를 다시 전송하지 않고 클라이언트가 기존 캐시를 재사용하는 것이 더 효율적
단, 클라이언트의 데이터와 서버의 데이터가 같다는 사실을 확인할 수 있는 방법이 필요하다!
검증 헤더
HTTP 헤더에 데이터가 마지막에 수정된 시간인 Last-Modified 라는 검증 헤더를 추가한다.
캐시 저장소에 헤더에 있던 데이터의 최종 수정일 정보도 함께 저장한다.
캐시 유효 시간이 초과한 후, 클라이언트가 서버에 요청을 보낼 때
if-modified-since 라는 조건부 요청을 포함해 요청을 보낸다.
서버의 데이터와 클라이언트의 데이터의 최종 수정일이 같다.
서버는 데이터가 변경되지 않았음을 확인하고 304 Not Modified와 함께 HTTP 헤더만 보낸다. (HTTP Body 보내지 않음)
클라이언트는 유효 시간이 초과된 캐시 저장소의 데이터를 사용하고, 헤더 데이터를 갱신한다.
검증헤더
- 캐시 데이터와 서버 데이터가 같은지 검증하는 데이터
- Last-Modified: 리소스가 마지막으로 수정된 날짜와 시간
- ETag: 리소스의 특정 버전을 식별하는 고유한 태그 값
조건부 요청 헤더
조건부 요청 헤더 :
HTTP 요청에서 특정 조건을 기반으로 서버에 요청을 보내도록 하는 헤더
- 클라이언트가 보낸 조건을 서버가 확인하여, 해당 조건을 만족할 때만 데이터를 전송하거나 요청을 처리
If-Modified-Since,If-Unmodified Since:Last-Modified사용If-None-Match,If-Match:ETag사용If-Range
조건부 요청을 왜 쓸까?
예를 들어, 웹 사이트에서 이미지를 받았다고 해보자.
이 이미지를 자주 열어본다면, 매번 이미지를 새로 받아올 필요가 없을 것이다.
이전에 받은 이미지가 여전히 최신이라면, 전체 데이터를 다시 다운로드 받지 않고 캐시된 이미지를 그대로 쓰는 것이 더 효율적이다.
조건부 요청은 이렇게 중복된 데이터를 다시 전송하지 않도록 하여 네트워크 사용량을 줄이고, 로딩 시간을 단축하는 데 도움을 준다.
조건부 요청 헤더 종류
1. If-Modified-Since
- 클라이언트가
If-Modified-Since헤더에 마지막으로 받은 리소스의 날짜를 넣어 서버에 요청을 보내면, 서버는 이 날짜 이후에 리소스가 변경되었는지 확인한다. - 응답 결과
| 리소스 변경되지 않음 | 304 Not Modified , 헤더 데이터만 전송 (Body 미포함). 클라이언트가 캐시된 데이터 그대로 사용 |
|---|---|
| 리소스 변경됨 | 서버가 새 데이터(Body 포함)를 보내면서 200 OK 응답 보냄 |
2. If-Unmodified Since
- If-Modified-Since와 반대로, 리소스가 변경되지 않았는지를 확인
- 주로 PUT, DELETE 요청에 사용
- 클라이언트가 지정한 날짜 이후로 리소스가 수정되지 않았다면 요청을 처리
- 응답 결과
| 리소스 변경되지 않음 | 서버는 요청을 처리 |
|---|---|
| 리소스 변경됨 | 412 Precondition Failed 오류 응답 |
3. If-Match
- ETag 기반으로 작동. 클라이언트의 ETag와 현재 ETag가 일치할 때만 요청이 진행됨
- 주로 PUT, DELETE 요청에 사용
| ETag 일치 | 서버는 요청을 처리 |
|---|---|
| ETag 불일치 | 412 Precondition Failed 응답 |
4. If-None-Match
- 현재 클라이언트의 ETag와 서버의 ETag가 다를 때만 요청을 처리(최신 데이터 전송)
- 동작 방식 : ETag가 다를 경우에만 전체 리소스를 요청
| ETag 일치 | 304 Not Modified. 서버는 헤더만 전송하고 클라이언트는 캐시된 데이터 사용 |
|---|---|
| ETag 불일치 | 서버가 새 데이터를 보내면서 200 OK로 응답 |
5. If-Range
- 클라이언트가 리소스의 특정 범위를 새로 받고 싶을 때 사용
- 클라이언트가 이미 받은 리소스의 일부가 최신 상태인지 확인하고, 변경되지 않았다면 요청한 범위에 해당하는 데이터만 다시 받도록 도와줌.
- 리소스가 변경된 경우, 전체 데이터를 새로 받음
| 리소스 변경되지 않음 | 206 Partial Content, 요청한 범위의 데이터만 반환 |
|---|---|
| 리소스 변경됨 | 200 OK, 전체 리소스 반환 |
정리
| 조건부 요청 헤더 | 정의 |
|---|---|
| If-Modified-Since | 클라이언트가 가진 리소스의 최종 수정 날짜 이후로 변경되었는지 확인하여 변경되지 않았다면 캐시된 데이터를 사용 |
| If-Unmodified-Since | 클라이언트가 지정한 날짜 이후로 리소스가 수정되지 않은 경우에만 요청을 처리 |
| If-Match | 클라이언트의 ETag와 서버의 ETag가 일치할 때만 요청을 처리하여 안전한 리소스 수정 또는 삭제를 가능하게 함 |
| If-None-Match | 클라이언트의 ETag와 서버의 ETag가 다를 때만 요청을 처리하여 캐시된 데이터가 최신인지 확인하고 필요 시 새 데이터 가져옴 |
| If-Range | 리소스가 변경되지 않았다면 클라이어트가 요청한 데이터 범위만 반환하고, 변경된 경우 전체 리소스를 다시 전송 |
