웹 캐시

주형(Jureamer)·2022년 1월 3일
0

Network

목록 보기
4/5

캐시

캐시는 컴퓨터 과학에서 데이터나 값을 미리 복사해 놓는 임시 장소를 가리킨다.

캐시는 캐시의 접근 시간에 비해 원래 데이터를 접근하는 시간이 오래 걸리는 경우나 값을 다시 계산하는
시간을 절약하고 싶은 경우 사용한다.

검증헤더와 조건부 요청

캐시를 재사용하기 위해 검증헤더, 조건부 요청을 이용할 수 있다.

Last Modified(검증헤더) & If-Modified-Since(조건부요청)

Last Modified: 데이터가 마지막으로 수정된 시간을 헤더에 포함한다.

    Last-Modified: <day-name>, <day> <month> <year> <hour>:<minute>:<second> GMT

If-Modified-Since: 해당 헤더를 이용해 캐시 유효시간이 초과되더라도 조건부 요청을 할 수 있다.

=> 수정되지 않았다면 바디를 제외한 HTTP 헤더만 전송함으로써, 응답결과를 재사용한다. 클라이언트에서는 해당 응답을 받은 뒤 캐시를 갱신하고 다시 일정 시간동안 유효하게 만든다.

정리

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

단점

  • 1초 미만(0.x초) 단위로 캐시 조정이 불가능
  • 날짜 기반의 로직 사용
  • 데이터를 날짜만 수정할 경우 다른 데이터로 인식한다.
  • 서버에서 별도의 캐시 로직을 관리하기 힘들다.

ETag(검증헤더) & If-None-Match(조건부 요청)

ETag(Entity Tag)

  • 캐시용 데이터에 임의의 고유한 버전 이름을 달아둔 것
    - 예시: ETag: "v1.1", ETag: "61dis0admczcnasckzokczockaoa1"
  • 데이터가 변경되면 이 이름을 바꾸어서 변경함 (Hash 재생성)
    - 예시: ETag: "81401ckcksaww" -> ETag: "95029dkcoizuc
  • 단순하게 ETag만 보내서 같으면 유지, 다르면 다시 받는 방식

If-None-Match

  • ETag를 검증하기 위해 사용

정리

  • 단순하게 ETag만 보내서 같으면 유지, 다르면 다시 받는 방식
  • 캐시 제어 로직을 서버에서 완전히 관리
  • 클라이언트는 단순히 이 값을 서버에서 제공 (클라이언트는 캐시 매커니즘을 모름)
  • 예시)
    1. 서버는 베타 오픈 기간동안 3일동안 파일이 변경되어도 ETag를 동일하게 유지
    1. 애플리케이션 배포 주기에 맞추어 ETag 갱신

캐시 관련 헤더

Cache-Control: max-age

  • 캐시 유효시간. 초 단위
    Cache-Control: no-cache
  • 데이터는 캐시해도 되지만, 항상 원(Origin) 서버에 검증하고 사용
    **Cache-Control: no-store
  • 데이터에 민감한 정보가 있으므로 저장하면 안됨(메모리에서만 사용하고 최대한 빨리 삭제)
    **Expires: Mon, 01 Jan 1990 00:00:00 GMT
  • 캐시 만료일을 정확한 날짜로 지정
  • HTTP 1.0부터 사용
  • 지금은 더 유연한 Cache-Control: max-age 권장
  • Cache-Control:max-age와 함께 사용 시, Expires는 무시 됨

프록시 캐시(Proxy Cache)

프록시 서버란? 클라이언트가 다른 네트워크 서비스에 간접적으로 접속할 수 있게 하는 컴퓨터 시스템이나 응용 프로그램을 의미한다. 클라이언트와 서버 사이에 대리로 통신을 수행하는 것을 '프록시(Proxy)', 그 중계 기능을 하는 서버를 '프록시 서버' 라고 한다.

보안, 캐싱을 통한 성능, 트래픽 분산 등의 장점을 가진다.

프록시 캐시는 원(Origin) 서버가 미국에 있다고 가정했을 시, 직접 접근하여 자료를 가져올 경우 속도가 느릴 수 밖에 없다. 하지만 한국에 프록시 캐시서버를 통하여 자료를 캐시에 올려두면 같은 국내에 있는 클라이언트는 훨씬 빠른 속도로 자료를 가져올 수 있다.

프록시 서버와 관련된 캐시 지시어
- Cache-Control: public
- 응답이 public 캐시에 저장되어도 됨
- Cache-Control: private
- 응답이 해당 사용자만을 위한 것, private 캐시에 저장해야 함(기본 값)
- Cache-Control: s-maxage
- 프록시 캐시에만 적용되는 max-age
- Age: 60(HTTP 헤더)
- 오리진 서버에서 응답 후 프록시 캐시 내에 머문 시간(초)

캐시 무효화 지시어
- Cache-Control: no-cache
- 데이터는 캐시해도 되지만, 항상 원 서버에 검증하고 사용
- Cache-Control: no-store
- 데이터에 민감한 정보가 있으므로 저장하면 안됨
- Cache-Control: must-revalidate
- 캐시 만료 후 최초 조회 시 원 서버에 검증해야함
- 원 서버 접근 실패 시 반드시 오류가 발생해야함 - 504(Gateway Timeout)
- must-revalidate는 캐시 유효 시간이라면 캐시를 사용함
- Pragma: no-cache
- HTTP 1.0 하위 호환

확실히 무효화 응답을 하고 싶다면 위에 있는 캐시 지시어를 모두 넣어야함.

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

no-cache VS must-revalidate 비교

(no-chache)
프록시 캐시 서버와 원 서버 간 네트워크 연결이 단절되어 접근이 불가능하다면, 응답으로 오류가 아닌 오래된 데이터를 보여주자라는 개념으로 "200 OK" 로 응답한다.

(must-revalidate)
원 서버에 접근이 불가할 때 504 Gateway Timeout 오류를 보낸다.* 통장 잔고 등 중요한 정보가 원 서버에 접근 못하여 예전 데이터를 보낼 경우 큰 문제가 될 수 있으므로, must-revalidate를 사용한다.

Reference

profile
작게라도 꾸준히 성장하는게 목표입니다.

0개의 댓글