Antwortkomprimierung in ASP.NET Core

Die Netzwerkbandbreite ist eine begrenzte Ressource. Die Verringerung der Größe der Antwort erhöht in der Regel die Reaktionsfähigkeit einer App, oft dramatisch. Eine Möglichkeit zum Reduzieren der Nutzlastgrößen besteht darin, die Antworten einer App zu komprimieren.

Komprimierung mit HTTPS

Komprimierte Antworten über sichere Verbindungen können mit der EnableForHttps Option gesteuert werden, die standardmäßig aufgrund des Sicherheitsrisikos deaktiviert ist. Die Verwendung der Komprimierung mit dynamisch generierten Seiten kann die App für CRIME und BREACH Angriffe verfügbar machen. CRIMEund BREACH Angriffe können in ASP.NET Core mit Antiforgery-Token reduziert werden. Weitere Informationen finden Sie unter Prevent Cross-Site Request Forgery (XSRF/CSRF) Attacks in ASP.NET Core (Verhindern von websiteübergreifenden Anforderungsfälschungen (XSRF/CSRF) in ASP.NET Core). Informationen zur Entschärfung von BREACH Angriffen finden Sie unter "Entschärfungen" unter http://www.breachattack.com/

Selbst wenn EnableForHttps in der App, IIS, IIS Express und Azure App Service gzip auf den IIS-Webserver angewendet werden kann. Beachten Sie beim Überprüfen von Antwortheadern den Serverwert . Ein unerwarteter content-encoding Antwortheaderwert kann das Ergebnis des Webservers und nicht die ASP.NET Core App-Konfiguration sein.

Verwenden der Antwortkomprimierungs-Middleware

Verwenden Sie serverbasierte Antwortkomprimierungstechnologien in IIS, Apache oder Nginx. Die Leistung der Antwortkomprimierungs-Middleware entspricht wahrscheinlich nicht dem der Servermodule. HTTP.sys Server und Kestrel Server bieten derzeit keine integrierte Komprimierungsunterstützung.

Verwenden Sie Die Antwortkomprimierungs-Middleware, wenn die App lautet:

Antwortkomprimierung

In der Regel kann jede Antwort, die nicht systemintern komprimiert wird, von der Antwortkomprimierung profitieren. Antworten, die nicht systemeigene komprimiert werden, umfassen in der Regel CSS, JavaScript, HTML, XML und JSON. Komprimieren Sie nicht systemeigene komprimierte Ressourcen, z. B. PNG-Dateien. Wenn Sie versuchen, eine systemeigene komprimierte Antwort weiter zu komprimieren, wird jede kleine zusätzliche Reduzierung der Größe und Übertragungszeit wahrscheinlich durch die Zeit überschattet, die es benötigt, um die Komprimierung zu verarbeiten. Komprimieren Sie dateien nicht kleiner als etwa 150-1000 Bytes, je nach Inhalt der Datei und der Effizienz der Komprimierung. Der Aufwand der Komprimierung kleiner Dateien kann eine komprimierte Datei erzeugen, die größer als die nicht komprimierte Datei ist.

Wenn ein Client komprimierte Inhalte verarbeiten kann, muss der Client den Server seiner Funktionen informieren, indem er den Header mit der Anforderung sendet Accept-Encoding . Wenn ein Server komprimierte Inhalte sendet, muss er Informationen in die Content-Encoding Kopfzeile einschließen, wie die komprimierte Antwort codiert ist. Inhaltscodierungsbezeichnungen, die von der Antwortkomprimierungs-Middleware unterstützt werden, werden in der folgenden Tabelle angezeigt.

Accept-Encoding Kopfzeilenwerte Middleware unterstützt BESCHREIBUNG
br Ja (Standard) Brotli komprimiertes Datenformat
deflate Nein Komprimiertes Datenformat DEFLATE
exi Nein W3C-effizienter XML-Austausch
gzip Ja Gzip-Dateiformat
identity Ja Bezeichner "Keine Codierung": Die Antwort darf nicht codiert werden.
pack200-gzip Nein Netzwerkübertragungsformat für Java-Archive
* Ja Alle verfügbaren Inhaltscodierungen werden nicht explizit angefordert.

Weitere Informationen finden Sie in der offiziellen Inhaltscodierungsliste von IANA.

Die Antwortkomprimierungs-Middleware ermöglicht das Hinzufügen zusätzlicher Komprimierungsanbieter für benutzerdefinierte Accept-Encoding Headerwerte. Weitere Informationen finden Sie unter Benutzerdefinierte Anbieter in diesem Artikel.

Die Antwortkomprimierungs-Middleware ist in der Lage, auf den Qualitätswert (qvalue, ) zu reagieren, qwenn der Client gesendet wird, um Komprimierungsschemas zu priorisieren. Weitere Informationen finden Sie unter RFC 7231: Accept-Encoding.

Komprimierungsalgorithmen unterliegen einem Handel zwischen Komprimierungsgeschwindigkeit und Wirksamkeit der Komprimierung. Die Wirksamkeit in diesem Zusammenhang bezieht sich auf die Größe der Ausgabe nach der Komprimierung. Die kleinste Größe wird durch die optimale Komprimierung erreicht.

Die Kopfzeilen, die beim Anfordern, Senden, Zwischenspeichern und Empfangen komprimierter Inhalte enthalten sind, werden in der folgenden Tabelle beschrieben.

Header Role
Accept-Encoding Gesendet vom Client an den Server, um die für den Client zulässigen Inhaltscodierungsschemas anzugeben.
Content-Encoding Vom Server an den Client gesendet, um die Codierung des Inhalts in der Nutzlast anzugeben.
Content-Length Wenn die Komprimierung auftritt, wird die Kopfzeile entfernt, da sich der Content-Length Textkörperinhalt ändert, wenn die Antwort komprimiert wird.
Content-MD5 Wenn die Komprimierung auftritt, wird die Kopfzeile entfernt, da der Content-MD5 Textkörperinhalt geändert wurde und der Hash nicht mehr gültig ist.
Content-Type Gibt den MIME-Typ des Inhalts an. Jede Antwort sollte seine Content-TypeAngabe angeben. Die Antwortkomprimierungs-Middleware überprüft diesen Wert, um festzustellen, ob die Antwort komprimiert werden soll. Die Reaktionskomprimierungs-Middleware gibt einen Satz von Standard-MIME-Typen an, die codiert werden können, und sie können ersetzt oder hinzugefügt werden.
Vary Wenn der Server mit einem Wert an Accept-Encoding Clients und Proxies gesendet wird, gibt der Vary Header an, dass er die Antworten zwischenspeichern (variieren) sollte, basierend auf dem Wert des Accept-Encoding Headers der Anforderung. Das Ergebnis der Rückgabe von Inhalten mit der Vary: Accept-Encoding Kopfzeile ist, dass sowohl komprimierte als auch nicht komprimierte Antworten separat zwischengespeichert werden.

Erkunden Sie die Features der Response-Komprimierungs-Middleware mit der Beispiel-App. Das Beispiel veranschaulicht:

  • Die Komprimierung von App-Antworten mithilfe von Gzip- und benutzerdefinierten Komprimierungsanbietern.
  • So fügen Sie einem MIME-Typ die Standardliste der MIME-Typen für die Komprimierung hinzu.
  • So fügen Sie einen benutzerdefinierten Antwortkomprimierungsanbieter hinzu.

Konfiguration

Im folgenden Code wird gezeigt, wie Sie die Response Compression Middleware für Standard-MIME-Typen und Komprimierungsanbieter (Brotli und Gzip) aktivieren:

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddResponseCompression(options =>
{
    options.EnableForHttps = true;
});

var app = builder.Build();

app.UseResponseCompression();

app.MapGet("/", () => "Hello World!");

app.Run();

Hinweise:

Senden Sie eine Anforderung an die Beispiel-App ohne Accept-Encoding Kopfzeile und beachten Sie, dass die Antwort nicht komprimiert ist. Die Content-Encoding Kopfzeile befindet sich nicht in der Antwortheadersammlung.

Beispiel: in Firefox Developer:

  • Wählen Sie die Netzwerkregisterkarte aus.
  • Klicken Sie mit der rechten Maustaste auf die Anforderung in der Liste "Netzwerkanforderung ", und wählen Sie "Bearbeiten" und "Erneut senden" aus.
  • Ändern Sie Accept-Encoding: von gzip, deflate, br in none.
  • Wählen Sie Send (Senden) aus.

Senden Sie eine Anforderung an die Beispiel-App mit einem Browser mithilfe der Entwicklertools und beobachten Sie, dass die Antwort komprimiert wird. Vary Die Content-Encoding Kopfzeilen sind auf der Antwort vorhanden.

Anbieter

Brotli- und Gzip-Komprimierungsanbieter

Verwenden Sie die BrotliCompressionProvider Antworten, um Antworten mit dem komprimierten Datenformat Brotli zu komprimieren.

Wenn keine Komprimierungsanbieter explizit zur Folgenden CompressionProviderCollectionhinzugefügt werden:

  • Der Brotli-Komprimierungsanbieter und der Gzip-Komprimierungsanbieter werden standardmäßig dem Array von Komprimierungsanbietern hinzugefügt.
  • Komprimierungsstandard für die Brotli-Komprimierung, wenn das komprimierte Datenformat vom Client unterstützt wird. Wenn Brotli vom Client nicht unterstützt wird, wird die Komprimierung standardmäßig auf Gzip festgelegt, wenn der Client die Gzip-Komprimierung unterstützt.

Hinweis

Dokumentationslinks zur .NET-Referenzquelle laden in der Regel den Standardbranch des Repositorys, der die aktuelle Entwicklung für das nächste Release von .NET darstellt. Um ein Tag für ein bestimmtes Release auszuwählen, wählen Sie diesen mit der Dropdownliste Switch branches or tags (Branches oder Tags wechseln) aus. Weitere Informationen finden Sie unter How to select a version tag of ASP.NET Core source code (dotnet/AspNetCore.Docs #26205) (Auswählen eines Versionstags von ASP.NET Core-Quellcode (dotnet/AspNetCore.Docs #26205)).

Wenn ein Komprimierungsanbieter hinzugefügt wird, werden andere Anbieter nicht hinzugefügt. Wenn beispielsweise der Gzip-Komprimierungsanbieter der einzige Anbieter explizit hinzugefügt ist, werden keine anderen Komprimierungsanbieter hinzugefügt.

Der folgende Code führt folgende Aktionen aus:

  • Aktiviert die Antwortkomprimierung für HTTPS-Anforderungen.
  • Fügt die Brotli- und Gzip-Antwortkomprimierungsanbieter hinzu.
using System.IO.Compression;
using Microsoft.AspNetCore.ResponseCompression;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddResponseCompression(options =>
{
    options.EnableForHttps = true;
    options.Providers.Add<BrotliCompressionProvider>();
    options.Providers.Add<GzipCompressionProvider>();
});

builder.Services.Configure<BrotliCompressionProviderOptions>(options =>
{
    options.Level = CompressionLevel.Fastest;
});

builder.Services.Configure<GzipCompressionProviderOptions>(options =>
{
    options.Level = CompressionLevel.SmallestSize;
});

var app = builder.Build();

app.UseResponseCompression();

app.MapGet("/", () => "Hello World!");

app.Run();

Legen Sie die Komprimierungsebene mit BrotliCompressionProviderOptions und GzipCompressionProviderOptions. Die Brotli- und Gzip-Komprimierungsanbieter sind standardmäßig auf der schnellsten Komprimierungsebene, CompressionLevel.Fastest, die möglicherweise nicht die effizienteste Komprimierung erzeugen. Wenn die effizienteste Komprimierung gewünscht wird, konfigurieren Sie die Reaktionskomprimierungs-Middleware für optimale Komprimierung.

Compression Level BESCHREIBUNG
CompressionLevel.Schnellstes Die Komprimierung sollte so schnell wie möglich abgeschlossen werden, auch wenn die resultierende Ausgabe nicht optimal komprimiert wird.
CompressionLevel.NoCompression Es sollte keine Komprimierung ausgeführt werden.
CompressionLevel.Optimal Antworten sollten optimal komprimiert werden, auch wenn die Komprimierung mehr Zeit benötigt.
using System.IO.Compression;
using Microsoft.AspNetCore.ResponseCompression;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddResponseCompression(options =>
{
    options.EnableForHttps = true;
    options.Providers.Add<BrotliCompressionProvider>();
    options.Providers.Add<GzipCompressionProvider>();
});

builder.Services.Configure<BrotliCompressionProviderOptions>(options =>
{
    options.Level = CompressionLevel.Fastest;
});

builder.Services.Configure<GzipCompressionProviderOptions>(options =>
{
    options.Level = CompressionLevel.SmallestSize;
});

var app = builder.Build();

app.UseResponseCompression();

app.MapGet("/", () => "Hello World!");

app.Run();

Benutzerdefinierte Anbieter

Erstellen von benutzerdefinierten Komprimierungsimplementierungen mit ICompressionProvider. Dies EncodingName stellt die Inhaltscodierung dar, die dies ICompressionProvider erzeugt. Die Antwortkomprimierungs-Middleware verwendet diese Informationen, um den Anbieter basierend auf der Liste auszuwählen, die in der Accept-Encoding Kopfzeile der Anforderung angegeben ist.

Anforderungen an die Beispiel-App mit der Accept-Encoding: mycustomcompression Kopfzeile geben eine Antwort mit einer Content-Encoding: mycustomcompression Kopfzeile zurück. Der Client muss die benutzerdefinierte Codierung dekomprimieren können, damit eine benutzerdefinierte Komprimierungsimplementierung funktioniert.

using Microsoft.AspNetCore.ResponseCompression;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddResponseCompression(options =>
{
    options.Providers.Add<BrotliCompressionProvider>();
    options.Providers.Add<GzipCompressionProvider>();
    options.Providers.Add<CustomCompressionProvider>();
});

var app = builder.Build();

app.UseResponseCompression();

app.MapGet("/", () => "Hello World!");

app.Run();
using Microsoft.AspNetCore.ResponseCompression;

public class CustomCompressionProvider : ICompressionProvider
{
    public string EncodingName => "mycustomcompression";
    public bool SupportsFlush => true;

    public Stream CreateStream(Stream outputStream)
    {
        // Replace with a custom compression stream wrapper.
        return outputStream;
    }
}

Mit dem vorherigen Code wird der Antworttext vom Beispiel nicht komprimiert. Das Beispiel zeigt jedoch, wo ein benutzerdefinierter Komprimierungsalgorithmus implementiert werden soll.

MIME-Typen

Die Antwortkomprimierungs-Middleware gibt einen Standardsatz von MIME-Typen für die Komprimierung an. Sehen Sie sich den Quellcode für eine vollständige Liste der MIME-Typen an, die unterstützt werden.

Hinweis

Dokumentationslinks zur .NET-Referenzquelle laden in der Regel den Standardbranch des Repositorys, der die aktuelle Entwicklung für das nächste Release von .NET darstellt. Um ein Tag für ein bestimmtes Release auszuwählen, wählen Sie diesen mit der Dropdownliste Switch branches or tags (Branches oder Tags wechseln) aus. Weitere Informationen finden Sie unter How to select a version tag of ASP.NET Core source code (dotnet/AspNetCore.Docs #26205) (Auswählen eines Versionstags von ASP.NET Core-Quellcode (dotnet/AspNetCore.Docs #26205)).

Ersetzen oder Anfügen von MIME-Typen durch ResponseCompressionOptions.MimeTypes. Beachten Sie, dass Wildcard-MIME-Typen, z. B text/* . nicht unterstützt werden. Die Beispiel-App fügt einen MIME-Typ für image/svg+xml und komprimiert hinzu und dient dem ASP.NET Core Bannerbild banner.svg.

using Microsoft.AspNetCore.ResponseCompression;
using ResponseCompressionSample;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddResponseCompression(options =>
{
    options.EnableForHttps = true;
    options.Providers.Add<BrotliCompressionProvider>();
    options.Providers.Add<GzipCompressionProvider>();
    options.Providers.Add<CustomCompressionProvider>();
    options.MimeTypes =
    ResponseCompressionDefaults.MimeTypes.Concat(
        new[] { "image/svg+xml" });
});

var app = builder.Build();

app.UseResponseCompression();

Hinzufügen des Headers "Vary"

Beim Komprimieren von Antworten basierend auf der Anforderungsheader können nicht komprimierte und mehrere komprimierte Versionen der Accept-EncodingAntwort vorhanden sein. Um Client- und Proxycaches anzuweisen, dass mehrere Versionen vorhanden sind und gespeichert werden sollen, wird der Vary Header mit einem Accept-Encoding Wert hinzugefügt. Die Antwort-Middleware fügt die Kopfzeile automatisch hinzu, wenn die Vary Antwort komprimiert wird.

Hinweis

Dokumentationslinks zur .NET-Referenzquelle laden in der Regel den Standardbranch des Repositorys, der die aktuelle Entwicklung für das nächste Release von .NET darstellt. Um ein Tag für ein bestimmtes Release auszuwählen, wählen Sie diesen mit der Dropdownliste Switch branches or tags (Branches oder Tags wechseln) aus. Weitere Informationen finden Sie unter How to select a version tag of ASP.NET Core source code (dotnet/AspNetCore.Docs #26205) (Auswählen eines Versionstags von ASP.NET Core-Quellcode (dotnet/AspNetCore.Docs #26205)).

Middleware-Problem bei hinter einem Nginx-Reverseproxy

Wenn eine Anforderung von Nginx proxied wird, wird die Accept-Encoding Kopfzeile entfernt. Die Entfernung des Accept-Encoding Headers verhindert, dass die Reaktionskomprimierungs-Middleware die Antwort komprimiert. Weitere Informationen finden Sie unter NGINX: Komprimierung und Dekomprimierung. Dieses Problem wird von der Durchlaufkomprimierung für Nginx (dotnet/aspnetcore#5989) nachverfolgt.

Deaktivieren der dynamischen IIS-Komprimierung

Informationen zum Deaktivieren des auf Serverebene konfigurierten IIS-Dynamischen Komprimierungsmoduls finden Sie unter Deaktivieren von IIS-Modulen.

Problembehandlung bei der Antwortkomprimierung

Verwenden Sie ein Tool wie Firefox Browser Developer oder Postman, mit dem sie den Anforderungsheader festlegen und die Antwortkopfzeilen, die Größe und den Accept-Encoding Text untersuchen können. Standardmäßig komprimiert Response Compression Middleware Antworten, die die folgenden Bedingungen erfüllen:

  • Der Accept-Encoding Header ist mit einem Wert von br, gzip*oder benutzerdefinierter Codierung vorhanden, der einem benutzerdefinierten Komprimierungsanbieter entspricht. Der Wert darf nicht identity sein oder über einen Qualitätswert (qvalue, q) -Einstellung von 0 (Null) verfügen.
  • Der MIME-Typ (Content-Type) muss festgelegt werden und muss mit einem MIME-Typ übereinstimmen, der auf dem ResponseCompressionOptions.
  • Die Anforderung darf die Content-Range Kopfzeile nicht enthalten.
  • Die Anforderung muss das unsichere Protokoll (http) verwenden, es sei denn, das sichere Protokoll (https) ist in den Optionen für die Reaktionskomprimierungs-Middleware konfiguriert. Beachten Sie die oben beschriebene Gefahr beim Aktivieren der sicheren Inhaltskomprimierung.

Azure bereitgestelltes Beispiel

Die Beispiel-App , die in Azure gespeichert wurde, weist die folgende Program.cs Datei auf:

using Microsoft.AspNetCore.ResponseCompression;
using ResponseCompressionSample;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddResponseCompression(options =>
{
    options.EnableForHttps = true;
    options.Providers.Add<BrotliCompressionProvider>();
    options.Providers.Add<GzipCompressionProvider>();
    options.Providers.Add<CustomCompressionProvider>();
    options.MimeTypes =
    ResponseCompressionDefaults.MimeTypes.Concat(
        new[] { "image/svg+xml" });
});

var app = builder.Build();

app.UseResponseCompression();

app.Map("/trickle", async (HttpResponse httpResponse) =>
{
    httpResponse.ContentType = "text/plain;charset=utf-8";

    for (int i = 0; i < 20; i++)
    {
        await httpResponse.WriteAsync("a");
        await httpResponse.Body.FlushAsync();
        await Task.Delay(TimeSpan.FromMilliseconds(50));
    }
});

app.Map("/testfile1kb.txt", () => Results.File(
    app.Environment.ContentRootFileProvider.GetFileInfo("testfile1kb.txt").PhysicalPath,
    "text/plain;charset=utf-8"));

app.Map("/banner.svg", () => Results.File(
    app.Environment.ContentRootFileProvider.GetFileInfo("banner.svg").PhysicalPath,
    "image/svg+xml;charset=utf-8"));

app.MapFallback(() => LoremIpsum.Text);

app.Run();

Zusätzliche Ressourcen

Hinweis

Dokumentationslinks zur .NET-Referenzquelle laden in der Regel den Standardbranch des Repositorys, der die aktuelle Entwicklung für das nächste Release von .NET darstellt. Um ein Tag für ein bestimmtes Release auszuwählen, wählen Sie diesen mit der Dropdownliste Switch branches or tags (Branches oder Tags wechseln) aus. Weitere Informationen finden Sie unter How to select a version tag of ASP.NET Core source code (dotnet/AspNetCore.Docs #26205) (Auswählen eines Versionstags von ASP.NET Core-Quellcode (dotnet/AspNetCore.Docs #26205)).

Die Netzwerkbandbreite ist eine begrenzte Ressource. Die Verringerung der Größe der Antwort erhöht in der Regel die Reaktionsfähigkeit einer App, oft dramatisch. Eine Möglichkeit zum Reduzieren der Nutzlastgrößen besteht darin, die Antworten einer App zu komprimieren.

Anzeigen oder Herunterladen von Beispielcode (Vorgehensweise zum Herunterladen)

Verwenden der Antwortkomprimierungs-Middleware

Verwenden Sie serverbasierte Antwortkomprimierungstechnologien in IIS, Apache oder Nginx. Die Leistung der Middleware entspricht wahrscheinlich nicht dem der Servermodule. HTTP.sys Serverserver und Kestrel Server bieten derzeit keine integrierte Komprimierungsunterstützung.

Verwenden Sie Die Antwortkomprimierungs-Middleware, wenn Sie:

Antwortkomprimierung

In der Regel kann jede Antwort, die nicht systemintern komprimiert wird, von der Antwortkomprimierung profitieren. Antworten, die in der Regel nicht systemintern komprimiert werden, umfassen: CSS, JavaScript, HTML, XML und JSON. Sie sollten nicht systemeigene komprimierte Ressourcen komprimieren, z. B. PNG-Dateien. Wenn Sie versuchen, eine systemeigene komprimierte Antwort weiter zu komprimieren, wird jede kleine zusätzliche Verringerung der Größe und Der Übertragungszeit wahrscheinlich von der Zeit, die die Komprimierung benötigt, überschattet. Komprimieren Sie dateien nicht kleiner als etwa 150-1000 Bytes (je nach Inhalt der Datei und effizienz der Komprimierung). Der Aufwand der Komprimierung kleiner Dateien kann eine komprimierte Datei erzeugen, die größer als die nicht komprimierte Datei ist.

Wenn ein Client komprimierte Inhalte verarbeiten kann, muss der Client den Server seiner Funktionen informieren, indem er den Header mit der Anforderung sendet Accept-Encoding . Wenn ein Server komprimierte Inhalte sendet, muss er Informationen in die Content-Encoding Kopfzeile einschließen, wie die komprimierte Antwort codiert ist. Inhaltscodierungsbezeichnungen, die von der Middleware unterstützt werden, werden in der folgenden Tabelle angezeigt.

Accept-Encoding Kopfzeilenwerte Middleware unterstützt BESCHREIBUNG
br Ja (Standard) Brotli komprimiertes Datenformat
deflate Nein Komprimiertes Datenformat DEFLATE
exi Nein W3C-effizienter XML-Austausch
gzip Ja Gzip-Dateiformat
identity Ja Bezeichner "Keine Codierung": Die Antwort darf nicht codiert werden.
pack200-gzip Nein Netzwerkübertragungsformat für Java-Archive
* Ja Alle verfügbaren Inhaltscodierungen werden nicht explizit angefordert.

Weitere Informationen finden Sie in der offiziellen Inhaltscodierungsliste von IANA.

Mit der Middleware können Sie zusätzliche Komprimierungsanbieter für benutzerdefinierte Accept-Encoding Headerwerte hinzufügen. Weitere Informationen finden Sie unter "Benutzerdefinierte Anbieter" unten.

Die Middleware ist in der Lage, auf den Qualitätswert (qvalue, ) zu reagieren, qwenn der Client gesendet wird, um Komprimierungsschemas zu priorisieren. Weitere Informationen finden Sie unter RFC 7231: Accept-Encoding.

Komprimierungsalgorithmen unterliegen einem Handel zwischen Komprimierungsgeschwindigkeit und Wirksamkeit der Komprimierung. Die Wirksamkeit in diesem Zusammenhang bezieht sich auf die Größe der Ausgabe nach der Komprimierung. Die kleinste Größe wird durch die optimale Komprimierung erreicht.

Die Kopfzeilen, die beim Anfordern, Senden, Zwischenspeichern und Empfangen komprimierter Inhalte enthalten sind, werden in der nachstehenden Tabelle beschrieben.

Header Role
Accept-Encoding Gesendet vom Client an den Server, um die für den Client zulässigen Inhaltscodierungsschemas anzugeben.
Content-Encoding Vom Server an den Client gesendet, um die Codierung des Inhalts in der Nutzlast anzugeben.
Content-Length Wenn die Komprimierung auftritt, wird die Kopfzeile entfernt, da sich der Content-Length Textkörperinhalt ändert, wenn die Antwort komprimiert wird.
Content-MD5 Wenn die Komprimierung auftritt, wird die Kopfzeile entfernt, da der Content-MD5 Textkörperinhalt geändert wurde und der Hash nicht mehr gültig ist.
Content-Type Gibt den MIME-Typ des Inhalts an. Jede Antwort sollte seine Content-TypeAngabe angeben. Die Middleware überprüft diesen Wert, um festzustellen, ob die Antwort komprimiert werden soll. Die Middleware gibt einen Satz von Standard-MIME-Typen an, die codiert werden können, Sie können jedoch MIME-Typen ersetzen oder hinzufügen.
Vary Wenn der Server mit einem Wert an Accept-Encoding Clients und Proxies gesendet wird, gibt der Vary Header an, dass er die Antworten zwischenspeichern (variieren) sollte, basierend auf dem Wert des Accept-Encoding Headers der Anforderung. Das Ergebnis der Rückgabe von Inhalten mit der Vary: Accept-Encoding Kopfzeile ist, dass sowohl komprimierte als auch nicht komprimierte Antworten separat zwischengespeichert werden.

Erkunden Sie die Features der Response-Komprimierungs-Middleware mit der Beispiel-App. Das Beispiel veranschaulicht:

  • Die Komprimierung von App-Antworten mithilfe von Gzip- und benutzerdefinierten Komprimierungsanbietern.
  • So fügen Sie einem MIME-Typ die Standardliste der MIME-Typen für die Komprimierung hinzu.

Konfiguration

Im folgenden Code wird gezeigt, wie Sie die Response Compression Middleware für Standard-MIME-Typen und Komprimierungsanbieter (Brotli und Gzip) aktivieren:

public class Startup
{
    public void ConfigureServices(IServiceCollection services)
    {
        services.AddResponseCompression();
    }

    public void Configure(IApplicationBuilder app, IHostingEnvironment env)
    {
        app.UseResponseCompression();
    }
}

Hinweise:

  • app.UseResponseCompression muss vor jeder Middleware aufgerufen werden, die Antworten komprimiert. Weitere Informationen finden Sie unter ASP.NET Core-Middleware.
  • Verwenden Sie ein Tool wie Fiddler, Firefox Browser Developer oder Postman , um den Anforderungsheader festzulegen und die Antwortheader, Größe Accept-Encoding und Text zu untersuchen.

Senden Sie eine Anforderung an die Beispiel-App ohne Accept-Encoding Kopfzeile und beachten Sie, dass die Antwort nicht komprimiert ist. Die Content-Encoding Kopfzeilen Vary sind auf der Antwort nicht vorhanden.

Fiddler-Fenster mit Ergebnis einer Anforderung ohne Accept-Encoding Header. Die Antwort wird nicht komprimiert.

Senden Sie eine Anforderung an die Beispiel-App mit der Accept-Encoding: br Kopfzeile (Brotli-Komprimierung), und beachten Sie, dass die Antwort komprimiert wird. Vary Die Content-Encoding Kopfzeilen sind auf der Antwort vorhanden.

Fiddler-Fenster mit Ergebnis einer Anforderung mit der Accept-Encoding Kopfzeile und einem Wert von br. Die Kopfzeilen

Anbieter

Brotli Komprimierungsanbieter

Verwenden Sie die BrotliCompressionProvider Antworten, um Antworten mit dem komprimierten Datenformat Brotli zu komprimieren.

Wenn keine Komprimierungsanbieter explizit zur Folgenden CompressionProviderCollectionhinzugefügt werden:

  • Der Brotli-Komprimierungsanbieter wird standardmäßig dem Array von Komprimierungsanbietern zusammen mit dem Gzip-Komprimierungsanbieter hinzugefügt.
  • Komprimierungsstandard für die Brotli-Komprimierung, wenn das komprimierte Datenformat vom Client unterstützt wird. Wenn Brotli vom Client nicht unterstützt wird, wird die Komprimierung standardmäßig auf Gzip festgelegt, wenn der Client die Gzip-Komprimierung unterstützt.
public void ConfigureServices(IServiceCollection services)
{
    services.AddResponseCompression();
}

Der Brotli-Komprimierungsanbieter muss hinzugefügt werden, wenn alle Komprimierungsanbieter explizit hinzugefügt werden:

public void ConfigureServices(IServiceCollection services)
{
    services.AddResponseCompression(options =>
    {
        options.Providers.Add<BrotliCompressionProvider>();
        options.Providers.Add<GzipCompressionProvider>();
        options.Providers.Add<CustomCompressionProvider>();
        options.MimeTypes = 
            ResponseCompressionDefaults.MimeTypes.Concat(
                new[] { "image/svg+xml" });
    });
}

Legen Sie die Komprimierungsstufe mit BrotliCompressionProviderOptions. Der Brotli-Komprimierungsanbieter wird standardmäßig auf die schnellste Komprimierungsebene (CompressionLevel.Fastest) festgelegt, die möglicherweise nicht die effizienteste Komprimierung erzeugt. Wenn die effizienteste Komprimierung gewünscht ist, konfigurieren Sie die Middleware für optimale Komprimierung.

Compression Level BESCHREIBUNG
CompressionLevel.Schnellstes Die Komprimierung sollte so schnell wie möglich abgeschlossen werden, auch wenn die resultierende Ausgabe nicht optimal komprimiert wird.
CompressionLevel.NoCompression Es sollte keine Komprimierung ausgeführt werden.
CompressionLevel.Optimal Antworten sollten optimal komprimiert werden, auch wenn die Komprimierung mehr Zeit benötigt.
public void ConfigureServices(IServiceCollection services)
{
    services.AddResponseCompression();

    services.Configure<BrotliCompressionProviderOptions>(options => 
    {
        options.Level = CompressionLevel.Fastest;
    });
}

Gzip-Komprimierungsanbieter

Verwenden Sie die GzipCompressionProvider Antworten zum Komprimieren mit dem Gzip-Dateiformat.

Wenn keine Komprimierungsanbieter explizit zur Folgenden CompressionProviderCollectionhinzugefügt werden:

  • Der Gzip-Komprimierungsanbieter wird standardmäßig dem Array der Komprimierungsanbieter zusammen mit dem Brotli-Komprimierungsanbieter hinzugefügt.
  • Komprimierungsstandard für die Brotli-Komprimierung, wenn das komprimierte Datenformat vom Client unterstützt wird. Wenn Brotli vom Client nicht unterstützt wird, wird die Komprimierung standardmäßig auf Gzip festgelegt, wenn der Client die Gzip-Komprimierung unterstützt.
public void ConfigureServices(IServiceCollection services)
{
    services.AddResponseCompression();
}

Der Gzip-Komprimierungsanbieter muss hinzugefügt werden, wenn alle Komprimierungsanbieter explizit hinzugefügt werden:

public void ConfigureServices(IServiceCollection services)
{
    services.AddResponseCompression(options =>
    {
        options.Providers.Add<BrotliCompressionProvider>();
        options.Providers.Add<GzipCompressionProvider>();
        options.Providers.Add<CustomCompressionProvider>();
        options.MimeTypes = 
            ResponseCompressionDefaults.MimeTypes.Concat(
                new[] { "image/svg+xml" });
    });
}

Legen Sie die Komprimierungsstufe mit GzipCompressionProviderOptions. Der Gzip-Komprimierungsanbieter ist standardmäßig auf die schnellste Komprimierungsebene (CompressionLevel.Schnellste) festgelegt, die möglicherweise nicht die effizienteste Komprimierung erzeugt. Wenn die effizienteste Komprimierung gewünscht ist, konfigurieren Sie die Middleware für optimale Komprimierung.

Compression Level BESCHREIBUNG
CompressionLevel.Schnellstes Die Komprimierung sollte so schnell wie möglich abgeschlossen werden, auch wenn die resultierende Ausgabe nicht optimal komprimiert wird.
CompressionLevel.NoCompression Es sollte keine Komprimierung ausgeführt werden.
CompressionLevel.Optimal Antworten sollten optimal komprimiert werden, auch wenn die Komprimierung mehr Zeit benötigt.
public void ConfigureServices(IServiceCollection services)
{
    services.AddResponseCompression();

    services.Configure<GzipCompressionProviderOptions>(options => 
    {
        options.Level = CompressionLevel.Fastest;
    });
}

Benutzerdefinierte Anbieter

Erstellen von benutzerdefinierten Komprimierungsimplementierungen mit ICompressionProvider. Dies EncodingName stellt die Inhaltscodierung dar, die dies ICompressionProvider erzeugt. Die Middleware verwendet diese Informationen, um den Anbieter basierend auf der Liste auszuwählen, die in der Accept-Encoding Kopfzeile der Anforderung angegeben ist.

Mithilfe der Beispiel-App sendet der Client eine Anforderung mit der Accept-Encoding: mycustomcompression Kopfzeile. Die Middleware verwendet die benutzerdefinierte Komprimierungsimplementierung und gibt die Antwort mit einer Content-Encoding: mycustomcompression Kopfzeile zurück. Der Client muss die benutzerdefinierte Codierung dekomprimieren können, damit eine benutzerdefinierte Komprimierungsimplementierung funktioniert.

public void ConfigureServices(IServiceCollection services)
{
    services.AddResponseCompression(options =>
    {
        options.Providers.Add<BrotliCompressionProvider>();
        options.Providers.Add<GzipCompressionProvider>();
        options.Providers.Add<CustomCompressionProvider>();
        options.MimeTypes = 
            ResponseCompressionDefaults.MimeTypes.Concat(
                new[] { "image/svg+xml" });
    });
}
public class CustomCompressionProvider : ICompressionProvider
{
    public string EncodingName => "mycustomcompression";
    public bool SupportsFlush => true;

    public Stream CreateStream(Stream outputStream)
    {
        // Create a custom compression stream wrapper here
        return outputStream;
    }
}

Senden Sie eine Anforderung an die Beispiel-App mit der Accept-Encoding: mycustomcompression Kopfzeile und beobachten Sie die Antwortheader. Content-Encoding Die Vary Kopfzeilen sind auf der Antwort vorhanden. Der Antworttext (nicht angezeigt) wird vom Beispiel nicht komprimiert. Es gibt keine Komprimierungsimplementierung in der CustomCompressionProvider Klasse des Beispiels. Das Beispiel zeigt jedoch, wo Sie einen solchen Komprimierungsalgorithmus implementieren würden.

Fiddler-Fenster mit Ergebnis einer Anforderung mit der Accept-Encoding Kopfzeile und einem Wert von mycustomcompression. Die Kopfzeilen

MIME-Typen

Die Middleware gibt einen Standardsatz von MIME-Typen für die Komprimierung an:

  • application/javascript
  • application/json
  • application/xml
  • text/css
  • text/html
  • text/json
  • text/plain
  • text/xml

Ersetzen oder Anfügen von MIME-Typen durch die Optionen für die Reaktionskomprimierungs-Middleware. Beachten Sie, dass Wildcard-MIME-Typen, z. B text/* . nicht unterstützt werden. Die Beispiel-App fügt einen MIME-Typ für image/svg+xml und komprimiert hinzu und dient dem ASP.NET Core Bannerbild (Banner.svg).

public void ConfigureServices(IServiceCollection services)
{
    services.AddResponseCompression(options =>
    {
        options.Providers.Add<BrotliCompressionProvider>();
        options.Providers.Add<GzipCompressionProvider>();
        options.Providers.Add<CustomCompressionProvider>();
        options.MimeTypes = 
            ResponseCompressionDefaults.MimeTypes.Concat(
                new[] { "image/svg+xml" });
    });
}

Komprimierung mit sicherem Protokoll

Komprimierte Antworten über sichere Verbindungen können mit der Option gesteuert werden, die EnableForHttps standardmäßig deaktiviert ist. Die Verwendung der Komprimierung mit dynamisch generierten Seiten kann zu Sicherheitsproblemen wie z. B. den CRIME Angriffen BREACH führen.

Hinzufügen des Headers "Vary"

Beim Komprimieren von Antworten basierend auf der Accept-Encoding Kopfzeile gibt es potenziell mehrere komprimierte Versionen der Antwort und eine nicht komprimierte Version. Um Client- und Proxycaches anzuweisen, dass mehrere Versionen vorhanden sind und gespeichert werden sollen, wird der Vary Header mit einem Accept-Encoding Wert hinzugefügt. In ASP.NET Core 2.0 oder höher fügt die Middleware den Vary Header automatisch hinzu, wenn die Antwort komprimiert wird.

Middleware-Problem bei hinter einem Nginx-Reverseproxy

Wenn eine Anforderung von Nginx proxied wird, wird die Accept-Encoding Kopfzeile entfernt. Das Entfernen der Accept-Encoding Kopfzeile verhindert, dass die Middleware die Antwort komprimiert. Weitere Informationen finden Sie unter NGINX: Komprimierung und Dekomprimierung. Dieses Problem wird von der Durchlaufkomprimierung für Nginx (dotnet/aspnetcore#5989) nachverfolgt.

Arbeiten mit der dynamischen IIS-Komprimierung

Wenn Sie über ein aktives IIS-Dynamisches Komprimierungsmodul auf Serverebene konfiguriert haben, das Sie für eine App deaktivieren möchten, deaktivieren Sie das Modul mit einer Ergänzung zur web.config Datei. Weitere Informationen finden Sie unter Disabling IIS modules (Deaktivieren von IIS-Modulen).

Problembehandlung

Verwenden Sie ein Tool wie Fiddler, Firefox Browser Developer oder Postman, mit dem Sie den Anforderungsheader festlegen und die Antwortheader, Größe Accept-Encoding und Text untersuchen können. Standardmäßig komprimiert Response Compression Middleware Antworten, die die folgenden Bedingungen erfüllen:

  • Die Accept-Encoding Kopfzeile ist mit einem Wert von br, , oder *benutzerdefinierter Codierung vorhanden, der einem benutzerdefinierten Komprimierungsanbieter entspricht, gzipden Sie eingerichtet haben. Der Wert darf nicht identity sein oder über einen Qualitätswert (qvalue, q) -Einstellung von 0 (Null) verfügen.
  • Der MIME-Typ (Content-Type) muss festgelegt werden und muss mit einem MIME-Typ übereinstimmen, der auf dem ResponseCompressionOptions.
  • Die Anforderung darf die Content-Range Kopfzeile nicht enthalten.
  • Die Anforderung muss das unsichere Protokoll (http) verwenden, es sei denn, das sichere Protokoll (https) ist in den Optionen für die Reaktionskomprimierungs-Middleware konfiguriert. Beachten Sie die oben beschriebene Gefahr beim Aktivieren der sicheren Inhaltskomprimierung.

Zusätzliche Ressourcen