[HTTP] HTTP 웹 기본 지식 8) HTTP 헤더 2 - 캐시와 조건부 요청

HTTP 웹 기본 지식

Session 8 HTTP 헤더 2 - 캐시와 조건부 요청

1. 캐시 기본 동작

1) 캐시가 없을 때

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

▶ 네트워크는 비싸고 느림, 브라우저 로딩 속도도 느림 → 느린 사용자 경험

첫 요청에서 1.1m 용량의 응답을 받게 됨 똑같은 요청을 재요청했을 때 1.1m 용량의 응답을 다시 받게됨

 

2) 캐시 적용

요청이 들어오면 1.1m 용량의 응답을 보내면서 캐시 유효시간을 지정

브라우저 캐시에 60초간 유효한 상태로 응답결과 저장

 

2-1) 두 번째 요청

두 번째 재요청 시 캐시 유효시간을 검증하고 유효하다면 캐시에서 직접 조회해 브라우저에서 결과 로딩

▶ 캐시 덕분에 유효시간 동안은 네트워크를 사용하지 않아도 됨

▶ 비싼 네트워크 사용량 줄임, 브라우저 로딩 속도 빠름 → 빠른 사용자 경험

 

2-2) 세 번째 요청

세 번째 재요청 시 캐시 유효시간을 검증하고 유효하지 않다면 서버에 요청 전송

1.1m 용량의 응답을 보내면서 캐시 유효시간을 지정

브라우저 캐시에 60초간 유효한 상태로 응답결과 저장

▶ 캐시 유효 시간이 초과하면 서버를 통해 데이터를 다시 조회하고 캐시 갱신, 네트워크 다운로드 발생

▶ 유효 시간이 초과하면 같은 데이터를 다시 다운로드? → 다음 강의에서 해결

---

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

1) 캐시 시간 초과 두 가지 상황

캐시 만료 후에도 데이터 변경을 하지 않는 경우 ▶ 캐시 재사용

단 클라이언트의 데이터와 서버 데이터가 같다는 사실을 확인해야 함

 

2) 검증 헤더 추가

요청이 들어오면 1.1m 용량의 응답을 보내면서 캐시 유효시간과 데이터가 마지막에 수정된 시간 같이 전송

브라우저 캐시에 60초간 유효한 상태, 데이터 최종 수정일을 포함한 결과 저장

 

두 번째 재요청 시 캐시 유효시간을 검증하고 유효하지 않다면 재요청을 서버에 전송하면서

캐시가 가지고 있는 데이터 최종 수정일을 같이 전송

서버에서 해당 데이터의 최종 수정일을 확인하고 수정 사항이 없다면

 

데이터 없이 0.1m 용량의 헤더만 전송

▶ 304 Not Modified 상태코드 전송, HTTP body 없음

응답 결과를 재사용하면서 헤더 데이터를 60초간 유효한 상태로 갱신

웹브라우저는 캐시에서 조회해 로딩

 

3) 검증 헤더와 조건부 요청 정리 

캐시 유효 시간이 초과해도 서버의 데이터가 갱신되지 않았으면 304 상태코드와 헤더만 전송

클라이언트는 서버가 보낸 응답 헤더 정보로 캐시 메타 정보 갱신

클라이언트는 캐시에 저장되어 있는 데이터 재활용

▶ 네트워크 다운로드가 발생하지만 용략이 적은 헤더 정보만 다운로드해 매우 실용적인 해결책

---

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

1) 검증 헤더

캐시 데이터와 서버 데이터가 같은지 검증하는 데이터

Last-Modified, ETag

 

2) 조건부 요청 헤더

검증 헤더로 조건에 따른 분기

if-Modified-Since : Last-Modified 사용

if-None-Match : ETag 사용

조건이 만족하면 200 ok, 조건이 만족하지 않으면 304 Not Modified 

 

3) If-Modified-Since 이후 데이터 수정?

-데이터 미변경

캐시 10월 31일 12:00:00 서버 10월 31일 12:00:00

304 Not Modified + 헤더 데이터

전송용량 0.1M

 

-데이터 변경

캐시 10월 31일 12:00:00 서버 10월 31일 13:00:00

200 ok + 모든 데이터(헤더+바디)

전송용량 1.1M(헤더 0.1M+바디 1M)

 

4) Last-Modified, If-Modified-Since 단점

날짜 기반 로직을 사용, 1초 미만 단위로 캐시 조정 불가능

날짜만 수정되고 콘텐츠 수정되지 않았어도 날짜가 다르기 때문에 모든 데이터 재다운로드 필요

▶ 위의 상황으로 인한 별도의 캐시 로직을 관리하고 싶은 경우(스페이스나 주석처럼 크게 영향이 없는 변경은 캐시 유지) ETag 사용

 

5) ETag, If-None-Match

ETag : 캐시용 데이터에 임의의 고유 버전 이름을 추가

데이터가 변경되면 이 이름을 변경

ETag를 보내서 같으면 유지, 다르면 다시 다운로드

 

5-1) ETag 검증헤더 추가

요청이 들어오면 1.1m 용량의 응답을 보내면서 캐시 유효시간과 ETag 같이 전송

브라우저 캐시에 60초간 유효한 상태, ETag 포함한 결과 저장

두 번째 재요청 시 캐시 유효시간을 검증하고 유효하지 않다면 재요청을 서버에 전송하면서

캐시가 가지고 있는 ETag 같이 전송

서버에서 해당 데이터의 ETag 확인하고 수정 사항이 없다면 데이터 없이 0.1m 용량의 헤더만 전송

▶ 304 Not Modified 상태코드 전송, HTTP body 없음

응답 결과를 재사용하면서 헤더 데이터를 60초간 유효한 상태로 갱신

웹브라우저는 캐시에서 조회해 로딩

 

5-2) ETag, If-None-Match 정리

▶ 예) 서버는 배타 오픈 기간 3일 동안 파일 변경되어도 ETag유지

ETag만 보내서 같으면 재사용, 다르면 재다운로드

캐시 제어 로직을 서버에서 완전히 관리

클라이언트는 단순히 이 값을 서버에 제공만 함(클라이언트는 캐시 메커니즘을 모름)

---

4. 캐시와 조건부 요청 헤더

1) 캐시 제어 헤더

Cache-Control : 캐시 제어

Pragma : 캐시 제어(HTTP 1.0 하위 호환)

Expires : 캐시 유효기간(하위호환)

 

2) Cache-Control 

캐시 지시어

- Cache-Control: max-age

캐시 유효 시간, 초단위

- Cache-Control: no-cache

데이터는 캐시해도 되지만, 항상 origin 서버에 검증하고 사용

- Cache-Control: no-store

데이터에 민감한 정보가 있으므로 저장하면 안 됨 메모리에서 사용하고 최대한 빨리 삭제

 

3) Expires

캐시 만료일을 정확한 날짜로 지정

HTTP 1.0부터 사용, 지금은 더 유연한 Cache-Control: max-age 권장

Cache-Control: max-age와 같이 사용 시 무시됨

---

5. 프록시 캐시

1) 원(origin) 서버 직접 접근

미국에 있는 origin 서버를 한국에서 직접 접근할 때 대략 0.5초가 걸린다

프록시 캐시를 사용하면 접근 시간을 줄일 수 있음

 

2) 프록시 캐시 도입

미국에 있는 origin 서버를 한국에서 직접 접근하면 한국에 있는 프록시 캐시 서버로 접근하게 조작

프록시 캐시를 사용하면 0.1초로 접근 시간을 단축 할 수 있다.

public 캐시 : 프록시 캐시 서버에 있는 캐시

private 캐시 : 개인 웹 브라우저에서 사용되는 캐시

 

3) Cache-Control 

- Cache-Control: public

응답이 public 캐시에 저장가능함

- Cache-Control: private

응답이 해당 사용자만을 위한 것, 기본값

- Cache-Control: s-maxage

프록시 캐시에만 적용되는 max-age

- Age: 60

오리진 서버에서 응답 후 프록시 캐시 내에 머문 시간

---

6. 캐시 무효화

1) 확실한 캐시 무효화 응답

캐시를 적용하지 않아도 웹 브라우저에서 임의로 캐시 하는 경우가 있어 확실하게 캐시를 미적용하기 위한 방법

Cache-Control: no-cache, no-store, must-revalidate

Pragma: no-cache

 

2) Cache-Control 확실한 캐시 무효화

- Cache-Control: no-cache

데이터는 캐시해도 되지만, 항상 origin 서버에 검증하고 사용

- Cache-Control: no-store

데이터에 민감한 정보가 있으므로 저장하면 안 됨 메모리에서 사용하고 최대한 빨리 삭제

- Cache-Control: must-revalidate

캐시 만료 후 최초 조회 시 원 서버에 검증 필요

원 서버 접근 실패 시 반드시 오류 발생 ▶ 504

- Pragma: no-cache

하위 호환으로 사용

 

3) Cache-Control: no-cache 동작

캐시가 유효해도 원 서버에 검증 필수!

 

검증 중 원서버와 단절되면 오류보단 예전 데이터로 응답함

 

4) Cache-Control: must-revalidate 동작

검증 중 원서버와 단절되면 504 오류로 응답함