HTTP 캐시

1. 개요

**캐시(Cache)**는 데이터를 일시적으로 저장하는 메커니즘으로, 자주 사용되는 데이터를 더 빠르게 접근할 수 있는 위치에 저장하여 성능을 향상시키는 역할을 한다.

이를 통해 동일한 데이터에 대한 반복적인 요청을 처리할 때, 더 빠른 응답을 제공할 수 있다.

HTTP 캐시는 웹 브라우저와 서버 간의 통신에서 HTTP 응답을 캐싱하여, 불필요한 네트워크 비용을 줄임으로써 웹 페이지나 리소스를 더 빠르게 로드할 수 있게 한다.

웹 환경에서는 많은 양과 크기의 데이터를 주고받는다.

그리고 그 중에는 이미지, CSS, JS파일 같이 잘 변하지 않는 데이터들도 포함된다.

이러한 잘 변하지 않는 데이터들의 전달 횟수를 줄여 웹 성능을 최적화 할 수 있다.

1-1. HTTP 캐시를 사용하지 않으면

데이터가 변경되지 않아도 계속 네트워크를 통해서 데이터를 다운로드 받아야 한다.

인터넷 네트워크는 매우 비싸고 느리다.
브라우저 로딩 속도가 느려진다.
좋지 않은(느린) UX(사용자 경험)으로 이어진다.

1-2. HTTP 캐시를 사용하면

캐시 가능한 시간동안 데이터에 대한 네트워크를 사용하지 않아도 된다.

비싼 네트워크 사용량을 줄일 수 있다.
브라우저 로딩 속도가 빨라진다.
좋은(빠른) UX(사용자 경험)으로 이어진다.

2. HTTP 캐시의 동작 방식

HTTP 캐시 헤더를 사용하여 캐싱 동작을 제어할 수 있다.

서버는 캐싱 전략을 이러한 헤더를 통해 정의하여 클라이언트(브라우저 등)에게 전달한다.

HTTP 캐시의 동작 방식은 다음과 같다.

2-1. 첫 번째 요청 시

사용자가 웹 페이지에 처음 접근할 때, 브라우저는 서버에 요청을 보낸다.
서버는 웹 페이지와 필요한 리소스(예: 이미지, CSS 파일 등)를 보내면서, 이 데이터를 얼마나 오랫동안 캐시에 저장할 수 있을지 알려주는 정보 등을 포함한 헤더들을 같이 보낸다. 2-1. 이 정보는 Cache-Control이나 Expires라는 HTTP 헤더에 담겨있다. 2-2. 그 밖에도 캐시 무효화 전략 등 다양한 캐시 옵션들이 헤더에 담겨서 클라이언트로 전달된다.

Cache-Controle(max-age) : 캐시 유효 기간 지정 Expires : 캐시 만료일 지정

2-2. 재요청 시

사용자가 같은 웹 페이지를 다시 방문하면, 브라우저는 먼저 캐시를 확인한다.
캐시된 데이터가 이미 존재한다면 해당 데이터를 불러온다. (캐시 히트, Cache Hit) 2-1. 이러면 서버에 다시 요청을 보낼 필요가 없어서 웹 페이지가 훨씬 빠르게 로드된다.
이 때, 브라우저가 ETag나 Last-Modifted를 통해 서버에게 캐시된 자원이 최신 상태인지(변경되지 않았는지) 확인할 수도 있다.
서버는 해당 헤더들을 사용하여 리소스가 변경되었는지 확인한다.
리소스가 변경되지 않았다면 304 Not Modified와 같은 응답을 내려준다. 5-1. 이러면 브라우저는 캐시된 버전을 그대로 사용하면 된다.

ETag: 리소스가 고유하게 식별될 수 있는 태그를 주고받아, 리소스가 바뀌었는지 확인 Last-Modified: 마지막으로 이 리소스가 수정된 날짜를 확인해서, 그 이후로 변경된 게 있는지 확인

2-3. 캐시 만료 시

캐시가 만료 되었다는 것은 해당 캐시가 최신 상태일 가능성이 높다는 의미다.

따라서 캐시에 저장된 리소스가 최신 상태가 아니거나, 너무 오래돼서 만료되면 브라우저는 새로운 리소스 전달을 요청하거나, 조건부 헤더를 사용하여 다시 서버에 검증을 요청한다.

이렇게 되면 브라우저는 최신 버전의 리소스를 가지고 있을 수 있게 된다.

재검증 요청 조건부 헤더

If-None-Match: 캐시된 리소스의 ETag 값과 서버에 존재하는 리소스의 ETag가 같은지 확인 If-Modified-Since: 캐시된 리소스의 Last-Modified 시점 이후에 서버 리소스가 수정되었는지 확인

3. HTTP 캐시 장단점

3-1. 장점

웹 성능 최적화

자주 사용되는 웹 리소스를 캐싱하여, 웹 페이지 로딩 시간을 단축하고, 사용자 경험을 개선할 수 있다.

네트워크 트래픽 감소

동일한 리소스에 대한 불필요한 네트워크 요청을 줄여, 네트워크 자원을 효율적으로 사용한다.

서버 부하 감소

자주 요청되는 리소스를 캐싱하여, 서버가 반복적으로 동일한 데이터를 처리할 필요가 없어 서버 부하가 줄어든다.

3-2. 단점

데이터 일관성 문제

캐시된 데이터가 오래된 경우, 사용자에게 최신 정보가 제공되지 않을 수 있다.

캐시 관리 복잡성

적절한 캐시 정책을 설정하지 않으면 성능 저하나 데이터 일관성 문제를 초래할 수 있다.

캐시 제어 헤더

1. Cache-Control

1-1. 캐시 저장 범위 설정

public

해당 리소스를 모든 캐시에 저장할 수 있도록 허용 (CDN 등 공유 캐시 포함)
Cache-Control: public

private

해당 리소스를 개인 캐시에만 저장할 수 있음 (브라우저 캐시 등)
Cache-Control: private

1-2. 캐시 유효 시간 설정

max-age

캐시된 리소스가 몇 초 동안 유효한지 설정
Cache-Control: max-age=3600 (1시간 동안 캐시 유효)

s-maxage

공유 캐시(CDN 등)에서 사용할 최대 유효 기간을 설정
Cache-Control: s-maxage=600
max-age보다 우선한다

예를 들어, Cache-Control 값을 s-maxage=31536000, max-age=0 과 같이 설정하면 CDN에서는 1년동안 캐시되지만 브라우저에서는 매번 재검증 요청을 보내도록 설정할 수 있습니다.

1-3. 캐시 무효화 설정

캐시 무효화(Cache Busting)는 캐시에 저장된 데이터가 더 이상 유효하지 않을 때, 이를 인식하고 무효화(캐시 데이터를 제거하거나 갱신)하는 작업이다.

기본적으로 브라우저는 캐시 유효 기간이 끝나야 캐시 유효성 검증을 서버에게 요청한다.

따라서 캐시 유효 기간을 과도하게 길게 설정해버려서 리소스의 업데이트를 제 때 못해주는 상황 등을 방지하기 위해 캐시 무효화 전략을 사용한다.

no-cache

캐시된 리소스를 사용하기 전에 서버에 유효성 검사를 요청
Cache-Control: max-age=0과 동일한 의미
Cache-Control: no-cache

캐시를 사용하지 않는 것이 아니라 캐시를 사용하기 전에 서버로부터 검증 받고 사용하는 전략이다.

no-store

리소스를 캐시에 저장하지 않음
보안이 중요한 데이터에 주로 사용
Cache-Control: no-store

must-revalidate

캐시된 리소스가 만료되면, 반드시 Origin 서버에 재검증 요청
Cache-Control: must-revalidate
스펙상 반드시 프록시 서버가 아닌 원 서버를 통해 재검증 받아야 한다.
원 서버에 접근할 수 없을 시 504 Gateway Timeout 응답을 보내야 한다.

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

HTTP에서는 캐시된 리소스가 여전히 유효한지 확인하기 위해 검증 헤더와 조건부 요청 헤더를 사용한다.

2-1. 검증 헤더

서버가 클라이언트에게 전달하는 정보로, HTTP 응답 헤더에 포함된다.

Last-Modified

리소스가 마지막으로 수정된 시각을 나타낸다. 이를 통해 클라이언트에 캐시된 리소스와 비교하여 서버의 리소스가 수정되었는 지 알 수 있다. Last-Modified: Thu, 04 Jun 2020 07:19:24 GMT

ETag

서버가 리소스의 고유한 버전을 식별하기 위해 생성하는 식별자로, 리소스가 변경될 때마다 달라진다. ETag: "v1.0" ETag: "asid93jkrh2l..."

2-2. 조건부 요청 헤더

클라이언트가 서버로 요청을 보낼 때 현재 캐시된 리소스 정보를 함께 보낸다.

조건을 만족할 경우 새로운 리소스를 받지 않고 캐시된 리소스를 사용함으로써 네트워크 비용을 절약할 수 있다.

If-Match, If-None-Match: ETag 사용
If-Modified-Since, If-Unmodified-Since: Last-Modified 사용

조건부 요청 시, 리소스의 캐시 유효기간이 만료되어도 서버의 데이터가 갱신되지 않은 경우

304 Not Modified + 헤더 메타 정보만 응답된다. (바디X)
클라이언트는 서버가 보낸 응답 헤더 정보로 캐시의 메타 정보를 갱신
클라이언트는 캐시에 저장되어 있는 데이터 재활용

결과적으로 네트워크 다운로드가 발생하지만 용량이 적은 헤더 정보만 다운로드하면 된다.

If-Modified-Since

If-Modified-Since = 이후에 데이터가 수정되었는지 질의

If-Modified-Since: Wed, 21 Oct 2023 07:28:00 GMT

클라이언트가 이전에 서버로부터 받은 Last-Modified값을 전달했을 때,

서버는 이 헤더를 보고 리소스가 그 이후로 변경되지 않았다면 304 Not Modified 상태 코드와 함께 응답한다. (리소스 전송X)

리소스가 수정된 경우 리소스 전송

2-3. Last-Modified / If-Modified-Since 예시

데이터 미변경 예시

• 캐시: 2020년 11월 10일 10:00:00 vs 서버: 2020년 11월 10일 10:00:00
• 304 Not Modified, 헤더 데이터만 전송(BODY 미포함)
• 전송 용량 0.1M (헤더 0.1M)

데이터 변경 예시

• 캐시: 2020년 11월 10일 10:00:00 vs 서버: 2020년 11월 10일 11:00:00
• 200 OK, 모든 데이터 전송(BODY 포함)
• 전송 용량 1.1M (헤더 0.1M, 바디 1.0M)

Last-Modified, If-Modified-Since 단점

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

2-4. ETag / If-None-Match 예시

ETag(Entity Tag) = 캐시용 데이터에 임의의 고유한 버전 이름을 달아둠

데이터가 변경되면 이 이름을 바꾸어서 변경함(Hash를 다시 생성) 예) ETag: "v1.0" -> ETag: "a2jiodwjekjl3"

서버 입장에서 단순하게 ETag를 보고 같으면 304 Not Modified, 다르면 리소스 전송!

예) 
ETag: "aaaaa" == ETag: "aaaaa" -> 304 Not Modified (헤더)
ETag: "v1.0" != ETag: "a2jiodwjekjl3" -> 200 OK 리소스 전송 (헤더 + 바디)

ETag, If-None-Match 정리

캐시 제어 로직을 서버에서 완전히 관리
클라이언트는 단순히 이 값을 서버에 제공(클라이언트는 캐시 메커니즘을 모름)
- 이로인해 다음과 같은 경우도 가능함
- 1. 서버는 배타 오픈 기간인 3일 동안 파일이 변경되어도 ETag를 동일하게 유지
- 1. 애플리케이션 배포 주기에 맞추어 ETag 모두 갱신

2-5. If-Unmodified-Since / If-Match

If-Unmodified-Since와 If-Match는 각각 If-Modified_Since와 If-None-Match와 반대라고 생각하면 된다.

If-Unmodified-Since

서버는 리소스가 수정되지 않은 경우에만 요청받은 리소스를 전송
리소스가 지정된 날짜 이후에 수정된 경우 412 Precondition Failed 응답
If-Unmodified-Since 참조

If-Match

서버는 요청받은 리소스에 주어진 값과 일치하는 ETag가 있는 경우에만 리소스 전송
일치하는 Etag가 없는 경우에는 412 Precondition Failed 응답
If-Match 참조

References

MDN web docs, 『HTTP 캐싱』, mozilla 인파, 『웹 브라우저의 Cache 전략 & 헤더 다루기』, tistory 박서진· 토스 Head of Frontend, 웹 서비스 캐시 똑똑하게 다루기』, tosstech

Files

캐시.md

Latest commit

History