Zwischenspeichern von Antworten in ASP.NET Core

Von John Luo, Rick Andersonund Steve Smith

Anzeigen oder Herunterladen von Beispielcode (Vorgehensweise zum Herunterladen)

Die Zwischenspeicherung von Antworten reduziert die Anzahl der Anforderungen, die ein Client oder Proxy an einen Webserver stellt. Das Zwischenspeichern von Antworten reduziert auch die Arbeitsaufwand, die der Webserver zum Generieren einer Antwort ausführt. Die Zwischenspeicherung von Antworten wird durch Header gesteuert, die angeben, wie Antworten von Client, Proxy und Middleware zwischengespeichert werden sollen.

Das ResponseCache-Attribut ist am Festlegen von Headern für das Zwischenspeichern von Antworten beteiligt. Clients und Zwischenproxys sollten die Header für das Zwischenspeichern von Antworten gemäß der HTTP 1.1 Caching-Spezifikationberü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 serverseitige Cacheverhalten zu beeinflussen.

HTTP-basiertes Zwischenspeichern von Antworten

Die HTTP 1.1 Caching-Spezifikation beschreibt, wie sich Internetcaches verhalten sollten. Der primäre HTTP-Header, der für das Zwischenspeichern verwendet wird, ist Cache-Control,der zum Angeben von Cachedirektiven verwendet wird. Die -Direktiven steuern das Verhalten beim Zwischenspeichern, wenn Anforderungen ihren Weg von Clients zu Servern und als Antworten von Servern zurück zu Clients herstellen. Anforderungen und Antworten werden über Proxyserver übertragen, und Proxyserver müssen auch der HTTP 1.1-Cachingspezifikation entsprechen.

Allgemeine Cache-Control Anweisungen sind in der folgenden Tabelle dargestellt.

Anweisung Aktion
public Ein Cache kann die Antwort speichern.
private Die Antwort darf nicht von 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)
kein 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 im Cache.

Bei Antworten: Die Antwort darf nicht für eine nachfolgende Anforderung ohne Überprüfung 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.

Andere Cacheheader, die beim Zwischenspeichern eine Rolle spielen, sind in der folgenden Tabelle dargestellt.

Header Funktion
Age (Alter) Eine Schätzung der Zeitspanne in Sekunden, seit die Antwort auf dem Ursprungsserver generiert oder erfolgreich überprüft wurde.
Abläuft Die Zeit, nach der die Antwort als veraltet betrachtet wird.
Pragma Ist aus Gründen der Abwärtskompatibilität mit HTTP/1.0-Caches zum Festlegen no-cache des Verhaltens vorhanden. 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-basierte Zwischenspeicherung beachtet Anforderungen Cache-Control-Direktiven.

Die HTTP 1.1-Cachingspezifikation für den Cache-Control-Header erfordert einen Cache, um einen gültigen Header zu erfüllen, Cache-Control der vom Client gesendet wird. Ein Client kann Anforderungen mit einem Headerwert stellen no-cache und erzwingen, dass der Server für jede Anforderung eine neue Antwort generiert.

Es ist Cache-Control sinnvoll, Clientanforderungsheader immer zu berücksichtigen, 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 über ein Netzwerk von Clients, Proxys und Servern reduzieren. Dies ist nicht unbedingt eine Möglichkeit, die Last auf einem Ursprungsserver zu steuern.

Bei Verwendung der Middleware für das Zwischenspeichern von Antworten gibt es keine Kontrolle durch Entwickler über dieses Zwischenspeicherverhalten, da die Middleware der offiziellen Cachespezifikation entspricht. Die Unterstützung der Ausgabezwischenspeicherung zur besseren Steuerung der Serverauslastung ist ein Entwurf für eine zukünftige Version von ASP.NET Core. Weitere Informationen finden Sie unter Hinzufügen von Unterstützung für die Ausgabezwischenspeicherung (dotnet/aspnetcore #27387).

Andere Cachingtechnologie in ASP.NET Core

In-Memory-Caching

Beim Zwischenspeichern im Arbeitsspeicher wird Serverspeicher zum Speichern zwischengespeicherter Daten verwendet. Diese Art der Zwischenspeicherung eignet sich für einen einzelnen Server oder mehrere Server mithilfe von Sticky Sessions. Sticky Sessions bedeutet, dass die Anforderungen von einem Client zur Verarbeitung immer an denselben Server weitergeleitet werden.

Weitere Informationen finden Sie unter Zwischenspeichern im Arbeitsspeicher in ASP.NET Core.

Verteilter Cache

Verwenden Sie einen verteilten Cache, um Daten im Arbeitsspeicher zu speichern, wenn die App in einer Cloud- oder Serverfarm gehostet wird. Der Cache wird von den Servern gemeinsam genutzt, die Anforderungen verarbeiten. Ein Client kann eine Anforderung übermitteln, die von einem beliebigen Server in der Gruppe verarbeitet wird, wenn zwischengespeicherte Daten für den Client verfügbar sind. ASP.NET Core funktioniert mit verteilten Caches für SQL Server, Redisund NCache.

Weitere Informationen finden Sie unter Verteiltes Zwischenspeichern in ASP.NET Core.

Cache-Taghilfsprogramm

Zwischenspeichern des Inhalts aus einer MVC-Ansicht oder Razor -Seite mit dem Cachetaghilfs-Hilfgeber. Das Cache-Taghilfsmodul verwendet das Zwischenspeichern im Arbeitsspeicher, um Daten zu speichern.

Weitere Informationen finden Sie unter Cache-Taghilfsprogramm im ASP.NET Core MVC.

Taghilfsprogramm für verteilten Cache

Zwischenspeichern des Inhalts aus einer MVC-Ansicht oder Razor -Seite in verteilten Cloud- oder Webfarmszenarien mit dem Taghilfs-Tool für verteilten Cache. Das Taghilf hilft für verteilte Caches verwendet SQL Server, Redisoder NCache, um Daten zu speichern.

Weitere Informationen finden Sie unter Taghilfsprogramm für verteilten Cache in ASP.NET Core.

ResponseCache-Attribut

ResponseCacheAttributeGibt 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 oder der Anmeldung eines Benutzers ändern.

VaryByQueryKeys variiert die gespeicherte Antwort durch die Werte der angegebenen Liste von Abfrageschlüsseln. Wenn ein einzelner Wert von * angegeben wird, variiert die Middleware die Antworten durch alle Parameter der Anforderungsabfragezeichenfolge.

Middleware für das Zwischenspeichern von Antworten muss aktiviert sein, um die VaryByQueryKeys -Eigenschaft festzulegen. Andernfalls wird eine Laufzeitausnahme ausgelöst. Es gibt keinen entsprechenden HTTP-Header für die VaryByQueryKeys -Eigenschaft. Die -Eigenschaft ist ein HTTP-Feature, das von middleware für das Zwischenspeichern von Antworten verarbeitet wird. Damit die Middleware eine zwischengespeicherte Antwort bedienen kann, müssen die Abfragezeichenfolge und der Abfragezeichenfolgenwert mit einer vorherigen Anforderung übereinstimmen. Betrachten Sie beispielsweise die Reihenfolge der Anforderungen und Ergebnisse, die in der folgenden Tabelle angezeigt werden.

Anforderung Ergebnis
http://example.com?key1=value1 Wird vom Server zurückgegeben.
http://example.com?key1=value1 Von Middleware zurückgegeben.
http://example.com?key1=value2 Wird vom Server zurückgegeben.

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 Wert der Abfragezeichenfolge nicht mit einer vorherigen Anforderung übereinstimmt.

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

  • Entfernt alle vorhandenen Header für Vary Cache-Control , und Pragma .
  • Schreibt die entsprechenden Header basierend auf den in der festgelegten ResponseCacheAttribute Eigenschaften.
  • Aktualisiert die HTTP-Funktion zum Zwischenspeichern von Antworten, wenn VaryByQueryKeys festgelegt ist.

Variieren

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

[ResponseCache(VaryByHeader = "User-Agent", Duration = 30)]
public class Cache1Model : PageModel
{

Zeigen Sie mithilfe der Beispiel-App die Antwortheader mit den Netzwerktools des Browsers an. Die folgenden Antwortheader werden mit der Cache1-Seitenantwort gesendet:

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

NoStore und Location.None

NoStore überschreibt die meisten anderen Eigenschaften. Wenn diese Eigenschaft auf festgelegt true ist, wird der Cache-Control Header auf no-store festgelegt. Wenn Location auf festgelegt None ist:

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

Wenn NoStore ist false und Location None Cache-Control ist, werden und auf Pragma no-cache festgelegt.

NoStore ist in der Regel für Fehlerseiten auf true festgelegt. Die Cache2-Seite in der Beispiel-App erzeugt Antwortheader, die den Client anweisen, die Antwort nicht zu speichern.

[ResponseCache(Duration = 0, Location = ResponseCacheLocation.None, NoStore = true)]
public class Cache2Model : PageModel
{

Die Beispiel-App gibt die Seite Cache2 mit den folgenden Headern zurück:

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

Standort und Dauer

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

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

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

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

Cachesteuerelementheader stellen lediglich Anleitungen für Clients und Zwischenproxys bereit, wann und wie Antworten zwischengespeichert werden. Es gibt keine Garantie, dass Clients und Proxys die HTTP 1.1 Caching-Spezifikationeinhalten. Die Middleware für das Zwischenspeichern von Antworten folgt immer den Incachingregeln, die in der Spezifikation festgelegt sind.

Das folgende Beispiel zeigt das Cache3-Seitenmodell aus der Beispiel-App und die Header, die durch Festlegen Duration und Belassen des Standardwerts erzeugt Location werden:

[ResponseCache(Duration = 10, Location = ResponseCacheLocation.Any, NoStore = false)]
public class Cache3Model : PageModel
{

Die Beispiel-App gibt die Seite Cache3 mit dem folgenden Header zurück:

Cache-Control: public,max-age=10

Cacheprofile

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

Richten Sie ein Cacheprofil ein. Das folgende Beispiel zeigt ein 30-Sekunden-Cacheprofil im der Beispiel-App Startup.ConfigureServices :

public void ConfigureServices(IServiceCollection services)
{
    services.AddRazorPages();
    services.AddMvc(options =>
    {
        options.CacheProfiles.Add("Default30",
            new CacheProfile()
            {
                Duration = 30
            });
    });
}
public void ConfigureServices(IServiceCollection services)
{
    services.AddMvc(options =>
    {
        options.CacheProfiles.Add("Default30",
            new CacheProfile()
            {
                Duration = 30
            });
    }).SetCompatibilityVersion(CompatibilityVersion.Version_2_2);
}

Das Cache4-Seitenmodell der Beispiel-App verweist auf das Default30 Cacheprofil:

[ResponseCache(CacheProfileName = "Default30")]
public class Cache4Model : PageModel
{

Kann ResponseCacheAttribute auf Folgendes angewendet werden:

  • Razor Pages: Attribute können nicht auf Handlermethoden angewendet werden.
  • MVC-Controller.
  • MVC-Aktionsmethoden: Attribute auf Methodenebene überschreiben die in Attributen auf Klassenebene angegebenen Einstellungen.

Der resultierende Header, der vom Cacheprofil auf die Cache4-Seitenantwort angewendet Default30 wird:

Cache-Control: public,max-age=30

Zusätzliche Ressourcen