Zwischenspeichern von Antworten in ASP.NET Core

Von Rick Anderson und Kirk Larkin

Anzeigen oder Herunterladen von Beispielcode (Vorgehensweise zum Herunterladen)

Das Zwischenspeichern von Antworten reduziert die Anzahl der Anforderungen, die ein Client oder Proxy an einen Webserver sendet. Das Zwischenspeichern von Antworten verringert auch den Arbeitsaufwand, den der Webserver zum Generieren einer Antwort ausführt. Das Zwischenspeichern von Antworten wird in Headern festgelegt.

Das ResponseCache-Attribut legt Antwortzwischenspeicherungsheader fest. Clients und Zwischenproxys sollten die Header für das Zwischenspeichern von Antworten unter RFC 9111: HTTP-Zwischenspeicherung berücksichtigen.

Verwenden Sie für die serverseitige Zwischenspeicherung, die der HTTP 1.1-Zwischenspeicherungsspezifikation folgt, Middleware für das Zwischenspeichern von Antworten. Die Middleware kann die Eigenschaften verwenden, um das ResponseCacheAttribute Verhalten des serverseitigen Zwischenspeicherns zu beeinflussen.

Die Middleware zum Zwischenspeichern von Antworten:

• Ermöglicht das Zwischenspeichern von Serverantworten basierend auf HTTP-Cacheheadern. Implementiert die standardmäßige HTTP-Zwischenspeicherungssemantik. Caches basierend auf HTTP-Cacheheadern wie Proxys.
• Ist in der Regel nicht vorteilhaft für Benutzeroberflächen-Apps wie Razor Pages, da Browser im Allgemeinen Anforderungsheader festlegen, die das Zwischenspeichern verhindern. Die Ausgabezwischenspeicherung, die in ASP.NET Core 7.0 und höher verfügbar ist, kommt UI-Apps zugute. Bei der Ausgabezwischenspeicherung entscheidet die Konfiguration unabhängig von HTTP-Headern, was zwischengespeichert werden soll.
• Kann für öffentliche GET- oder HEAD-API-Anforderungen von Clients von Vorteil sein, bei denen die Bedingungen für die Zwischenspeicherung erfüllt sind.

Verwenden Sie zum Testen der Antwortzwischenspeicherung Fiddler, Postman oder ein anderes Tool, das Anforderungsheader explizit festlegen kann. Das explizite Festlegen von Headern wird zum Testen der Zwischenspeicherung bevorzugt. Weitere Informationen finden Sie unter Problembehandlung.

HTTP-basiertes Zwischenspeichern von Antworten

RFC 9111: HTTP-Zwischenspeicherung beschreibt das Verhalten von Internetcaches. Der primäre HTTP-Header, der für das Zwischenspeichern verwendet wird, ist Cache-Control, das zum Angeben von Cachedirektiven verwendet wird. Die -Direktiven steuern das Zwischenspeicherungsverhalten, wenn Anforderungen von Clients zu Servern weitergeleitet werden und wenn Antworten von Servern wieder zu Clients weitergeleitet werden. Anforderungen und Antworten werden über Proxyserver verschoben, und Proxyserver müssen auch der HTTP 1.1-Cachespezifikation entsprechen.

Allgemeine Cache-Control Anweisungen sind in der folgenden Tabelle aufgeführt.

Anweisung	Aktion
Public	Die Antwort kann in einem Cache gespeichert werden.
private	Die Antwort darf nicht in einem freigegebenen Cache gespeichert werden. Ein privater Cache kann die Antwort speichern und wiederverwenden.
max-age	Der Client akzeptiert keine Antwort, deren Alter größer als die angegebene Anzahl von Sekunden ist. Beispiele: max-age=60 (60 Sekunden), max-age=2592000 (1 Monat)
no-cache	Bei Anforderungen: Ein Cache darf keine gespeicherte Antwort verwenden, um die Anforderung zu erfüllen. Der Ursprungsserver generiert die Antwort für den Client neu, und die Middleware aktualisiert die gespeicherte Antwort in seinem Cache. Bei Antworten: Die Antwort darf nicht für eine nachfolgende Anforderung ohne Validierung auf dem Ursprungsserver verwendet werden.
no-store	Bei Anforderungen: Ein Cache darf die Anforderung nicht speichern. Bei Antworten: Ein Cache darf keinen Teil der Antwort speichern.

Weitere Cacheheader, die beim Zwischenspeichern eine Rolle spielen, sind in der folgenden Tabelle aufgeführt.

Header	Funktion
Age (Alter)	Eine Schätzung der Zeitspanne in Sekunden, seit die Antwort auf dem Ursprungsserver generiert oder erfolgreich überprüft wurde.
Läuft ab	Die Zeit, nach der die Antwort als veraltet betrachtet wird.
Pragma	Dient zur Abwärtskompatibilität mit HTTP/1.0-Caches zum Festlegen no-cache des Verhaltens. Wenn der Cache-Control Header vorhanden ist, wird der Pragma Header ignoriert.
Variieren	Gibt an, dass eine zwischengespeicherte Antwort nur gesendet werden darf, wenn alle Vary Headerfelder sowohl in der ursprünglichen Anforderung der zwischengespeicherten Antwort als auch in der neuen Anforderung übereinstimmen.

HTTP-basiertes Zwischenspeichern berücksichtigt Anforderungs-Cache-Control-Anweisungen

RFC 9111: HTTP-Zwischenspeicherung (Abschnitt 5.2. Cache-Control) erfordert einen Cache, um einen gültigen Cache-Control Header zu berücksichtigen, der vom Client gesendet wird. Ein Client kann Anforderungen mit einem no-cache Headerwert senden und den Server erzwingen, eine neue Antwort für jede Anforderung zu generieren.

Die Berücksichtigung von Clientanforderungsheadern Cache-Control ist sinnvoll, wenn Sie das Ziel der HTTP-Zwischenspeicherung in Betracht ziehen. Gemäß der offiziellen Spezifikation soll das Zwischenspeichern die Latenz und den Netzwerkaufwand für die Erfüllung von Anforderungen in einem Netzwerk von Clients, Proxys und Servern reduzieren. Dies ist nicht unbedingt eine Möglichkeit, die Last auf einem Ursprungsserver zu steuern.

Es gibt keine Entwicklerkontrolle über dieses Zwischenspeicherungsverhalten bei Verwendung der Middleware für die Antwortzwischenspeicherung , da die Middleware der offiziellen Zwischenspeicherungsspezifikation entspricht. Unterstützung für die Ausgabezwischenspeicherung zur besseren Steuerung der Serverlast wurde in .NET 7 hinzugefügt. Weitere Informationen finden Sie unter Ausgabezwischenspeicherung.

ResponseCache-Attribut

ResponseCacheAttribute Gibt die Parameter an, die zum Festlegen geeigneter Header beim Zwischenspeichern von Antworten erforderlich sind.

Warnung

Deaktivieren Sie die Zwischenspeicherung für Inhalte, die Informationen für authentifizierte Clients enthalten. Das Zwischenspeichern sollte nur für Inhalte aktiviert werden, die sich nicht basierend auf der Identität eines Benutzers ändern oder ob ein Benutzer angemeldet ist.

VaryByQueryKeys variiert die gespeicherte Antwort anhand der Werte der angegebenen Liste von Abfrageschlüsseln. Wenn ein einzelner Wert von * bereitgestellt wird, variiert die Middleware die Antworten nach allen Abfragezeichenfolgenparametern der Anforderung.

Die Middleware für das Zwischenspeichern von Antworten muss aktiviert sein, um die VaryByQueryKeys Eigenschaft festzulegen. Andernfalls wird eine Laufzeit-Ausnahme ausgelöst. Es gibt keinen entsprechenden HTTP-Header für die VaryByQueryKeys Eigenschaft. Die -Eigenschaft ist ein HTTP-Feature, das von der Middleware für die Antwortzwischenspeicherung behandelt wird. Damit die Middleware eine zwischengespeicherte Antwort bereitstellen kann, müssen die Abfragezeichenfolge und der Wert der Abfragezeichenfolge mit einer vorherigen Anforderung übereinstimmen. Betrachten Sie beispielsweise die Reihenfolge der Anforderungen und Ergebnisse, die in der folgenden Tabelle dargestellt sind:

Anforderung	Zurückgegeben von
http://example.com?key1=value1	Server
http://example.com?key1=value1	Middleware
http://example.com?key1=NewValue	Server

Die erste Anforderung wird vom Server zurückgegeben und in Middleware zwischengespeichert. Die zweite Anforderung wird von middleware zurückgegeben, da die Abfragezeichenfolge mit der vorherigen Anforderung übereinstimmt. Die dritte Anforderung befindet sich nicht im Middlewarecache, da der Abfragezeichenfolgenwert nicht mit einer vorherigen Anforderung übereinstimmt.

Wird ResponseCacheAttribute verwendet, um (über IFilterFactory) eine Microsoft.AspNetCore.Mvc.Internal.ResponseCacheFilterzu konfigurieren und zu erstellen. Die ResponseCacheFilter führt die Aktualisierung der entsprechenden HTTP-Header und -Features der Antwort durch. Der Filter:

• Entfernt alle vorhandenen Header für Vary, Cache-Controlund Pragma.
• Schreibt die entsprechenden Header basierend auf den eigenschaften, die in festgelegt sind ResponseCacheAttribute.
• Aktualisierungen das HTTP-Feature für die Antwortzwischenspeicherung, wenn VaryByQueryKeys festgelegt ist.

Variieren

Dieser Header wird nur geschrieben, wenn die VaryByHeader -Eigenschaft festgelegt ist. Die -Eigenschaft, die auf den Wert der Vary Eigenschaft festgelegt ist. Im folgenden Beispiel wird die VaryByHeader -Eigenschaft verwendet:

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

Zeigen Sie die Antwortheader mit Fiddler oder einem anderen Tool an. Die Antwortheader umfassen:

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

Der obige Code erfordert das Hinzufügen der Middlewaredienste AddResponseCaching für die Antwortzwischenspeicherung zur Dienstsammlung und konfiguriert die App für die Verwendung der Middleware mit der UseResponseCaching Erweiterungsmethode.

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 und Location.None

NoStore überschreibt die meisten anderen Eigenschaften. Wenn diese Eigenschaft auf truefestgelegt ist, wird der Cache-Control Header auf no-storefestgelegt. Wenn Location auf Nonefestgelegt ist:

• Für Cache-Control ist no-store,no-cache festgelegt.
• Für Pragma ist no-cache festgelegt.

false Wenn NoStore und NoneLocation ist , Cache-Controlund Pragma sind auf no-cachefestgelegt.

NoStore wird für Fehlerseiten in der Regel auf true festgelegt. Im Folgenden werden Antwortheader erzeugt, die den Client anweisen, die Antwort nicht zu speichern.

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

Der vorangehende Code enthält die folgenden Header in der Antwort:

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

Um die ResponseCacheAttribute auf alle MVC-Controller- oder Razor Seitenantworten der App anzuwenden, fügen Sie es mit einem MVC-Filter oder Razor Seitenfilter hinzu.

In einer MVC-App:

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

Einen Ansatz, der für Razor Pages-Apps gilt, finden Sie unter Hinzufügen ResponseCacheAttribute zu einer globalen MVC-Filterliste gilt nicht für Razor Seiten (dotnet/aspnetcore #18890). Das im Problemkommentar bereitgestellte Beispiel wurde für Apps mit ASP.NET Core vor der Veröffentlichung von Minimal-APIs in Version 6.0 geschrieben. Ändern Sie für Apps der Version 6.0 oder höher die Dienstregistrierung im Beispiel in builder.Services.AddSingleton... für Program.cs.

Standort und Dauer

Um die Zwischenspeicherung zu aktivieren, Duration muss auf einen positiven Wert festgelegt werden und Location muss entweder Any (Standard) oder Clientsein. Das Framework legt den Cache-Control Header auf den Location-Wert gefolgt von der max-age der Antwort fest.

Locationdie Optionen von Any und Client übersetzen sie in Cache-Control Headerwerte von public bzw private. . Wie im Abschnitt "NoStore" und "Location.None" erwähnt, legt die Einstellung Location auf None sowohl als Pragma auch Cache-Control -Header auf festno-cache.

Location.Any (Cache-Control auf publicfestgelegt) gibt an, dass der Client oder ein zwischengeschalteter Proxy den Wert zwischenspeichern kann, einschließlich Der Middleware für das Zwischenspeichern von Antworten.

Location.Client (Cache-Control auf privatefestgelegt) gibt an, dass nur der Client den Wert zwischenspeichern darf. Kein Zwischencache sollte den Wert zwischenspeichern, einschließlich der Middleware für das Zwischenspeichern von Antworten.

Cachesteuerelementheader bieten Clients und zwischengeschalteten Proxys Anleitungen, wann und wie Antworten zwischengespeichert werden. Es gibt keine Garantie, dass Clients und Proxys RFC 9111: HTTP Caching berücksichtigen. Die Middleware für die Antwortzwischenspeicherung folgt immer den in der Spezifikation festgelegten Zwischenspeicherungsregeln.

Das folgende Beispiel zeigt die Header, die durch Festlegen Duration und Belassen des Standardwerts Location erzeugt werden:

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

Der vorangehende Code enthält die folgenden Header in der Antwort:

Cache-Control: public,max-age=10

Cacheprofile

Anstatt die Antwortcacheeinstellungen für viele Controlleraktionsattribute zu duplizieren, können Cacheprofile beim Einrichten von MVC/Razor Pages als Optionen konfiguriert werden. Werte in einem Cacheprofil, auf das verwiesen wird, werden von als Standardwerte verwendet und von allen Eigenschaften überschrieben ResponseCacheAttribute , die für das Attribut angegeben sind.

Das folgende Beispiel zeigt ein Cacheprofil von 30 Sekunden:

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();

Der folgende Code verweist auf das Default30 Cacheprofil:

[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());
}

Die resultierende Headerantwort des Default30 Cacheprofils umfasst Folgendes:

Cache-Control: public,max-age=30

Das [ResponseCache] Attribut kann auf Folgendes angewendet werden:

• Razor Pages: Attribute können nicht auf Handlermethoden angewendet werden. Browser, die mit Benutzeroberflächen-Apps verwendet werden, verhindern das Zwischenspeichern von Antworten.
• MVC-Controller.
• MVC-Aktionsmethoden: Attribute auf Methodenebene setzen die einstellungen außer Kraft, die in Attributen auf Klassenebene angegeben sind.

Der folgende Code wendet das [ResponseCache] Attribut auf Controller- und Methodenebene an:

[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());
}

Zusätzliche Ressourcen

• Speichern von Antworten in Caches
• Cachesteuerung
• Zwischenspeichern im Arbeitsspeicher in ASP.NET Core
• Verteiltes Zwischenspeichern in ASP.NET Core
• Erkennen von Änderungen mit Änderungstoken in ASP.NET Core
• Middleware für das Zwischenspeichern von Antworten in ASP.NET Core
• Cache-Taghilfsprogramm im ASP.NET Core MVC
• Taghilfsprogramm für verteilten Cache in ASP.NET Core