ASP.NET Core の応答キャッシュ

作成者: Rick Anderson および Kirk Larkin

応答キャッシュを使用すると、クライアントまたはプロキシから Web サーバーに対して行う要求の数が減ります。 応答キャッシュを使用することで、Web サーバーで応答を生成するために実行される作業量も減ります。 応答キャッシュはヘッダーで設定されます。

ResponseCache 属性は、応答キャッシュ ヘッダーを設定します。 クライアントと中間プロキシでは、 RFC 9111: HTTP キャッシュ 仕様に基づく応答をキャッシュするためのヘッダーを使用する必要があります。

HTTP 1.1 キャッシュ仕様に従うサーバー側キャッシュのためには、応答キャッシュ ミドルウェアを使用します。 ミドルウェアで ResponseCacheAttribute プロパティを使用すると、サーバー側キャッシュの動作に影響を与えることができます。

応答キャッシュ ミドルウェアを使用すると、 HTTP Cache-Control ヘッダーに基づいてサーバー応答をキャッシュできます。

• キャッシュ動作は、標準の HTTP キャッシュ セマンティクスを実装します。

• キャッシュは、プロキシで使用されるメソッドと同様の HTTP キャッシュ ヘッダーに基づいています。

• この形式のキャッシュは、キャッシュの 条件 が満たされているクライアントからのパブリック GET または HEAD API 要求に役立ちます。

• Razor ページなどの UI アプリの場合、通常、応答キャッシュは有益ではありません。 通常、ブラウザーはキャッシュを妨げる要求ヘッダーを設定します。

  出力キャッシュ (.NET 7 以降で利用可能) は、UI アプリに適した方法です。 このシナリオでは、構成によって、HTTP ヘッダーに関係なくキャッシュする内容が決まります。

応答キャッシュをテストするには、 Fiddler または要求ヘッダーを明示的に設定できる別のツールを使用します。 キャッシュをテストするには、ヘッダーを明示的に設定することをおすすめします。 詳細については、「 応答キャッシュ ミドルウェア > トラブルシューティング」を参照してください。

サンプル コードを表示またはダウンロードします (ダウンロード方法)。

HTTP ベースの応答キャッシュ

RFC 9111: HTTP キャッシュ仕様では、インターネット キャッシュの動作について説明しています。 キャッシュのために使用される主な HTTP ヘッダーは、Cache-Control です。これは、キャッシュのディレクティブを指定するために使用されます。 ディレクティブは、要求がクライアントからサーバーに移動し、応答がサーバーからクライアントに戻る際のキャッシュ動作を制御します。 要求と応答はプロキシ サーバー間を移動し、プロキシ サーバーも HTTP 1.1 キャッシュ仕様に準拠している必要があります。

一般的な Cache-Control ディレクティブを次の表に示します。

Directive	Action
public	キャッシュは応答を格納できます。
private	共有キャッシュは応答を格納できません。 プライベート キャッシュは、応答を格納して再利用できます。
max-age	クライアントは、経過時間が指定の秒数を超えた応答を受け入れません。 例: max-age=60 (60 秒)、 max-age=2592000 (1 か月)
no-cache	要求時: キャッシュに格納された応答を、要求を満たすために使用することはできません。 オリジン サーバーはクライアントに対する応答を再生成し、キャッシュ内に格納されている応答がミドルウェアによって更新されます。 応答時: オリジン サーバー上での検証なしに後続の要求に応答を使用することはできません。
no-store	要求時: キャッシュに要求を格納することは禁止されます。 応答時: キャッシュに応答を一部でも格納することは禁止されます。

キャッシュで役割を果たすその他のキャッシュ ヘッダーを次の表に示します。

Header	Function
Age	配信元サーバーで応答が生成または正常に検証されてからの時間を秒単位で見積もります。
Expires	応答が古いと見なされる時間を指定します。
Pragma	HTTP 1.0 キャッシュと後方互換性を持たせるために、no-cache の動作を設定する目的で存在します。 Cache-Control ヘッダーが存在する場合、Pragma ヘッダーは無視されます。
Vary	キャッシュされた応答の最初要求と新しい要求の両方で、すべての Vary ヘッダー フィールドが一致しない限り、キャッシュされた応答を送信してはならないことを指定します。

HTTP ベースのキャッシュは、リクエストのCache-Controlディレクティブを尊重します。

RFC 9111: HTTP キャッシュ (セクション 5.2. Cache-Control) の仕様では、クライアントによって送信された有効なCache-Control ヘッダーを受け入れるキャッシュが必要です。 クライアントは、no-cache ヘッダー値を使用して要求を行うことで、すべての要求に対してサーバーに新しい応答を強制的に生成させることができます。

HTTP キャッシュの目標を考えると、クライアントの Cache-Control 要求ヘッダーに常に従うことは理にかなっています。 公式仕様では、キャッシュはクライアント、プロキシ、およびサーバーのネットワーク全体で要求を満たすための待機時間とネットワーク オーバーヘッドを削減することを目的としています。 これは必ずしもオリジン サーバーの負荷を制御する方法ではありません。

応答キャッシュ ミドルウェアを使用する場合、このキャッシュ動作を開発者が制御することはできません。ミドルウェアは公式のキャッシュ仕様に準拠しているためです。 .NET 7 以降には、サーバーの負荷をより適切に制御するための output キャッシュ のサポートが含まれています。 詳細については、「出力キャッシュ」を参照してください。

ResponseCache 属性

ResponseCacheAttribute クラスは、応答キャッシュで適切なヘッダーを設定するために必要なパラメーターを指定します。

Warning

認証されたクライアントに関する情報を含むコンテンツのキャッシュを無効にします。 キャッシュは、ユーザーの ID またはユーザーがサインインしているかどうかに基づいて変更されないコンテンツに対してのみ有効にする必要があります。

VaryByQueryKeys プロパティは、格納されている応答を、指定されたクエリ キーの一覧の値によって異なります。 ワイルドカード アスタリスク (*) の 1 つの値を指定すると、ミドルウェアはすべての要求クエリ文字列パラメーターによって応答を異なります。

レスポンスキャッシュミドルウェアを有効にするには、VaryByQueryKeys プロパティを設定する必要があります。 そうしないと、ランタイム例外がスローされます。 VaryByQueryKeys プロパティに対応する HTTP ヘッダーは存在しません。 このプロパティは、応答キャッシュ ミドルウェアによって処理される HTTP 機能です。 キャッシュされた応答をミドルウェアで処理するには、クエリ文字列とクエリ文字列値が前の要求と一致する必要があります。 たとえば、次の表に示す一連の要求と結果について考えてみます:

Request	戻ってきた
http://example.com?key1=value1	Server
http://example.com?key1=value1	Middleware
http://example.com?key1=NewValue	Server

サーバーは最初の要求を返し、ミドルウェアは要求をキャッシュします。 クエリ文字列が前の (最初の) 要求と一致するため、ミドルウェアは 2 番目の要求を返します。 3 番目の要求は、クエリ文字列の値が前の要求と一致しないため、ミドルウェア キャッシュ内に存在しません。

ResponseCacheAttribute クラスは、(IFilterFactory インターフェイスを介して) Microsoft.AspNetCore.Mvc.Internal.ResponseCacheFilterを構成および作成するために使用されます。 ResponseCacheFilter は、応答の適切な HTTP ヘッダーと機能を更新する処理を実行します。 フィルター:

• Vary、Cache-Control、Pragmaの既存ヘッダーがあれば削除します。
• ResponseCacheAttribute で設定されたプロパティに基づいて、適切なヘッダーを書き出します。
• VaryByQueryKeys プロパティが設定されている場合は、応答キャッシュ HTTP 機能を更新します。

Vary ヘッダー

このヘッダーは、VaryByHeader プロパティが設定されている場合にのみ書き込まれます。 プロパティは、 Vary プロパティの値に設定されます。 次のサンプルでは、VaryByHeader プロパティを使用しています。

[ApiController]
public class TimeController : ControllerBase
{
    [Route("api/[controller]")]
    [HttpGet]
    [ResponseCache(VaryByHeader = "User-Agent", Duration = 30)]
    public ContentResult GetTime() => Content(
                      DateTime.Now.Millisecond.ToString());

Fiddler または別のツールを使用して応答ヘッダーを表示します。 応答ヘッダーには、次のものが含まれます:

Cache-Control: public,max-age=30
Vary: User-Agent

上記のコードでは、応答キャッシュ ミドルウェア サービス AddResponseCaching メソッドをサービス コレクションに追加する必要があります。 コードは、 UseResponseCaching 拡張メソッドでミドルウェアを使用するようにアプリを構成します。

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddControllers();
builder.Services.AddResponseCaching();

var app = builder.Build();

app.UseHttpsRedirection();

// UseCors must be called before UseResponseCaching
//app.UseCors();

app.UseResponseCaching();

app.UseAuthorization();

app.MapControllers();

app.Run();

NoStore プロパティと Location.None プロパティ

NoStore プロパティは、他のほとんどのプロパティをオーバーライドします。 このプロパティを true に設定すると、Cache-Control ヘッダーが no-store に設定されます。 Location プロパティが None に設定されている場合:

• Cache-Control ヘッダーは no-store,no-cache に設定されます。
• Pragma ヘッダーは no-cache に設定されます。

NoStore プロパティが false に設定され、Location プロパティが None に設定されている場合、Cache-ControlおよびPragmaヘッダーはno-cacheに設定されます。

NoStore プロパティは、通常、エラー ページのtrueに設定されます。 次のコードは、応答を格納しないようにクライアントに指示する応答ヘッダーを生成します。

[Route("api/[controller]/ticks")]
[HttpGet]
[ResponseCache(Location = ResponseCacheLocation.None, NoStore = true)]
public ContentResult GetTimeTicks() => Content(
                  DateTime.Now.Ticks.ToString());

上記のコードでは、応答に次のヘッダーが含まれています:

Cache-Control: no-store,no-cache
Pragma: no-cache

アプリのすべての MVC コントローラーまたは ResponseCacheAttribute Pages ページ応答にRazorを適用するには、MVC フィルターまたは Razor Pages フィルターを使用して属性を追加します。

MVC アプリで、次のコードを追加します。

builder.Services.AddControllersWithViews().AddMvcOptions(options => 
    options.Filters.Add(
        new ResponseCacheAttribute
        {
            NoStore = true, 
            Location = ResponseCacheLocation.None
        }));

Razor Pages アプリに適用される方法については、「GitHub dotnet/aspnetcore issue #18890) - 」を参照してください。ただし、MVCのグローバルフィルターリストに ResponseCacheAttribute を追加することは、Razor Pages には適用されません。 この問題のコメントの例は、Minimal API (ASP.NET Core バージョン 6.0) のリリースより前の ASP.NET Core アプリに適用されます。 バージョン 6.0 以降を対象とするアプリの場合は、例で使用するサービス登録をbuilder.Services.AddSingleton... ファイルにするように変更します。

Location プロパティと Duration プロパティ

キャッシュを有効にするには、Duration プロパティを正の値に設定し、LocationAny (既定値) またはClientにする必要があります。 フレームワークによって、Cache-Control ヘッダーが location 値に設定され、その後に応答の max-age が設定されます。

LocationとAnyのClientプロパティ オプションは、それぞれ Cache-Control と public のprivateヘッダー値に変換されます。 NoStore と Location.None セクションで説明したように、Location プロパティを None に設定すると、Cache-Controlヘッダーと Pragma ヘッダーの両方がno-cacheに設定されます。

Location.Any (Cache-Controlpublic に設定) プロパティ設定は、クライアントまたは中間プロキシが値 (応答キャッシュ ミドルウェアなど) をキャッシュできることを示します。

Location.Client (Cache-Controlprivate に設定) プロパティ設定は、クライアントのみが値をキャッシュできることを示します。 応答キャッシュ ミドルウェアを含め、中間キャッシュでは値をキャッシュしないようにします。

キャッシュ 制御ヘッダーは、応答をキャッシュするタイミングと方法に関するガイダンスをクライアントと中間プロキシに提供します。 クライアントとプロキシが RFC 9111: HTTP キャッシュ 仕様を遵守する保証はありません。 応答キャッシュ ミドルウェアは、仕様に定められたキャッシュ規則に常に従います。

次の例は、 Duration プロパティを設定し、既定の Location プロパティ値のままにすることで生成されるヘッダーを示しています。

[Route("api/[controller]/ms")]
[HttpGet]
[ResponseCache(Duration = 10, Location = ResponseCacheLocation.Any, NoStore = false)]
public ContentResult GetTimeMS() => Content(
                  DateTime.Now.Millisecond.ToString());

上記のコードでは、応答に次のヘッダーが含まれています:

Cache-Control: public,max-age=10

キャッシュ プロファイル

多くのコントローラー アクション属性で応答キャッシュ設定を複製する代わりに、MVC ページまたは Razor Pages を設定するときにキャッシュ プロファイルをオプションとして構成できます。 参照されるキャッシュ プロファイルで見つかった値は、 ResponseCacheAttributeによって既定値として使用されます。 属性で指定されたすべてのプロパティは、参照されるキャッシュ プロファイル値をオーバーライドします。

次の例は、30 秒のキャッシュ プロファイルを示しています。

using Microsoft.AspNetCore.Mvc;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddResponseCaching();
builder.Services.AddControllers(options =>
{
    options.CacheProfiles.Add("Default30",
        new CacheProfile()
        {
            Duration = 30
        });
});

var app = builder.Build();

app.UseHttpsRedirection();

// UseCors must be called before UseResponseCaching
//app.UseCors();

app.UseResponseCaching();

app.UseAuthorization();

app.MapControllers();

app.Run();

次のコードは、Default30 キャッシュ プロファイルを参照しています:

[ApiController]
[ResponseCache(CacheProfileName = "Default30")]
public class Time2Controller : ControllerBase
{
    [Route("api/[controller]")]
    [HttpGet]
    public ContentResult GetTime() => Content(
                      DateTime.Now.Millisecond.ToString());

    [Route("api/[controller]/ticks")]
    [HttpGet]
    public ContentResult GetTimeTicks() => Content(
                      DateTime.Now.Ticks.ToString());
}

Default30 キャッシュ プロファイルによる結果のヘッダー応答には、次のものが含まれます:

Cache-Control: public,max-age=30

[ResponseCache] 属性は、 Razor Pages、MVC コントローラー、および MVC アクション メソッドに適用できます。

Razor ページでは、UI アプリで使用されるブラウザーが応答キャッシュを妨げるため、ハンドラー メソッドに属性を適用できません。 MVC アクション メソッドでは、メソッド レベルの属性は、クラス レベルの属性で指定された設定をオーバーライドします。

次のコードでは、[ResponseCache] 属性をコントローラー レベルとメソッド レベルで適用します:

[ApiController]
[ResponseCache(VaryByHeader = "User-Agent", Duration = 30)]
public class Time4Controller : ControllerBase
{
    [Route("api/[controller]")]
    [HttpGet]
    public ContentResult GetTime() => Content(
                      DateTime.Now.Millisecond.ToString());

    [Route("api/[controller]/ticks")]
    [HttpGet]
    public ContentResult GetTimeTicks() => Content(
                  DateTime.Now.Ticks.ToString());

    [Route("api/[controller]/ms")]
    [HttpGet]
    [ResponseCache(Duration = 10, Location = ResponseCacheLocation.Any, NoStore = false)]
    public ContentResult GetTimeMS() => Content(
                      DateTime.Now.Millisecond.ToString());
}

関連するコンテンツ

• キャッシュへの応答の格納 - RFC 9111: HTTP キャッシュ (セクション 3)
• Cache-Control - RFC 9111: HTTP キャッシュ (セクション 5.2)
• ASP.NET Core のメモリ内キャッシュ
• ASP.NET Core の分散キャッシュ
• ASP.NET Core の応答キャッシュミドルウェア