ASP.NET Core でのキャッシュの概要

注

これは、この記事の最新バージョンではありません。 現在のリリースについては、 この記事の .NET 10 バージョンを参照してください。

警告

このバージョンの ASP.NET Core はサポート対象から除外されました。 詳細については、 .NET および .NET Core サポート ポリシーを参照してください。 現在のリリースについては、 この記事の .NET 10 バージョンを参照してください。

作成者: Rick Anderson および Tom Dykstra

この記事では、メモリ内キャッシュ、分散キャッシュ、ハイブリッド キャッシュ、応答キャッシュ、出力キャッシュの概要を ASP.NET Coreで説明します。

メモリ内キャッシュ

メモリ内キャッシュの場合、キャッシュされるデータはサーバー メモリを使用して格納されます。 この種類のキャッシュは、セッション アフィニティを使用する 1 台のサーバーまたは複数のサーバーに適しています。 セッション アフィニティは、スティッキー セッションとも呼ばれます。 セッション アフィニティは、クライアントからの要求が処理のために常に同じサーバーにルーティングされることを意味します。

詳細については、「ASP.NET Core でメモリ内にキャッシュする」と「Azure Application Gateway セッション アフィニティの問題のトラブルシューティング」を参照してください。

分散キャッシュ

アプリがクラウドまたはサーバー ファームでホストされている場合にデータを保存するには分散キャッシュを使用します。 このキャッシュは、要求を処理するサーバー間で共有されます。 クライアントは、クライアントのキャッシュされたデータが使用可能な場合に、グループ内の任意のサーバーによって処理される要求を送信できます。 ASP.NET Core は、SQL Server、 Redis、 Postgres、 および NCache 分散キャッシュと連携します。

詳細については、「ASP.NET Core の分散キャッシュ」を参照してください。

HybridCache

HybridCache API は、IDistributedCache API と IMemoryCache API のギャップを埋めます。 HybridCache は、キャッシュへの保存とキャッシュからの取得のほとんどの側面を処理する既定の実装を持つ抽象クラスです。

HybridCache の機能

HybridCache には、他の API では使用できない次の機能が用意されています。

  • インプロセス キャッシュとアウトプロセス キャッシュの両方に対応する統合 API。

    HybridCache は、既存の IDistributedCache と IMemoryCache の使用に完全に取って代わるように設計されており、新しいキャッシュ コードを追加するための簡単な API を提供します。 アプリに IDistributedCache の実装がある場合、HybridCache サービスはそれをセカンダリ キャッシュ用に使用します。 この 2 段階のキャッシュ戦略により、HybridCache はインメモリ キャッシュの速度と、分散キャッシュや永続キャッシュの持続性を実現できます。

  • スタンピード保護。

    キャッシュ スタンピードは、頻繁に使用されるキャッシュ エントリが取り消され、同じキャッシュ エントリを同時に再入力しようとする要求が多すぎる場合に発生します。 HybridCache は同時実行操作を組み合わせて使用します。これにより、特定の応答のすべての要求が、最初の要求がキャッシュに設定されるまで待機します。

  • 構成可能なシリアル化。

    シリアル化は、サービスの登録の一環として構成され、WithSerializer 呼び出しからチェーンされる WithSerializerFactory および AddHybridCache メソッドを介して型固有シリアライザーと汎用シリアライザーをサポートします。 既定では、サービスは string 型と byte[] 型を内部的に処理し、他のすべての System.Text.Json 名前空間を使用します。 HybridCache は、protobuf や XML など、他の種類のシリアライザー用に構成できます。

HybridCache API が相対的に見てどれほど簡単かを確認するには、これを使用するコードを IDistributedCache を使用するコードと比較してください。 IDistributedCache を使用するとどのようになるかの例を以下に示します。

public class SomeService(IDistributedCache cache)
{
    public async Task<SomeInformation> GetSomeInformationAsync
        (string name, int id, CancellationToken token = default)
    {
        var key = $"someinfo:{name}:{id}"; // Unique key for this combination.
        var bytes = await cache.GetAsync(key, token); // Try to get from cache.
        SomeInformation info;
        if (bytes is null)
        {
            // Cache miss; get the data from the real source.
            info = await SomeExpensiveOperationAsync(name, id, token);

            // Serialize and cache it.
            bytes = SomeSerializer.Serialize(info);
            await cache.SetAsync(key, bytes, token);
        }
        else
        {
            // Cache hit; deserialize it.
            info = SomeSerializer.Deserialize<SomeInformation>(bytes);
        }
        return info;
    }

    // This is the work we're trying to cache.
    private async Task<SomeInformation> SomeExpensiveOperationAsync(string name, int id,
        CancellationToken token = default)
    { /* ... */ }
}

このコードは、シリアライズ化のようなことを含め、適切に動作させるためには毎回多くの努力が必要であることを示しています。 また、"キャッシュ ミス" シナリオでは、最終的に複数の同時実行スレッドが発生する可能性があります。 これらのスレッドはすべてキャッシュミスを受けて、基になるデータを取得し、シリアル化してキャッシュにデータを送信する可能性があります。

HybridCache API を使用する同等のコードを次に示します。

public class SomeService(HybridCache cache)
{
    public async Task<SomeInformation> GetSomeInformationAsync
        (string name, int id, CancellationToken token = default)
    {
        return await cache.GetOrCreateAsync(
            $"someinfo:{name}:{id}", // Unique key for this entry.
            async cancel => await SomeExpensiveOperationAsync(name, id, cancel),
            token: token
        );
    }
}

コードはより簡潔で、ライブラリはIDistributedCacheインターフェイスでは利用できない過負荷保護やその他の機能を提供します。

互換性

HybridCache ライブラリは、.NET Framework 4.7.2 や .NET Standard 2.0 など、以前の.NET ランタイムをサポートしています。

詳細情報

詳細については、次のリソースを参照してください。

応答キャッシュ

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

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

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

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

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

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

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

詳細については、「ASP.NET Core の応答キャッシュ」を参照してください。

出力キャッシュ

出力キャッシュ ミドルウェアを使用すると、HTTP 応答のキャッシュが可能になります。 出力キャッシュは、次の点で応答キャッシュとは異なります。

  • キャッシュ動作は、サーバーで構成できます。

    応答キャッシュ動作は HTTP ヘッダーで定義されます。 たとえば、Chrome または Microsoft Edge で Web サイトを参照すると、ブラウザーは自動的に Cache-control: max-age=0 ヘッダーを送信します。 このヘッダーは、サーバーがクライアントによって提供される指示に従うため、応答キャッシュを効果的に無効にします。 サーバーに新しいキャッシュされた応答がある場合でも、要求ごとに新しい応答が返されます。 出力キャッシュでは、サーバーで構成したキャッシュ動作はクライアントによってオーバーライドされません。

  • キャッシュ ストレージ メディアは拡張可能です。

    既定でメモリーが使用されます。 応答キャッシュはメモリに制限されます。

  • 選択したキャッシュ エントリをプログラムで無効にすることができます。

    応答キャッシュは HTTP ヘッダーに依存しているため、キャッシュ エントリを無効にするオプションはほとんどありません。

  • リソース ロックにより、キャッシュ スタンピードや thundering herd のリスクが軽減されます。

    キャッシュ スタンピードは、頻繁に使用されるキャッシュ エントリが取り消され、同じキャッシュ エントリを同時に再入力しようとする要求が多すぎる場合に発生します。 Thundering herd も似ています。キャッシュエントリにまだ存在しない同じ応答に対する要求が急増する現象です。 リソース ロックにより、特定の応答のすべての要求が、最初の要求がキャッシュに設定されるまで待機します。 応答キャッシュには、リソース ロック機能がありません。

  • キャッシュの再検証により、帯域幅の使用が最小限に抑えられます。

    キャッシュ再検証 は、サーバーがキャッシュされた応答本文ではなく 、304 Not Modified HTTP 状態コードを返すことができるという意味です。 この状態コードは、要求に対する応答が以前に受信されたものと変更されていないことをクライアントに通知します。 応答キャッシュでは、キャッシュの再検証は行われません。

詳細については、「ASP.NET Core の出力キャッシュ ミドルウェア」を参照してください。

キャッシュ タグ ヘルパー

キャッシュ タグ ヘルパーを使用して、MVC ビューまたは Razor ページからのコンテンツをキャッシュします。 キャッシュ タグ ヘルパーは、メモリ内キャッシュを使用してデータを格納します。

詳細については、「ASP.NET Core MVC のキャッシュ タグ ヘルパー」を参照してください。

分散キャッシュ タグ ヘルパー

分散キャッシュ タグ ヘルパーを使用して、分散クラウドまたは Web ファームのシナリオで MVC ビューまたは Razor ページからのコンテンツをキャッシュします。 分散キャッシュ タグ ヘルパーは、SQL Server、Redis、または NCache を使用してデータを格納します。

詳細については、「ASP.NET Core の分散型キャッシュ タグ ヘルパー」を参照してください。

メモリ内キャッシュ

メモリ内キャッシュの場合、キャッシュされるデータはサーバー メモリを使用して格納されます。 この種類のキャッシュは、1 台またはセッション アフィニティを使用する複数のサーバーに適しています。 セッション アフィニティは、スティッキー セッションとも呼ばれます。 セッション アフィニティは、クライアントからの要求が処理のために常に同じサーバーにルーティングされることを意味します。

詳細については、「ASP.NET Core でメモリ内にキャッシュする」と「Azure Application Gateway セッション アフィニティの問題のトラブルシューティング」を参照してください。

分散キャッシュ

アプリがクラウドまたはサーバー ファームでホストされている場合にデータを保存するには分散キャッシュを使用します。 このキャッシュは、要求を処理するサーバー間で共有されます。 クライアントのためのキャッシュされたデータが使用可能な場合、クライアントから送信された要求は、グループ内の任意のサーバーで処理できます。 ASP.NET Core は、SQL Server、 Redis、 Postgres、 および NCache 分散キャッシュと連携します。

詳細については、「ASP.NET Core の分散キャッシュ」を参照してください。

HybridCache

HybridCache API は、IDistributedCache API と IMemoryCache API のギャップを埋めます。 HybridCache は、キャッシュへの保存とキャッシュからの取得のほとんどの側面を処理する既定の実装を持つ抽象クラスです。

HybridCache の機能

HybridCache には、他の API では使用できない次の機能が用意されています。

  • インプロセス キャッシュとアウトプロセス キャッシュの両方に対応する統合 API。

    HybridCache は、既存の IDistributedCache と IMemoryCache の使用に完全に取って代わるように設計されており、新しいキャッシュ コードを追加するための簡単な API を提供します。 アプリに IDistributedCache の実装がある場合、HybridCache サービスはそれをセカンダリ キャッシュ用に使用します。 この 2 段階のキャッシュ戦略により、HybridCache はインメモリ キャッシュの速度と、分散キャッシュや永続キャッシュの持続性を実現できます。

  • スタンピード保護。

    キャッシュ スタンピードは、頻繁に使用されるキャッシュ エントリが取り消され、同じキャッシュ エントリを同時に再入力しようとする要求が多すぎる場合に発生します。 HybridCache は同時実行操作を組み合わせて使用します。これにより、特定の応答のすべての要求が、最初の要求がキャッシュに設定されるまで待機します。

  • 構成可能なシリアル化。

    シリアル化は、サービスの登録の一環として構成され、WithSerializer 呼び出しからチェーンされる WithSerializerFactory および AddHybridCache メソッドを介して型固有シリアライザーと汎用シリアライザーをサポートします。 既定では、サービスは string 型と byte[] 型を内部的に処理し、他のすべての System.Text.Json 名前空間を使用します。 HybridCache は、protobuf や XML など、他の種類のシリアライザー用に構成できます。

HybridCache API が相対的に見てどれほど簡単かを確認するには、これを使用するコードを IDistributedCache を使用するコードと比較してください。 IDistributedCache を使用するとどのようになるかの例を以下に示します。

public class SomeService(IDistributedCache cache)
{
    public async Task<SomeInformation> GetSomeInformationAsync
        (string name, int id, CancellationToken token = default)
    {
        var key = $"someinfo:{name}:{id}"; // Unique key for this combination.
        var bytes = await cache.GetAsync(key, token); // Try to get from cache.
        SomeInformation info;
        if (bytes is null)
        {
            // Cache miss; get the data from the real source.
            info = await SomeExpensiveOperationAsync(name, id, token);

            // Serialize and cache it.
            bytes = SomeSerializer.Serialize(info);
            await cache.SetAsync(key, bytes, token);
        }
        else
        {
            // Cache hit; deserialize it.
            info = SomeSerializer.Deserialize<SomeInformation>(bytes);
        }
        return info;
    }

    // This is the work we're trying to cache.
    private async Task<SomeInformation> SomeExpensiveOperationAsync(string name, int id,
        CancellationToken token = default)
    { /* ... */ }
}

このコードは、シリアライズ化のようなことを含め、適切に動作させるためには毎回多くの努力が必要であることを示しています。 また、"キャッシュ ミス" シナリオでは、最終的に複数の同時実行スレッドが発生する可能性があります。 これらのスレッドはすべてキャッシュミスを受けて、基になるデータを取得し、シリアル化してキャッシュにデータを送信する可能性があります。

HybridCache API を使用する同等のコードを次に示します。

public class SomeService(HybridCache cache)
{
    public async Task<SomeInformation> GetSomeInformationAsync
        (string name, int id, CancellationToken token = default)
    {
        return await cache.GetOrCreateAsync(
            $"someinfo:{name}:{id}", // Unique key for this entry.
            async cancel => await SomeExpensiveOperationAsync(name, id, cancel),
            token: token
        );
    }
}

コードはより簡潔で、ライブラリはIDistributedCacheインターフェイスでは利用できない過負荷保護やその他の機能を提供します。

互換性

HybridCache ライブラリは、.NET Framework 4.7.2 や .NET Standard 2.0 など、以前の.NET ランタイムをサポートしています。

詳細情報

詳細については、次のリソースを参照してください。

キャッシュ タグ ヘルパー

キャッシュ タグ ヘルパーを使用して、MVC ビューまたは Razor ページからのコンテンツをキャッシュします。 キャッシュ タグ ヘルパーは、メモリ内キャッシュを使用してデータを格納します。

詳細については、「ASP.NET Core MVC のキャッシュ タグ ヘルパー」を参照してください。

分散キャッシュ タグ ヘルパー

分散キャッシュ タグ ヘルパーを使用して、分散クラウドまたは Web ファームのシナリオで MVC ビューまたは Razor ページからのコンテンツをキャッシュします。 分散キャッシュ タグ ヘルパーは、SQL Server、Redis、または NCache を使用してデータを格納します。

詳細については、「ASP.NET Core の分散型キャッシュ タグ ヘルパー」を参照してください。

応答キャッシュ

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

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

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

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

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

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

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

出力キャッシュ

出力キャッシュ ミドルウェアを使用すると、HTTP 応答のキャッシュが可能になります。 出力キャッシュは、次の点で応答キャッシュとは異なります。

  • キャッシュの動作は、サーバー上で構成できます。

    応答キャッシュの動作は、HTTP ヘッダーによって定義されます。 たとえば、Chrome または Edge を使用して Web サイトにアクセスすると、ブラウザーから Cache-control: max-age=0 ヘッダーが自動的に送信されます。 このヘッダーは、サーバーがクライアントによって提供される指示に従っているため、応答キャッシュを効果的に無効にします。 サーバーに新しいキャッシュされた応答がある場合でも、要求ごとに新しい応答が返されます。 出力キャッシュでは、サーバーで構成したキャッシュ動作はクライアントによってオーバーライドされません。

  • キャッシュ ストレージ メディアは拡張可能です。

    既定でメモリーが使用されます。 応答キャッシュはメモリに制限されます。

  • 選択したキャッシュ エントリをプログラムで無効にすることができます。

    応答キャッシュの HTTP ヘッダーへの依存により、キャッシュ エントリを無効にするオプションはほとんどありません。

  • リソース ロックにより、キャッシュ スタンピードや thundering herd のリスクが軽減されます。

    キャッシュ スタンピードは、頻繁に使用されるキャッシュ エントリが取り消され、同じキャッシュ エントリを同時に再入力しようとする要求が多すぎる場合に発生します。 Thundering herd も似ています。キャッシュエントリにまだ存在しない同じ応答に対する要求が急増する現象です。 リソース ロックにより、特定の応答のすべての要求が、最初の要求がキャッシュに設定されるまで待機します。 応答キャッシュには、リソース ロック機能がありません。

  • キャッシュの再検証により、帯域幅の使用が最小限に抑えられます。

    キャッシュの再検証とは、サーバーがキャッシュされた応答本文の代わりに 304 Not Modified HTTP 状態コードを返すことができることを意味します。 この状態コードは、要求に対する応答が以前に受信されたものと変更されていないことをクライアントに通知します。 応答キャッシュでは、キャッシュの再検証は行われません。

メモリ内キャッシュ

メモリ内キャッシュの場合、キャッシュされるデータはサーバー メモリを使用して格納されます。 この種類のキャッシュは、1 台またはセッション アフィニティを使用する複数のサーバーに適しています。 セッション アフィニティは、スティッキー セッションとも呼ばれます。 セッション アフィニティは、クライアントからの要求が処理のために常に同じサーバーにルーティングされることを意味します。

詳細については、「ASP.NET Core でメモリ内にキャッシュする」と「Azure Application Gateway セッション アフィニティの問題のトラブルシューティング」を参照してください。

分散キャッシュ

アプリがクラウドまたはサーバー ファームでホストされている場合にデータを保存するには分散キャッシュを使用します。 このキャッシュは、要求を処理するサーバー間で共有されます。 クライアントのためのキャッシュされたデータが使用可能な場合、クライアントから送信された要求は、グループ内の任意のサーバーで処理できます。 ASP.NET Core は、SQL Server、 Redis、 Postgres、 および NCache 分散キャッシュと連携します。

詳細については、「ASP.NET Core の分散キャッシュ」を参照してください。

HybridCache

HybridCache API は、IDistributedCache API と IMemoryCache API のギャップを埋めます。 HybridCache は、キャッシュへの保存とキャッシュからの取得のほとんどの側面を処理する既定の実装を持つ抽象クラスです。

HybridCache の機能

HybridCache には、他の API では使用できない次の機能が用意されています。

  • インプロセス キャッシュとアウトプロセス キャッシュの両方に対応する統合 API。

    HybridCache は、既存の IDistributedCache と IMemoryCache の使用に完全に取って代わるように設計されており、新しいキャッシュ コードを追加するための簡単な API を提供します。 アプリに IDistributedCache の実装がある場合、HybridCache サービスはそれをセカンダリ キャッシュ用に使用します。 この 2 段階のキャッシュ戦略により、HybridCache はインメモリ キャッシュの速度と、分散キャッシュや永続キャッシュの持続性を実現できます。

  • スタンピード保護。

    キャッシュ スタンピードは、頻繁に使用されるキャッシュ エントリが取り消され、同じキャッシュ エントリを同時に再入力しようとする要求が多すぎる場合に発生します。 HybridCache は同時実行操作を組み合わせて使用します。これにより、特定の応答のすべての要求が、最初の要求がキャッシュに設定されるまで待機します。

  • 構成可能なシリアル化。

    シリアル化は、サービスの登録の一環として構成され、WithSerializer 呼び出しからチェーンされる WithSerializerFactory および AddHybridCache メソッドを介して型固有シリアライザーと汎用シリアライザーをサポートします。 既定では、サービスは string 型と byte[] 型を内部的に処理し、他のすべての System.Text.Json 名前空間を使用します。 HybridCache は、protobuf や XML など、他の種類のシリアライザー用に構成できます。

HybridCache API が相対的に見てどれほど簡単かを確認するには、これを使用するコードを IDistributedCache を使用するコードと比較してください。 IDistributedCache を使用するとどのようになるかの例を以下に示します。

public class SomeService(IDistributedCache cache)
{
    public async Task<SomeInformation> GetSomeInformationAsync
        (string name, int id, CancellationToken token = default)
    {
        var key = $"someinfo:{name}:{id}"; // Unique key for this combination.
        var bytes = await cache.GetAsync(key, token); // Try to get from cache.
        SomeInformation info;
        if (bytes is null)
        {
            // Cache miss; get the data from the real source.
            info = await SomeExpensiveOperationAsync(name, id, token);

            // Serialize and cache it.
            bytes = SomeSerializer.Serialize(info);
            await cache.SetAsync(key, bytes, token);
        }
        else
        {
            // Cache hit; deserialize it.
            info = SomeSerializer.Deserialize<SomeInformation>(bytes);
        }
        return info;
    }

    // This is the work we're trying to cache.
    private async Task<SomeInformation> SomeExpensiveOperationAsync(string name, int id,
        CancellationToken token = default)
    { /* ... */ }
}

このコードは、シリアル化などを毎回適切に動作させるために多くの作業が含まれていることを示しています。 また、"キャッシュ ミス" シナリオでは、最終的に複数の同時実行スレッドが発生する可能性があります。 これらのスレッドはすべてキャッシュミスが発生し、基になるデータをフェッチし、シリアル化し、キャッシュにデータを送信することがあります。

HybridCache API を使用する同等のコードを次に示します。

public class SomeService(HybridCache cache)
{
    public async Task<SomeInformation> GetSomeInformationAsync
        (string name, int id, CancellationToken token = default)
    {
        return await cache.GetOrCreateAsync(
            $"someinfo:{name}:{id}", // Unique key for this entry.
            async cancel => await SomeExpensiveOperationAsync(name, id, cancel),
            token: token
        );
    }
}

コードはよりシンプルで、ライブラリはフラッド防止機能と、IDistributedCache インターフェイスでは使用できない他の機能を提供します。

互換性

HybridCache ライブラリは、.NET Framework 4.7.2 や .NET Standard 2.0 など、以前の.NET ランタイムをサポートしています。

詳細情報

詳細については、次のリソースを参照してください。

キャッシュ タグ ヘルパー

キャッシュ タグ ヘルパーを使用して、MVC ビューまたは Razor ページからのコンテンツをキャッシュします。 キャッシュ タグ ヘルパーは、メモリ内キャッシュを使用してデータを格納します。

詳細については、「ASP.NET Core MVC のキャッシュ タグ ヘルパー」を参照してください。

分散キャッシュ タグ ヘルパー

分散キャッシュ タグ ヘルパーを使用して、分散クラウドまたは Web ファームのシナリオで MVC ビューまたは Razor ページからのコンテンツをキャッシュします。 分散キャッシュ タグ ヘルパーは、SQL Server、Redis、または NCache を使用してデータを格納します。

詳細については、「ASP.NET Core の分散型キャッシュ タグ ヘルパー」を参照してください。

応答キャッシュ

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

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

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

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

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

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

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

出力キャッシュ

出力キャッシュ は、.NET 7 以降で使用できます。

関連するコンテンツ

  • Last updated on