[HTTP] Cache-Control: 웹 서비스 캐시(Cache) 다루기

 

 

💋 인트로

웹사이트에 있어서 속도(성능)는 매우 중요하다. 

구글에서 정리한 자료에 따르면, 속도는 실제 서비스의 사용자를 늘리고 서비스의 영업 이익을 늘린다고 한다.

 

백엔드 개발자가 적은 시간 투자로 최대 성능 효과를 얻을 수 있는 방법은 대략 아래와 같다.

• HTTP 압축
• 다양한 리소스 최적화 기법
• 이미지, JS, CSS, 기타 리소스
• HTTP 캐싱

이중에서도 이번 포스팅에서는 캐싱에 대해 집중적으로 다룰 예정이다. 

 

💋 HTTP 캐시(Cache) 

✔ 개념

출처: 우테코 코치 구구

• 캐시는 데이터나 콘텐츠를 일시적으로 저장하는 임시 저장소
• 웹에서의 캐시는 웹 페이지, 이미지, 스크립트, 스타일 시트 등의 자원들을 저장하여 이후에 동일한 자원에 접근할 때 더 빠르게 가져올 수 있도록 함.

✔ 캐시를 사용하는 이유

1. 성능 향상: 웹 페이지의 자원들을 다시 서버로부터 가져오는 것보다 캐시된 자원을 사용하는 것이 더 빠릅니다. 캐시된 자원은 로컬 컴퓨터나 네트워크의 브라우저 캐시에서 바로 가져오기 때문에 네트워크 대역폭을 절약하고 응답 시간을 단축시킵니다.

2. 데이터 전송량 감소: 캐시를 사용하면 웹 페이지를 방문할 때마다 서버로부터 모든 자원을 다시 받아올 필요가 없습니다. 이미 캐시된 자원들은 로컬에서 가져와서 사용할 수 있기 때문에 데이터 전송량을 줄여줍니다.

3. 서버 부하 감소: 캐시된 자원을 사용하면 웹 서버의 부하를 줄일 수 있습니다. 반복적으로 요청되는 자원들은 캐시에 저장되므로, 서버는 해당 자원들에 대한 요청을 처리하는 데 드는 부담을 줄일 수 있습니다.

캐시는 웹 브라우저나 중간에 위치한 프록시 서버 등에서 관리됩니다. 이러한 캐시는 캐시 제어 헤더를 통해 캐시의 동작을 제어하고, 캐시된 자원의 유효성을 확인하여 필요할 때만 새로운 자원을 요청하게 됩니다.

 

 

 

 

이번 포스팅에서는 캐시를 다루는 방법, 그중에서도 Cache-Control 헤더를 통한 제어에 대해서 설명할 것이다. 

웹 서비스의 캐시에 대한 전반적인 내용에 대해 알고싶다면, 토스 기술블로그에 올라온 이 포스팅을 적극 추천한다. 

 

✔ 캐시 제어 헤더

HTTP 헤더 가운데 캐시에 대한 내용을 제어할 수 있는 헤더는 아래와 같다. 

• Cache-Control
• Pragma
• Expires

이 가운데 현재의 HTTP/1.1에서 주로 사용하고, 현재 개발자를 준비하는 우리가 적극적으로 사용해야 하는 것은 Cache-Control이다. 

 

 

아래 두 가지를 잘 사용하지 않는 이유는 아래의 글을 펼쳐보면 알 수 있다! 

• Expires
  • 이 헤더는 캐시의 만료일을 지정하는 데 사용
  • 정확한 시간을 지정하는 대신, 특정 날짜와 시간을 사용하기 때문에 이를 유지하기가 어려움
  • 캐시 갱신에 대한 유연성이 부족하고, 캐시된 콘텐츠가 적절히 갱신되지 않을 수 있음.
• Pragma
  • HTTP/1.0에서 사용되던 캐시 제어 헤더
  • 캐시 동작에 영향을 미치는 지시사항을 전달하기 위해 사용
  • HTTP/1.1 및 그 이후의 버전에서는 Cache-Control 헤더가 도입되면서, Cache-Control의 하위 호환이 됨.
    • Cache-Control 헤더는 Pragma 헤더보다 더 포괄적인 캐시 제어 기능을 제공하며, 더욱 유연하고 표준화된 방식으로 동작함
    • Pragma 헤더는 오래된 버전의 HTTP 프로토콜과의 호환성을 유지하기 위해 사용되지만, 대부분의 경우에는 Cache-Control 헤더를 사용하는 것이 권장됨.
  • Pragma 헤더에는 "no-cache"라는 값이 주로 사용되는데, 이는 캐시된 콘텐츠를 재사용하지 않고 항상 서버로부터 새로운 콘텐츠를 가져와야 함을 나타냄.
    • 그러나 이 값은 Cache-Control 헤더의 "no-cache" 지시자와 다르게 작동할 수 있고, Pragma 헤더를 해석하지 않는 캐시 서버가 있을 수 있음
    • "no-cache" 기능을 구현하려면 Cache-Control 헤더를 사용하는 것이 더 일반적이고 신뢰할 수 있는 방법임.
  • 현재 Pragma 헤더는 오래된 버전의 HTTP와의 호환성을 위해 사용되거나 특정한 상황에서만 필요한 경우에 사용됨.

 

그럼 이제 이 포스팅의 메인 주제인 Cache-Control에 대해서 살펴보자! 

 

💋 Cache-Control 

• Cache-Control: max-age
  • 캐시의 유효 시간을 초 단위로 지정함
• Cache-Control: no-cache
  • 데이터 캐시는 해도 되지만, 항상 origin 서버에 검증하고 사용
• Cache-Control: no-store
  • 데이터에 민감한 정보가 포함되었을 때  사용
  • 절대로 저장하면 안되는 경우에, 해당 지시어를 사용해서 메모리에서 사용하고 최대한 빠르게 삭제하도록 함.
• Cache-Control: must-revalidate
  • 캐시 만료 후 최초 조회 시 origin 서버에 검증해야 함. 
  • no-cache보다 더 강력한 검증을 요구하는 설정이다. 
  • origin 서버 접근 실패 시에 반드시 오류가 발생해야 함.
• Cache-Control: public
  • 응답이 public 캐시에 저장되어도 됨 
  • 모든 사람과 중간 서버가 캐시를 저장할 수 있음
• Cache-Control: private
  • 가장 끝의 사용자 브라우저만 캐시를 저장할 수 있음.
• Cache-Contro: s-maxage
  • 프록시 캐시에만 적용되는 max-age

 

💋 no-cache VS must-revalidate

✔ Cache-Control: no-cache

이미지 출처: 인프런 김영한님 강의

 

웹 브라우저가 리소스에 접근하기 위해서 프록시 캐시에 우선 요청을 보낸다. 

캐시 서버는 no-cache가 붙어있기 때문에 반드시 origin 서버에 검증해야 한다.

 

origin 서버가 이제 응답을 한다. 

 

• 캐시 데이터가 fresh한 경우 (oudated되지 않음)

이미지 출처: 인프런 김영한님 강의

ETag를 통해서 원 서버는 최신의 데이터와 캐시 서버가 가지고 있는 데이터가 같다고 판단하면, 304 Not Modified 응답을 보내고, 해당 응답을 받은 웹 브라우저는 캐시 데이터를 사용한다. 

 

• 원 서버에 캐시 데이터를 조회하는데, 네트워크에 접속할 수 없어 연결이 끊긴 경우 

이미지 출처: 인프런 김영한님 강의

no-cache의 경우에는 원 서버에 반드시 접속해서 현재의 캐시 데이터가 fresh한지 확인 후에 캐시 데이터를 사용해야만 한다. 

하지만, 원 서버에 접속할 수 없는 경우에는 에러를 반환하거나, 때에 따라서 오래된 데이터라도 보여주는 것이 나을 경우에는 200 OK로 응답 후에 캐시에 저장된 데이터를 보여주도록 설정할 수 있다. 

 

 

✔ Cache-Control: must-revalidate

no-cache와 달리 좀 더 강력한 검증을 요구하는 설정이다. 

따라서 원 서버에 접근할 수 없는 경우에는 항상 오류가 발생해야 한다. 504 Gateway Timeout을 반환한다.

 

이 설정은 돈과 관련된 결과처럼, 반드시 최신 데이터여야만 하는 경우에 사용한다. 

 

💋 참고자료

• https://toss.tech/article/smart-web-service-cache
• https://velog.io/@leemember/HTTP-%ED%94%84%EB%A1%9D%EC%8B%9C-%EC%BA%90%EC%8B%9C
• https://www.inflearn.com/course/http-%EC%9B%B9-%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC/dashboard

 

도움이 되었다면, 공감/댓글을 달아주면 깃짱에게 큰 힘이 됩니다!🌟