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

웅평·2023년 4월 5일

http 네트워크

네트워크

목록 보기

17/21

캐시 기본 동작

캐시가 없을 때

기본 동작
캐시가 없을 때 첫 번째 요청

클라이언트에서 star.jpg 이미지를 요청한다.
서버에서는 해당 이미지가 있으면 응답을 줘야하는데, 이미지의 HTTP 헤더+바디를 합쳐 대략 1.1M정도 용량의 데이터를 응답한다.
클라이언트에서는 해당 이미지를 응답 받아 사용한다.

캐시가 없을 때 두 번째 요청

클라이언트에서는 star.jpg 이미지를 다시 한 번 요청한다.
서버에서는 동일한 이미지를 다시 1.1M정도 용량의 데이터를 응답해준다.
클라이언트에서는 해당 이미지를 응답 받아 사용한다.

특징

데이터가 변경되지 않아도 계속 네트워크를 통해서 데이터를 다운받아야 한다
인터넷 네트워크는 매우 느리고 비싸다
브라우저 로딩 속도가 느리다

캐시가 있다면

기본 동작

캐시를 적용한 첫 번째 요청

헤더에 cache-controll 속성을 넣어주어 캐시가 유효한 시간을 넣어준다. 위에서는 60초로 설정해 60초 동안은 해당 캐시가 유효하다는 의미다.
그럼 브라우저 캐시에 응답 결과를 저장하며 60초간 유효하다.

캐시를 적용한 두 번째 요청

두 번째 요청할때는 우선 캐시를 조회한다.
캐시가 존재하고 아직 60초 이내이기에 유효한 캐시가 있어서 해당 캐시에서 자료를 가져온다.
캐시가 초과(만료)되었다면?
⇒ =다시 서버에 요청을하고 60초간 유효한 star.jpg 이미지를 다운받는다
⇒ 캐시 유효 시간이 초과하면 서버를 통해 데이터를 다시 조회하고 캐시를 갱신
⇒ 이때 다시 네트워크 다운로드가 발생한다.

특징

캐시가 있다면 브라우저 데이터베이스에 캐시를 저장하고 처음 요청 때만 다운 받고 그 다음 부터 변경이 없으면 그 캐시 만료 전까지 사용
캐시 가능 시간동안 네트워크를 사용하지 않아도 된다
네트워크 사용량 줄어든다
브라우저 로딩속도 향상

검증 헤더와 조건부 요청

검증 헤더와 조건부 요청1

캐시 유효 시간이 초과한 경우

캐시 만료후에도 서버에서 데이터를 변경하지 않음
데이터를 전송하는 대신에 저장해 두었던 캐시를 재사용 할 수 있다.
단 클라이언트의 데이터와 서버의 데이터가 같다는 사실을 확인할 수 있는 방법 필요

그래서 검증 헤더가 들어가게 된다.

검증 헤더 추가 첫 번째 요청

데이터가 마지막으로 수정된 시간정보를 헤더에 작성해준다
응답 결과를 캐시에 저장할 때 데이터 최종 수정일도 저장된다.

검증 헤더 추가 두 번째 요청(캐시 시간 초과)

캐시 시간이 초과해서 다시 요청을 해야하는데, 캐시에 최종 수정일 정보(Last-Modified)가 있다면 요청 헤더에 if-modified-since에 해당 날짜를 담아서 서버에 보낸다.
서버의 해당 자료의 최종 수정일과 비교해서 데이터가 수정이 안되었을 경우 응답 메세지에 이를 담아서 알려준다.

HTTP 바디가 없이 304 Not Modified를 보내준다
그래서 전송 데이터는 바디가 빠졌기에 헤더만 포함된 0.1M만 전송된다.

정리

캐시 유효 시간이 초과해도, 서버의 데이터가 갱신되지 않으면 304 Not Modified + 헤더 메타 정보만 응답(바디X)
클라이언트는 서버가 보낸 응답 헤더 정보로 캐시의 메타 정보를 갱신
클라이언트는 캐시에 저장되어 있는 데이터 재활용
결과적으로 네트워크 다운로드가 발생하지만 용량이 적은 헤더 정보만 다운로드
매우 실용적인 해결책

검증 헤더와 조건부 요청2

검증 헤더

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

조건부 요청 헤더

검증 헤더로 조건에 따른 분기
If-Modified-Since: Last-Modified 사용
If-None-Match: ETage 사용
조건이 만족하면 200 OK
조건이 만족하지 않으면 304 Modified

예시
If-Modified-Since이후 데이터가 수정이 되었으면?

데이터 미변경시

캐시(클라이언트)와 서버 Last-Modified가 같다면
304 Not Modified, 헤더 데이터만 전송
BODY 미포함

데이터 변경시

캐시와 서버 의 Last-Modified가 다르다면
200 OK, 모든 데이터 전송(BODY 포함)

If-Modified-Since, Last-Modified 단점

1초 미만 단위로 캐시 조정이 불가능
날짜 기반의 로직 사용
데이터를 수정해서 날짜가 다르지만 같은 데이터를 수정해서 데이터 결과가 똑같은 경우 다시 다운로드 한다
서버에서 별도의 캐시 로직을 관리하고 싶은 경우
- ETag로 해결

ETag, If-None-Match

서버에서 완전히 캐시를 컨트롤하고 싶은 경우 ETag 를 사용하면 된다.

ETag(Entity Tag)
캐시용 데이터에 임의의 고유한 버전 이름을 달아둠
- 예) ETag: "v1.0", ETag: "a2jiodwjekjl3"
데이터가 변경되면 이 이름을 바꾸어서 변경함(Hash를 다시 생성)
- 예) ETag: "aaaaa" -> ETag: "bbbbb"
ETag만 보내서 같으면 유지, 다르면 다시 받기

ETag를 이용한 요청 과정

ETag를 사용한 첫 번째 요청

헤더에 ETag 를 작성해서 응답해준다.
클라이언트의 캐시에선 ETag 값을 저장한다.

ETag를 사용한 두 번째 요청
캐시시간이 초과되서 다시 요청을 해야하는 경우이다.
이때 If-None-Match를 요청 헤더에 작성해서 보낸다
서버에서 데이터가 변경되지 않았을 경우 ETag는 동일하다. 그래서 If-None-Match는 실패다.
이 경우 서버에서는 304 Not Modified를 응답하며 이때 역시 HTTP Body는 없다.
브라우저 캐시에서는 응답 결과를 재사용하고 헤더 데이터를 갱신한다.

ETag 정리

ETag만 서버에 보내면 같으면 유지 다르면 다시 받기
캐시 제어 로직을 서버에서 완전히 관리
클라이언트는 단순히 이 값을 서버에 제공(클라이언트는 캐시 메커니즘을 모른다)

캐시와 조건부 요청 헤더

캐시 제어 헤더

• Cache-Control: 캐시 제어
• Pragma: 캐시 제어(하위 호환)
• Expires: 캐시 유효 기간(하위 호환)

Cache-Control

캐시 지시어(directives)
Cache-Control: max-age

캐시 유효 시간, 초 단위
보통 길게 잡는다

Cache-Control: no-cache

데이터는 캐시해도 되지만, 항상 원(origin) 서버에 검증하고 사용
데이터는 캐시해도 되지만 사용하기 전에 검증헤더와 조건부 요청을 하고 사용

Cache-Control: no-store

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

Pragma

캐시 제어(하위 호환)

no-cache
HTTP 1.0 하위 호환
거의 사용하지 않음

Expires

캐시 만료일 지정(하위 호환)

캐시 만료일을 정확한 날짜로 지정
지금은 더 유연한 Cache-Control :max-age 권장
Cache-Control:max-age와 함께 사용하면 Expires 무시됨

프록시 캐시

예시

한국에있는 클라이언트에서 별 이미지가 필요한상황인데 해당 이미지의 원서버가 미국에 있다고 가정해보자. 한국에서 미국까지 직접 접근하여 이미지를 가져오는데 0.5초가량 걸린다고하면 여러 클라이언트는 모두 0.5초 가량을 기다려야 해당 이미지를 받을 수 있다. 이것도 매우 긍정적인 상황이고 실제로는 더 많은 시간이 걸릴 수 있다. 그래서 이를 해결하기 위해 프록시 캐시가 도입되었다.

한국에 프록시 캐시서버를 두고 한국의 클라이언트는 프록시 캐시서버를 통해 자료를 가져오도록 한다.
여러 사람이 찾은 자료일수록 이미 캐시에 등록되어있기에 빠른 속도로 자료를 가져올 수 있다.
- 같은 국내에 있기에 원서버에 접근하는것보다 훨씬 빠른 속도에 자료를 가져올 수 있다.
- 예) 유튜브에서 고용량의 영상도 빨리 볼 수 있는 이유.
클라이언트에서 사용되고 저장되는 캐시를 private캐시라 하고 프록시 캐시서버의 캐시를 public 캐시라 한다.

Cachae-Control

캐시 지시어(directives) - 기타
Cachae-Control: public

응답이 public 캐시에 저장되어도 됨

Cachae-Control: private

응답이 해당 사용자만을 위한 것임
private 캐시에 저장해야함

Cachae-Control: max-age

프록시 캐시에만 적용

Age: 60 (HTTP 헤더)

원서버에서 응답 후 프록시 캐시 내에 머문 시간

캐시 무효화

Cachae-Control: no-cache, cno-store, must-revalidate
Pragma: no-cache
를 다 넣어야 캐시가 무효화 된다

캐시 지시어(directives) - 확실한 캐시 무효화

Cachae-Control: no-cache

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

Cachae-Control: no-store

데이터에 민강한 정보가 있으므로 저장하면 안됨

Cachae-Control: must-revalidate

캐시 만료후 최초 조회시 원서버에 검증해야함
원 서버 접근 실패시 반드시 오류가 발생해야함 - 504(Gateway Timeout) error
must-revalidate는 캐시 유효 시간이라면 캐시 사용

Pragma: no-cache

HTTP 1.0 하위 호환

no-cache와 must-revalidate를 같이 써야 하는가?

no-cache 기본 동작

캐시 서버 요청을 하면 프록시 캐시 서버에 도착하면 no-cache인 경우 원 서버에 요청을 하게된다. 그리고 원 서버에서 검증 후 응답을하게 된다.
하지만, 어떠한 이유라도 프록시 캐시 서버와 원 서버간 네트워크 연결이 단절되어 접근이 불가능 하다면, no-cache에서는 응답으로 오류가 아닌 오래된 데이터라도 보여주자라는 개념으로 200OK으로 응답을 한다.

must-revalidate 기본 동작

캐시 서버요청을 해 프록시 캐시 서버로 갔을때 캐시 서버와 원 서버간의 연결이 단절되어 접근이 불가능하다면 must-revalidate에서는 원 서버에 접근이 불가능한 경우 항상 오류가 발생해야 한다.(504 Gateway Timeout)

정리

그래서 위에 작성한 확실한 캐시 무효화 응답으로 작성한 헤더를 사용하게 되면
no-cache로 무조건 원 서버에서 검증을 하게하고 must-revalidate로 원 서버와 검증이 안되면 오류가 발생하도록 한다. 그리고 Pragma를 사용해서 혹시모를 1.0 이하 버전의 하위호환도 적용해준다.

참고
https://catsbi.oopy.io/6746abb1-efc6-4638-a0a2-e2e61bd0a636
https://www.inflearn.com/course/http-%EC%9B%B9-%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC/dashboard

웅평

이전 포스트

HTTP 헤더1 - 일반 헤더

다음 포스트