ASP.NET Core의 캐싱 개요

작성자: Rick Anderson 및 Kirk Larkin

메모리 내 캐싱

메모리 내 캐싱은 서버 메모리를 사용하여 캐시된 데이터를 저장합니다. 이 유형의 캐싱은 단일 서버 또는 고정 세션을 사용하는 여러 서버에 적합합니다. 세션 선호도를 고정 세션이라고 도 합니다. 세션 선호도는 클라이언트의 요청이 처리를 위해 항상 동일한 서버로 라우팅되는 것을 의미합니다.

자세한 내용은 ASP.NET Core 메모리 내 캐시 및 Azure Application Gateway 세션 선호도 이슈 해결을 참조하세요.

분산 캐시

앱이 클라우드 또는 서버 팜에서 호스팅될 때 분산 캐시를 사용하여 메모리에 데이터를 저장합니다. 캐시는 요청을 처리하는 서버에서 공유됩니다. 클라이언트에 대해 캐시된 데이터를 사용할 수 있는 경우 클라이언트는 그룹의 모든 서버에서 처리한 요청을 제출할 수 있습니다. ASP.NET Core는 SQL Server, Redis 및 NCache 분산 캐시와 함께 작동합니다.

자세한 내용은 ASP.NET Core의 분산 캐싱을 참조하세요.

캐시 태그 도우미

캐시 태그 도우미를 사용하여 MVC 보기 또는 Razor Page에서 콘텐츠를 캐시합니다. 캐시 태그 도우미는 메모리 내 캐싱을 사용하여 데이터를 저장합니다.

자세한 내용은 ASP.NET Core MVC의 캐시 태그 도우미를 참조하세요.

분산 캐시 태그 도우미

분산된 캐시 태그 도우미를 사용하여 분산 클라우드 또는 웹 팜 시나리오의 MVC 보기나 Razor Page에서 콘텐츠를 캐시합니다. 분산 캐시 태그 도우미는 SQL Server, Redis 또는 NCache를 사용하여 데이터를 저장합니다.

자세한 내용은 ASP.NET Core의 분산 캐시 태그 도우미를 참조하세요.

응답 캐싱

응답 캐싱 미들웨어:

• HTTP 캐시 헤더를 기반으로 서버 응답을 캐싱할 수 있도록 합니다. 표준 HTTP 캐싱 의미 체계를 구현합니다. 프록시처럼 HTTP 캐시 헤더에 기반하여 캐시합니다.
• 브라우저는 일반적으로 캐싱을 방지하는 요청 헤더를 설정하기 때문에 Razor Pages와 같은 UI 앱에는 일반적으로 도움이 되지 않습니다. ASP.NET Core 7.0 이상에서 사용할 수 있는 출력 캐싱은 UI 앱에 이점을 제공합니다. 출력 캐싱을 사용하여 구성에서 HTTP 헤더와 독립적으로 캐시할 내용을 결정합니다.
• 캐싱 조건이 충족되는 클라이언트의 퍼블릭 GET 또는 HEAD API 요청에 도움이 될 수 있습니다.

응답 캐싱을 테스트하려면 Fiddler 또는 요청 헤더를 명시적으로 설정할 수 있는 다른 도구를 사용합니다. 헤더를 명시적으로 설정하는 것은 캐싱을 테스트하는 데 선호됩니다. 자세한 내용은 문제 해결을 참조하십시오.

출력 캐싱

출력 캐싱 미들웨어를 사용하면 HTTP 응답을 캐싱할 수 있습니다. 출력 캐싱은 아래와 같이 응답 캐싱과 다릅니다.

• 캐싱 동작은 서버에서 구성할 수 있습니다.

  응답 캐싱 동작은 HTTP 헤더로 정의됩니다. 예를 들어 Chrome 또는 Edge를 사용하여 웹 사이트를 방문하면 브라우저에서 자동으로 Cache-control: max-age=0 헤더를 보냅니다. 이 헤더는 서버가 클라이언트에서 제공하는 지침을 따르므로 응답 캐싱을 효과적으로 사용하지 않도록 설정합니다. 서버에 새로 캐시된 응답이 있더라도 모든 요청에 대해 새 응답이 반환됩니다. 출력 캐싱을 사용하면 클라이언트가 서버에서 구성하는 캐싱 동작을 재정의하지 않습니다.

• 캐시 저장소 매체는 확장할 수 있습니다.

  메모리는 기본적으로 사용됩니다. 응답 캐싱은 메모리로 제한됩니다.

• 선택한 캐시 항목을 프로그래밍 방식으로 무효화할 수 있습니다.

  응답 캐싱이 HTTP 헤더에 의존하면 캐시 항목을 무효화하기 위한 몇 가지 옵션이 남습니다.

• 리소스 잠금을 통해 캐시 스탬프 및 썬더링 무리 위험을 완화할 수 있습니다.

  캐시 스탬프는 자주 사용되는 캐시 항목이 해지되고 너무 많은 요청이 동일한 캐시 항목을 동시에 다시 채점하려고 할 때 발생합니다. 천둥 무리 는 비슷합니다: 캐시 항목에 아직 없는 동일한 응답에 대 한 요청의 버스트. 리소스 잠금은 지정된 응답에 대한 모든 요청이 첫 번째 요청이 캐시를 채울 때까지 대기하도록 합니다. 응답 캐싱에는 리소스 잠금 기능이 없습니다.

• 캐시 유효성 재검사로 대역폭 사용량이 최소화됩니다.

  캐시 유효성 재검사란 서버가 캐시된 응답 본문 대신 HTTP 상태 코드를 반환 304 Not Modified 할 수 있습니다. 이 상태 코드는 요청에 대한 응답이 이전에 받은 응답과 변경되지 않음을 클라이언트에 알릴 수 있습니다. 응답 캐싱은 캐시 유효성 검사를 수행하지 않습니다.