1. Cache 정의과 개념

1.1 캐시(Cache)의 정의

• 캐시(Cache)의 사전적 정의는 숨겨진 물건의 저장 공간 또는 그 공간 자체를 지칭한다.
• 컴퓨터 분야에서는 데이터나 정보를 빠르게 액세스 할 수 있도록 일시적으로 저장하는 메모리나 저장 공간을 말한다.
• HTTP 캐시(Cache)란?
  • 웹사이트나 앱의 클라이언트가 이용하는 서비스 과정에서 이미지, HTML, 파일과 같이 재사용 할 수 있는 HTTP Resource들을 임시 (기간 설정 or 알고리즘)로 보관되는 저장 공간 이다.

• 캐시 : 임시로 재사용할 내용을 저장한 공간

  HTTP Resource
  웹 페이지, 영상, 음성, 이미지, HTML, JS 등등

1.2 HTTP 캐시(Cache)의 개념

• 클라이언트가 서버에 요청하고 서버는 응답하는게 웹의 본질 이다.
• 클라이언트가 매번 똑같은 내용을 서버에 요청을 한다면, 서버는 매번 똑같은 응답을 해줘야한면 이런 상황에 캐시를 사용한다.

• 예시

  • 캐시 X

    • 클라이언트가 웹 브라우저에서 매번 똑같은 100MB 짜리 고양이 영상을 웹 서버로 받아온다.

    • 매번 동영상이 다운로드 완료까지 긴 대기시간이 생기며 서버 응답의 네트워크 트래픽 및 비용이 발생한다.

  • 캐시 O

    • 첫 번째 요청에 100MB 짜리 고양이 영상을 캐시에 임시 저장을 한다. 클라이언트가 두 번째 요청한다면 캐시에서 고양이 영상을 반환한다. (두 번째부터 서버에 요청하지 않는다.)

    • 두 번째 요청부터 동영상 다운로드 없이 바로 시청 가능하고 서버에 요청하지 않아 네트워크 트래픽 및 비용 감소한다.

1.3 캐시(Cache)는 어디에 있는가?

• 캐시는 웹 브라우저, 웹 서버(프록시 서버, CDN)에 위치한다.
• 위치에 따라 캐시의 역할이 달라진다. (3.2 Cache 종류를 참조)

캐싱(Caching)이란?

• 데이터나 계산 결과를 캐시에 저장하는 행위를 말한다. 캐싱은 주로 데이터를 반복적으로 가져오거나 계산하는 작업을 최소화하고 성능을 향상시키기 위해 사용된다.

---

2. Cache의 이점

• 성능 향상
  • 가장 큰 이점 중 하나인 성능 향상, 캐시를 사용하면 이전에 액세스한 데이터나 계산 결과를 빠르게 반환할 수 있어서 원본 데이터나 계산에 비해 빠른 응답 속도로 제공한다.
• 네트워크 트래픽 감소
  • 반복적으로 동일한 데이터를 서버에서 불러오지 않고 캐시에서 가져오면, 네트워크 트래픽이 감소한다.
• 서버 부하 감소
  • 캐시를 사용하면 클라이언트가 요청한 데이터를 서버에서 반복적으로 계산하거나 불러오는 부하를 감소시킨다.
• 응답 속도 향상
  • 클라이언트가 캐시에서 데이터를 가져오면 원본 데이터를 서버에서 받아오는 것보다 훨씬 빠른 응답을 받을 수 있다.
• 비용 절감
  • 네트워크 트래픽 및 서버 부하의 감소로 인해 비용이 절감된다. 빠른 응답과 효율적인 자원 활용은 비즈니스에 소요되는 운영 비용을 줄일 수 있다.
• 사용자 경험 향상(UX)
  • 빠른 응답 속도와 원활핞 데이터 로딩은 사용자 경험을 향상시킨다.

---

3. Cache의 종류

• CPU 캐시 : CPU 연산을 위해 메모리에서 값 가져와 사용 후 폐기(칩셋)
• HTTP 캐시 : 웹 요청에 따른 결과를 임시 정장 후 폐기
• 서버 캐시 : LRU-Cache 로컬 캐시, 글로벌 캐시

이 문서에서는 주로 HTTP 캐시에 관한 내용을 다룰 것이며, CPU 및 서버 캐시에 대한 정보는 다른 문헌에서 참고하시기 바랍니다.

3.2 HTTP Cache 종류

크게 두 종류로 나누어진다.

1. Private : 대상이 특정 한 명
2. Shared : 대상이 불특정 다수

• Private 이란 단일 사용자만 전용으로 사용한다. 캐시가 웹 브라우저 안에 있어 유저 한 명만을 위한 것

  • 브라우저 캐시 : 웹 서버 HTTP Cache 헤더(Cache-control)를 통한 제어

• Shared 이란 불특정 다수가 사용한다. 캐시가 웹 브라우저와 웹 서버 사이에 있어 모든 웹 브라우저 유저 다수를 위한 것이다.

  • Proxy Cache : 웹 서버 HTTP Cache 헤더 (Cache-control) 를 통한 제어
  • Managed Cache : CDN 서비스 그리고 리버스 프록시에서 동작하는 캐시이다. 서비스들의 관리자 패널에서 직접 캐시에 대한 설정을 관리하거나 리버스 프록시 설정으로 관리할 수 있으므로 Managed Cache라 한다.
    • CDN Cache : 캐싱 + 지역성 해결을 위해 사용한다. HTTP Resource 제공 서버와 클라이언트가 멀리 떨어진 경우 클라이언트에 가까운 곳에 저장한다. 클라이언트의 요청은 가까운 서버가 응답해 클라이언트의 만족도를 향상시킨다.

• 간단한 모식도
  

• 참조 이미지
  
  출처 : https://developer.mozilla.org/en-US/docs/Web/HTTP/Caching

• 프록시, 포워드 프록시와 리버스 프록시에 대한 내용은 프록시란? 에서 확인하실 수 있습니다.
• CDN에 대한 설명은 CDN 에서 확인하실 수 있습니다.

---

4. HTTP Cache 동작

4.1 Cache hit, miss

• Cache Hit
  • 웹 브라우저 및 Proxy, CDN의 캐시에서 클라이언트 요청 HTTP Resource가 있을 때이다.
• Cache Miss
  • 웹 브라우저 및 proxy, CDN의 캐시가 없을 때 없을 때이다. 그럼 다음 서버로가 다시 캐시가 있는지 물어본다.
• Web Server
  • Web Browser, Proxy의 캐시에 클라이언트 요청 HTTP Resource가 없으면 Web Server에 도달
  • 클라이언트 요청에 대한 HTTP Resource와 헤더인 Cache-Control를 가지고 다시 Proxy, Web Browser를 거쳐 클리아인트에게 응답한다.
• 헤더 Cache-Control
  • Public라면 Proxy와 Web Browser에 캐시 저장
  • Private이라면 Web Browser에 캐시 저장

4.2 Cache-control 헤더를 통한 세부 설정

• 캐시 활용 여부 = 실시간성이 중요한 데이터는 성능에 문제가 되더라도 캐시는 사용하지 않는 것이 맞다.
• 재검증
  • 데이터 원 주인인 웹 서버에 캐시되어있는 데이터의 유효성(신선도) 체크
  • 재검증 기준
    • 시간 : 수정일 Last-Modified, If-Modified-Since
    • 고유값 : 식별자 ETag, If-None-Match (Hash)

• 서버의 제어로 HTTP Cache 사용 여부 및 기간, 저장 장소 등 정책 전달하기 위해서 헤더를 사용한다.
  • 예시) Cache -control : public, immutable, max-age=31536000

1. 캐시 저장 여부
   • no-store : 캐시를 사용하지 않는다.
   • no-cache : 캐시 저장은 한다 하지만 매번 재검증 후 사용
2. 캐시 저장 장소 : 어디에 저장해?
   • public : Private + Shared 모두에 저장 (브라우저 캐시 + 프록시 캐시)
   • private : Private에만 저장 (브라우저 캐시)
3. 캐시 재검증 주기 : 얼마가 지나면 재검증해?
   • max-age : Expires(유효시간)으로 변환되기 때문에, 기존 Expires가 있어도 덮어쓴다.
     • 매번 재검증 : max-age=0, no-cache
   • s-maxage : 포록시 캐시에만 적용되는 유효기간
   • CDN 캐시 적용예) s-maxage=31536000, max-age-0
4. 재검증 강제
   • must-revalidate : max-age에 도달하였을때 꼭 재검증이 완료된 뒤 사용하도록 가제
     • max-age에 도달하였을때, 서버와의 접속 문제로 재검증 실패시 기존엔 그냥 기존것 반환
       • must-revalidate가 활성화되어있다면 504 에러 발생
       • 웹 서버 개발자가 생각했을때 통장 잔고같은것은 어떤 상황에서도 검증 없인 써서는 안됨

4.3 재검증

재검증에는 두가지 기준이 있다. Last-modified와 ETag이다.

• Last-Modified 대응 : 시간 기반
  • 전송 Resource의 마지막 수정 시각을 명시한 것
  • 캐시가 유효한지 여부를 시간을 기반으로 판단한다.
  • 캐시 소요자가 if-Modified-Since 요청(Request)
    • 서버 답변 리소스가 다르면 200, Resource Cache
    • 서버 답변 리소스가 같다면 304, Not Modified
  • 캐시 소유자가 if-Unmodified-Since 요청
    • 서버 답변 리소스가 변하지 않아다면 304, Not Modified
  
  
• ETag 대응 : 고유값(해시, ID)기반
  • ETag는 Resource의 고유값이다.
  • 서버가 해당 해더 ETag를 클라이언트에 전송해 브라우저 캐시에 저장
  • 캐시의 유효성 검사
    • 서버에if-None-Match 헤더를 사용하여 현재 리소스 ETag값을 전송해 서버 ETag와 대응
    • 변경이 있으면 새로운 리소스를 반환, 캐시 업데이트
    • 변경이 없다면 클라이언트에 Not Modified 응답, 클라이언트는 캐시된 리소스를 사용

---

• HTTP Cache 제어중 SWR(stale-while-reValidate) 확장 디렉티브 전략
  • 현재에(당장에) 캐싱된 컨텐츠를 즉시 로드하는 즉시성 (Stale 이더라도)
  • 미래에 업데이트된 캐싱 컨텐츠가 사용될 수 있도록 보장하는 최신성

    SWR 에서 더 자세한 설명을 확인할 수 있습니다.

---

4.4 재검증의 한계

• Last-Modified & if-modified-since 방식의 한계점
  • 1초 미만(0.x)초 단위로 캐시 조정일 불가능하다.
  • 날씨 기반의 로직으로 사용하는데 한계가 있다. 내용 변경은 없었지만 마지막 수정 날짜가 달라지면 다시 서버에서 받아와야한다.
  • 서버에서 별도의 캐시 로직을 관리하고 싶은 경우 한계가 있다. (스페이스나 주석처럼 크게 영향이 없는 변경에서 캐시를 유지하고 싶은 경우)
• ETag의 방식의 한계점
  • ETag를 생성하는데 필요한 계산이나 해싱 과정이 서버에 부담을 준다.
  • 파일 변경 여부만 고려한다. 파일 내용이 동일해도 수정 날짜가 변경되는 경우 ETag는 다르게 생성이 된다.

=> 일반적으로는 Last-Modified와 ETag 두 방식을 사용하여 캐시 유효성 검사를 강하게 하지만 항상 필수적인 것인 아니다. 필요에 따라 사용하면 된다.

---

• Cache : https://developer.mozilla.org/en-US/docs/Web/HTTP/Caching
• https://hudi.blog/http-cache/
• https://inpa.tistory.com/entry/HTTP-%F0%9F%8C%90-%EC%9B%B9-%EB%B8%8C%EB%9D%BC%EC%9A%B0%EC%A0%80%EC%9D%98-%EC%BA%90%EC%8B%9C-%EC%A0%84%EB%9E%B5-Cache-Headers-%EB%8B%A4%EB%A3%A8%EA%B8%B0