Antwortkomprimierung in ASP.NET Core

Die Netzwerkbandbreite ist eine begrenzte Ressource. Das Reduzieren der Antwortgröße erhöht in der Regel die Reaktionsfähigkeit einer App, häufig erheblich. Eine Möglichkeit, die Nutzlastgröße zu reduzieren, besteht in der Komprimierung der Antworten einer App.

Anzeigen oder Herunterladen von Beispielcode (Vorgehensweise zum Herunterladen)

Einsatz von Middleware für die Antwortkomprimierung

Verwenden Sie serverbasierte Antwortkomprimierungstechnologien in IIS, Apache oder Nginx. Die Leistung der Middleware wird wahrscheinlich nicht mit der der Servermodule übereinstimmen. HTTP.sys Serverserver und Kestrel Server bieten derzeit keine integrierte Unterstützung für die Komprimierung.

Verwenden Sie die Middleware für die Antwortkomprimierung, wenn Sie:

Antwortkomprimierung

In der Regel kann jede Antwort, die nicht nativ komprimiert ist, von der Antwortkomprimierung profitieren. Antworten, die nicht nativ komprimiert sind, sind in der Regel: CSS, JavaScript, HTML, XML und JSON. Sie sollten keine nativ komprimierten Objekte wie PNG-Dateien komprimieren. Wenn Sie versuchen, eine nativ komprimierte Antwort weiter zu komprimieren, wird jede kleine zusätzliche Verkleinerung der Größe und Übertragungszeit wahrscheinlich durch die Zeit überschattet, die zum Verarbeiten der Komprimierung gezeitet hat. Komprimieren Sie Keine Dateien, die kleiner als etwa 150 bis 1000 Bytes sind (abhängig vom Inhalt der Datei und der Effizienz der Komprimierung). Der Mehraufwand für das Komprimieren kleiner Dateien kann eine komprimierte Datei erzeugen, die größer als die nicht komprimierte Datei ist.

Wenn ein Client komprimierten Inhalt verarbeiten kann, muss der Client den Server über seine Funktionen informieren, indem er den Header Accept-Encoding mit der Anforderung sendet. Wenn ein Server komprimierten Inhalt sendet, muss er Informationen zur Codierung der komprimierten Antwort in den Content-Encoding Header enthalten. Die von der Middleware unterstützten Inhaltscodierungsbezeichnungen sind in der folgenden Tabelle aufgeführt.

Accept-Encoding Headerwerte Middleware unterstützt BESCHREIBUNG
br Ja (Standard) Brotli-Komprimiertes Datenformat
deflate Nein DEFLATE- komprimiertes Datenformat
exi Nein Effizienter W3C-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, die nicht explizit angefordert wurden

Weitere Informationen finden Sie in der offiziellen IANA-Inhaltscodierungsliste.

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

Die Middleware kann auf die Gewichtung von Qualitätswerten (qvalue, ) reagieren, wenn sie vom Client gesendet wird, um q Komprimierungsschemas zu priorisieren. Weitere Informationen finden Sie unter RFC 7231: Accept-Encoding.

Komprimierungsalgorithmen unterliegen einem Kompromiss zwischen der Komprimierungsgeschwindigkeit und der Effektivität der Komprimierung. Effektivität bezieht sich in diesem Kontext auf die Größe der Ausgabe nach der Komprimierung. Die kleinste Größe wird durch die optimale Komprimierung erreicht.

Die Header für das Anfordern, Senden, Zwischenspeichern und Empfangen komprimierter Inhalte werden in der folgenden Tabelle beschrieben.

Header Rolle
Accept-Encoding Wird vom Client an den Server gesendet, um die inhaltscodierungsschemas anzugeben, die für den Client akzeptabel sind.
Content-Encoding Wird vom Server an den Client gesendet, um die Codierung des Inhalts in der Nutzlast anzugeben.
Content-Length Wenn die Komprimierung erfolgt, wird der Header entfernt, da sich Content-Length der Textinhalt ändert, wenn die Antwort komprimiert wird.
Content-MD5 Wenn die Komprimierung erfolgt, wird der Header entfernt, da sich der Textinhalt geändert hat und der Hash Content-MD5 nicht mehr gültig ist.
Content-Type Gibt den MIME-Typ des Inhalts an. Jede Antwort sollte ihren Content-Type angeben. Die Middleware überprüft diesen Wert, um zu bestimmen, ob die Antwort komprimiert werden soll. Die Middleware gibt einen Satz von MIME-Standardtypen an, die codiert werden können. Sie können mime-Typen jedoch ersetzen oder hinzufügen.
Vary Beim Senden durch den Server mit dem Wert an Clients und Proxys gibt der Header dem Client oder Proxy an, dass Antworten basierend auf dem Wert des Headers der Anforderung zwischengespeichert Accept-Encoding Vary (variieren) werden Accept-Encoding sollen. Das Ergebnis der Rückgabe von Inhalt mit dem Header ist, dass sowohl komprimierte als auch nicht komprimierte Antworten Vary: Accept-Encoding separat zwischengespeichert werden.

Erkunden Sie die Features der Middleware für die Antwortkomprimierung mit der Beispiel-App. Das Beispiel veranschaulicht:

  • Die Komprimierung von App-Antworten mithilfe von Gzip und benutzerdefinierten Komprimierungsanbietern.
  • Hinzufügen eines MIME-Typs zur Standardliste der MIME-Typen für die Komprimierung.

Paket

Die Middleware für die Antwortkomprimierung wird vom Paket Microsoft.AspNetCore.ResponseCompression bereitgestellt, das implizit in ASP.NET Core enthalten ist.

Konfiguration

Der folgende Code zeigt, wie die Middleware für die Antwortkomprimierung für Standard-MIME-Typen und Komprimierungsanbieter (Brotli und Gzip ) aktiviert wird:

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 Developeroder Postman, um den Anforderungsheader und die Antwortheader, die Größe und den Text Accept-Encoding zu untersuchen.

Senden Sie eine Anforderung an die Beispiel-App ohne den -Header, und beobachten Accept-Encoding Sie, dass die Antwort nicht komprimiert ist. Die Content-Encoding Header und sind in der Antwort nicht Vary vorhanden.

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

Senden Sie eine Anforderung mit dem Header (Brotli-Komprimierung) an die Beispiel-App, und beobachten Accept-Encoding: br Sie, dass die Antwort komprimiert ist. Die Content-Encoding Header und sind in der Antwort Vary vorhanden.

Fiddler-Fenster mit dem Ergebnis einer Anforderung mit dem Accept-Encoding und dem Wert br. Die Vary- und Content-Encoding-Header werden der Antwort hinzugefügt. Die Antwort wird komprimiert.

Anbieter

Brotli-Komprimierungsanbieter

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

Wenn dem keine Komprimierungsanbieter explizit hinzugefügt CompressionProviderCollection werden:

  • Der Brotli-Komprimierungsanbieter wird standardmäßig dem Array der Komprimierungsanbieter zusammen mit dem Gzip-Komprimierungsanbieter hinzugefügt.
  • Die Komprimierung wird standardmäßig auf Brotli-Komprimierung festgelegt, wenn das komprimierte Brotli-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 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 fest. Der Brotli-Komprimierungsanbieter verwendet standardmäßig die schnellste Komprimierungsstufe(CompressionLevel.Fastest),die möglicherweise nicht die effizienteste Komprimierung erzeugt. Wenn die effizienteste Komprimierung gewünscht ist, konfigurieren Sie die Middleware für eine optimale Komprimierung.

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

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

Gzip-Komprimierungsanbieter

Verwenden Sie GzipCompressionProvider , um Antworten im Gzip-Dateiformatzu komprimieren.

Wenn dem keine Komprimierungsanbieter explizit hinzugefügt CompressionProviderCollection werden:

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

Der Gzip-Komprimierungsanbieter muss hinzugefügt werden, wenn 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 den Komprimierungsgrad mit GzipCompressionProviderOptions fest. Der Gzip-Komprimierungsanbieter verwendet standardmäßig die schnellste Komprimierungsstufe(CompressionLevel.Fastest),die möglicherweise nicht die effizienteste Komprimierung erzeugt. Wenn die effizienteste Komprimierung gewünscht ist, konfigurieren Sie die Middleware für eine optimale Komprimierung.

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

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

Benutzerdefinierte Anbieter

Erstellen Sie mit benutzerdefinierte Komprimierungsimplementierungen. ICompressionProvider Stellt EncodingName die Inhaltscodierung dar, die von ICompressionProvider diesem erzeugt wird. Die Middleware verwendet diese Informationen, um den Anbieter basierend auf der im Header der Anforderung angegebenen Liste Accept-Encoding auszuwählen.

Mithilfe der Beispiel-App sendet der Client eine Anforderung mit dem Accept-Encoding: mycustomcompression -Header. Die Middleware verwendet die benutzerdefinierte Komprimierungsimplementierung und gibt die Antwort mit einem Content-Encoding: mycustomcompression Header zurück. Der Client muss in der Lage sein, die benutzerdefinierte Codierung zu dekomprimieren, 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 mit dem -Header an die Beispiel-App, Accept-Encoding: mycustomcompression und beobachten Sie die Antwortheader. Die Vary Header und sind in der Antwort Content-Encoding 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 dem Ergebnis einer Anforderung mit dem Accept-Encoding-Header und dem Wert mycustomcompression. Die Vary- und Content-Encoding-Header werden der Antwort hinzugefügt.

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 Sie MIME-Typen durch die Middlewareoptionen für die Antwortkomprimierung, oder fügen Sie sie an. Beachten Sie, dass Platzhalter-MIME-Typen wie text/* nicht unterstützt werden. Die Beispiel-App fügt einen MIME-Typ für image/svg+xml hinzu und komprimiert und bedient das 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 EnableForHttps werden, die standardmäßig deaktiviert ist. Die Verwendung der Komprimierung mit dynamisch generierten Seiten kann zu Sicherheitsproblemen führen, z. B. zu DEN ANGRIFFEN MITHILFE VON ANGRIFFEN und SICHERHEITSVERLETZUNGEN.

Hinzufügen des Vary-Headers

Beim Komprimieren von Antworten basierend auf dem Accept-Encoding Header gibt es möglicherweise 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.

Middlewareproblem, wenn hinter einem Nginx-Reverseproxy

Wenn eine Anforderung von Nginx übermittelt wird, wird der Accept-Encoding Header entfernt. Das Entfernen des Accept-Encoding Headers verhindert, dass die Middleware die Antwort komprimiert. Weitere Informationen finden Sie unter NGINX: Komprimierung und Dekomprimierung. Dieses Problem wird durch Abbildung der Pass-Through-Komprimierung für Nginx (aspnet/BasicMiddleware #123)nachverfolgt.

Arbeiten mit der dynamischen IIS-Komprimierung

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

Problembehandlung

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

  • Der Header ist mit dem Wert , , oder der Accept-Encoding br gzip * benutzerdefinierten Codierung vorhanden, die einem von Ihnen eingerichteten benutzerdefinierten Komprimierungsanbieter entspricht. Der Wert darf nicht identity sein oder eine Qualitätswerteinstellung (qvalue, q ) von 0 (null) aufweisen.
  • Der MIME-Typ ( Content-Type ) muss festgelegt werden und mit einem MIME-Typ übereinstimmen, der für konfiguriert ResponseCompressionOptions ist.
  • Die Anforderung darf den Header nicht Content-Range enthalten.
  • Die Anforderung muss unsicheres Protokoll (http) verwenden, es sei denn, das sichere Protokoll (https) ist in den Middlewareoptionen für die Antwortkomprimierung konfiguriert. Beachten Sie die oben beschriebene Gefahr beim Aktivieren der sicheren Inhaltskomprimierung.

Zusätzliche Ressourcen

Die Netzwerkbandbreite ist eine begrenzte Ressource. Die Reduzierung der Antwortgröße erhöht in der Regel die Reaktionsfähigkeit einer App, häufig drastisch. Eine Möglichkeit zum Reduzieren der Nutzlastgrößen besteht darin, die Antworten einer App zu komprimieren.

Anzeigen oder Herunterladen von Beispielcode (Vorgehensweise zum Herunterladen)

Einsatz von Middleware für die Antwortkomprimierung

Verwenden Sie serverbasierte Technologien für die Antwortkomprimierung in IIS, Apache oder Nginx. Die Leistung der Middleware stimmt wahrscheinlich nicht mit der leistung der Servermodule überein. HTTP.sys Serverserver und Kestrel -server bieten derzeit keine integrierte Komprimierungsunterstützung.

Verwenden Sie Middleware für die Antwortkomprimierung, wenn Sie:

Antwortkomprimierung

In der Regel kann jede Antwort, die nicht nativ komprimiert ist, von der Antwortkomprimierung profitieren. Antworten, die nicht nativ komprimiert sind, umfassen in der Regel: CSS, JavaScript, HTML, XML und JSON. Sie sollten keine nativ komprimierten Objekte komprimieren, z. B. PNG-Dateien. Wenn Sie versuchen, eine nativ komprimierte Antwort weiter zu komprimieren, wird jede geringfügige zusätzliche Verringerung der Größe und Übertragungszeit wahrscheinlich durch die Zeit überschattet, die zum Verarbeiten der Komprimierung gedauert hat. Komprimieren Sie Dateien, die kleiner als etwa 150 bis 1000 Bytes sind (abhängig vom Inhalt der Datei und der Effizienz der Komprimierung). Der Aufwand für die Komprimierung kleiner Dateien kann dazu führen, dass eine komprimierte Datei größer als die nicht komprimierte Datei ist.

Wenn ein Client komprimierten Inhalt verarbeiten kann, muss der Client den Server über seine Funktionen informieren, indem er den Accept-Encoding Header mit der Anforderung sendet. Wenn ein Server komprimierten Inhalt sendet, muss er Informationen zur Content-Encoding Codierung der komprimierten Antwort in den Header einschließen. Die von der Middleware unterstützten Bezeichnungen für die Inhaltscodierung sind in der folgenden Tabelle aufgeführt.

Accept-Encoding Headerwerte Unterstützte Middleware BESCHREIBUNG
br Ja (Standard) Brotli compressed data format (Komprimiertes Brotli-Datenformat)
deflate Nein KOMPRIMIERTES DEFLATE-Datenformat
exi Nein Effizienter W3C-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, die nicht explizit angefordert werden

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 weiter unten unter Benutzerdefinierte Anbieter.

Die Middleware kann auf die Gewichtung von Qualitätswerten (qvalue, ) reagieren, wenn sie q vom Client gesendet wird, um Komprimierungsschemas zu priorisieren. Weitere Informationen finden Sie unter RFC 7231: Accept-Encoding.

Komprimierungsalgorithmen unterliegen einem Kompromiss zwischen der Komprimierungsgeschwindigkeit und der Effektivität der Komprimierung. Die Effektivität bezieht sich in diesem Kontext auf die Größe der Ausgabe nach der Komprimierung. Die kleinste Größe wird durch die optimale Komprimierung erreicht.

Die Header für das Anfordern, Senden, Zwischenspeichern und Empfangen komprimierter Inhalte werden in der folgenden Tabelle beschrieben.

Header Rolle
Accept-Encoding Wird vom Client an den Server gesendet, um die inhaltscodierungsschemas anzugeben, die für den Client akzeptabel sind.
Content-Encoding Wird vom Server an den Client gesendet, um die Codierung des Inhalts in der Nutzlast anzugeben.
Content-Length Bei der Komprimierung wird der Content-Length Header entfernt, da sich der Textinhalt ändert, wenn die Antwort komprimiert wird.
Content-MD5 Bei der Komprimierung wird der Content-MD5 Header entfernt, da sich der Textinhalt geändert hat und der Hash nicht mehr gültig ist.
Content-Type Gibt den MIME-Typ des Inhalts an. Jede Antwort sollte ihre Content-Type angeben. Die Middleware überprüft diesen Wert, um zu bestimmen, ob die Antwort komprimiert werden soll. Die Middleware gibt einen Satz von MIME-Standardtypen an, die codiert werden können. Sie können jedoch MIME-Typen ersetzen oder hinzufügen.
Vary Beim Senden durch den Server mit dem Wert Accept-Encoding an Clients und Proxys gibt der Header Vary dem Client oder Proxy an, dass antworten basierend auf dem Wert des Headers der Anforderung zwischengespeichert (variieren) werden Accept-Encoding sollen. Das Ergebnis der Rückgabe von Inhalten mit dem Vary: Accept-Encoding Header ist, dass sowohl komprimierte als auch nicht komprimierte Antworten separat zwischengespeichert werden.

Erkunden Sie die Features der Middleware für die Antwortkomprimierung mit der Beispiel-App. Das Beispiel veranschaulicht Folgendes:

  • Die Komprimierung von App-Antworten mithilfe von Gzip und benutzerdefinierten Komprimierungsanbietern.
  • Hinzufügen eines MIME-Typs zur Standardliste der MIME-Typen für die Komprimierung.

Paket

Um die Middleware in ein Projekt einzuschließen, fügen Sie einen Verweis auf das Microsoft.AspNetCore.App Metapakethinzu, das das Paket Microsoft.AspNetCore.ResponseCompression enthält.

Konfiguration

Der folgende Code zeigt, wie die Middleware für die Antwortkomprimierung für MIME-Standardtypen und Komprimierungsanbieter(Brotli und Gzip)aktiviert wird:

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 Developeroder Postman, um den Accept-Encoding Anforderungsheader festzulegen und die Antwortheader, die Größe und den Text zu untersuchen.

Senden Sie eine Anforderung an die Beispiel-App ohne den Accept-Encoding -Header, und stellen Sie fest, dass die Antwort nicht komprimiert ist. Die Content-Encoding Header und sind in der Antwort nicht Vary vorhanden.

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

Senden Sie eine Anforderung mit dem Accept-Encoding: br Header (Brotli-Komprimierung) an die Beispiel-App, und beobachten Sie, dass die Antwort komprimiert ist. Die Content-Encoding Header und sind in der Antwort Vary vorhanden.

Fiddler-Fenster mit dem Ergebnis einer Anforderung mit dem Accept-Encoding-Header und dem Wert br. Die Vary- und Content-Encoding-Header werden der Antwort hinzugefügt. Die Antwort wird komprimiert.

Anbieter

Brotli-Komprimierungsanbieter

Verwenden Sie BrotliCompressionProvider , um Antworten mit dem komprimierten Brotli-Datenformatzu komprimieren.

Wenn dem keine Komprimierungsanbieter explizit hinzugefügt CompressionProviderCollection werden:

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

Der Brotli-Komprimierungsanbieter muss hinzugefügt werden, wenn 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 den Komprimierungsgrad mit BrotliCompressionProviderOptions fest. Der Brotli-Komprimierungsanbieter verwendet standardmäßig die schnellste Komprimierungsstufe(CompressionLevel.Fastest),die möglicherweise nicht die effizienteste Komprimierung erzeugt. Wenn die effizienteste Komprimierung gewünscht ist, konfigurieren Sie die Middleware für eine optimale Komprimierung.

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

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

Gzip-Komprimierungsanbieter

Verwenden Sie GzipCompressionProvider , um Antworten im Gzip-Dateiformatzu komprimieren.

Wenn dem keine Komprimierungsanbieter explizit hinzugefügt CompressionProviderCollection werden:

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

Der Gzip-Komprimierungsanbieter muss hinzugefügt werden, wenn 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 den Komprimierungsgrad mit GzipCompressionProviderOptions fest. Der Gzip-Komprimierungsanbieter verwendet standardmäßig die schnellste Komprimierungsstufe(CompressionLevel.Fastest),die möglicherweise nicht die effizienteste Komprimierung erzeugt. Wenn die effizienteste Komprimierung gewünscht ist, konfigurieren Sie die Middleware für eine optimale Komprimierung.

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

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

Benutzerdefinierte Anbieter

Erstellen Sie mit benutzerdefinierte Komprimierungsimplementierungen. ICompressionProvider EncodingNameStellt die Inhaltscodierung dar, die von ICompressionProvider diesem erzeugt wird. Die Middleware verwendet diese Informationen, um den Anbieter basierend auf der im Header der Anforderung angegebenen Liste Accept-Encoding auszuwählen.

Mithilfe der Beispiel-App sendet der Client eine Anforderung mit dem Accept-Encoding: mycustomcompression -Header. Die Middleware verwendet die benutzerdefinierte Komprimierungsimplementierung und gibt die Antwort mit einem Header Content-Encoding: mycustomcompression zurück. Der Client muss in der Lage sein, die benutzerdefinierte Codierung zu dekomprimieren, 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 mit dem Header an die Beispiel-App, Accept-Encoding: mycustomcompression und beobachten Sie die Antwortheader. Die Vary Header und sind in der Antwort Content-Encoding vorhanden. Der Antwortkörper (nicht dargestellt) wird vom Beispiel nicht komprimiert. Es gibt keine Komprimierungsimplementierung in CustomCompressionProvider der -Klasse des Beispiels. Das Beispiel zeigt jedoch, wo Sie einen solchen Komprimierungsalgorithmus implementieren würden.

Fiddler-Fenster mit dem Ergebnis einer Anforderung mit dem Accept-Encoding und dem Wert mycustomcompression. Die Vary- und Content-Encoding-Header werden der Antwort hinzugefügt.

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 fügen Sie MIME-Typen durch die Middlewareoptionen für die Antwortkomprimierung an. Beachten Sie, dass MIME-Platzhaltertypen wie text/* nicht unterstützt werden. Die Beispiel-App fügt einen MIME-Typ für hinzu und komprimiert und stellt das ASP.NET Core image/svg+xml Bannerbild (banner.svg) zur Anwendung.

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 EnableForHttps werden, die standardmäßig deaktiviert ist. Die Verwendung der Komprimierung mit dynamisch generierten Seiten kann zu Sicherheitsproblemen führen, z. B. den ANGRIFFs- und SICHERHEITSVERLETZUNGsangriffen.

Hinzufügen des Vary-Headers

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

Middlewareproblem, wenn hinter einem Nginx-Reverseproxy

Wenn eine Anforderung per Proxy von Nginx zu senden ist, wird Accept-Encoding der Header entfernt. Das Entfernen des Accept-Encoding Headers verhindert, dass die Middleware die Antwort komprimiert. Weitere Informationen finden Sie unter NGINX: Compression and Decompression ( NGINX: Komprimierung und Dekomprimierung). Dieses Problem wird durch Herausfinden der Pass-Through-Komprimierung für Nginx (aspnet/BasicMiddleware #123) nachverfolgt.

Arbeiten mit der dynamischen IIS-Komprimierung

Wenn Sie ein aktives IIS Dynamic Compression Module auf Serverebene konfiguriert haben, das Sie für eine App deaktivieren möchten, deaktivieren Sie das Modul zusätzlich zurweb.configDatei. Weitere Informationen finden Sie unter Disabling IIS modules (Deaktivieren von IIS-Modulen).

Problembehandlung

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

  • Der Header ist mit dem Wert , , oder der benutzerdefinierten Codierung vorhanden, die einem von Ihnen festgelegten Accept-Encoding br benutzerdefinierten gzip * Komprimierungsanbieter entspricht. Der Wert darf nicht sein identity oder über eine Qualitätswerteinstellung (qvalue, ) von q 0 (null) verfügen.
  • Der MIME-Typ ( ) muss festgelegt werden und mit einem Content-Type mime-Typ übereinstimmen, der für konfiguriert ResponseCompressionOptions ist.
  • Die Anforderung darf den Header nicht Content-Range enthalten.
  • Die Anforderung muss ein unsicheres Protokoll (HTTP) verwenden, es sei denn, das sichere Protokoll (https) ist in den Middlewareoptionen für die Antwortkomprimierung konfiguriert. Beachten Sie die oben beschriebene Gefahr beim Aktivieren der sicheren Inhaltskomprimierung.

Zusätzliche Ressourcen

Die Netzwerkbandbreite ist eine begrenzte Ressource. Das Reduzieren der Antwortgröße erhöht in der Regel die Reaktionsfähigkeit einer App, häufig erheblich. Eine Möglichkeit, die Nutzlastgröße zu reduzieren, besteht in der Komprimierung der Antworten einer App.

Anzeigen oder Herunterladen von Beispielcode (Vorgehensweise zum Herunterladen)

Einsatz von Middleware für die Antwortkomprimierung

Verwenden Sie serverbasierte Antwortkomprimierungstechnologien in IIS, Apache oder Nginx. Die Leistung der Middleware wird wahrscheinlich nicht mit der der Servermodule übereinstimmen. HTTP.sys Serverserver und Server bieten derzeit keine integrierte Kestrel Unterstützung für die Komprimierung.

Verwenden Sie die Middleware für die Antwortkomprimierung, wenn Sie:

Antwortkomprimierung

In der Regel kann jede Antwort, die nicht nativ komprimiert ist, von der Antwortkomprimierung profitieren. Antworten, die nicht nativ komprimiert sind, sind in der Regel: CSS, JavaScript, HTML, XML und JSON. Sie sollten keine nativ komprimierten Objekte wie PNG-Dateien komprimieren. Wenn Sie versuchen, eine nativ komprimierte Antwort weiter zu komprimieren, wird jede kleine zusätzliche Verkleinerung der Größe und Übertragungszeit wahrscheinlich durch die Zeit überschattet, die zum Verarbeiten der Komprimierung gezeitet hat. Komprimieren Sie Keine Dateien, die kleiner als etwa 150 bis 1000 Bytes sind (abhängig vom Inhalt der Datei und der Effizienz der Komprimierung). Der Mehraufwand für das Komprimieren kleiner Dateien kann eine komprimierte Datei erzeugen, die größer als die nicht komprimierte Datei ist.

Wenn ein Client komprimierten Inhalt verarbeiten kann, muss der Client den Server über seine Funktionen informieren, indem er den Header Accept-Encoding mit der Anforderung sendet. Wenn ein Server komprimierten Inhalt sendet, muss er Informationen zur Codierung der komprimierten Antwort in den Content-Encoding Header enthalten. Die von der Middleware unterstützten Inhaltscodierungsbezeichnungen sind in der folgenden Tabelle aufgeführt.

Accept-Encoding Headerwerte Middleware unterstützt BESCHREIBUNG
br Nein Brotli-Komprimiertes Datenformat
deflate Nein DEFLATE- komprimiertes Datenformat
exi Nein Effizienter W3C-XML-Austausch
gzip Ja (Standard) 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, die nicht explizit angefordert wurden

Weitere Informationen finden Sie in der offiziellen IANA-Inhaltscodierungsliste.

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

Die Middleware kann auf die Gewichtung von Qualitätswerten (qvalue, ) reagieren, wenn sie vom Client gesendet wird, um q Komprimierungsschemas zu priorisieren. Weitere Informationen finden Sie unter RFC 7231: Accept-Encoding.

Komprimierungsalgorithmen unterliegen einem Kompromiss zwischen der Komprimierungsgeschwindigkeit und der Effektivität der Komprimierung. Effektivität bezieht sich in diesem Kontext auf die Größe der Ausgabe nach der Komprimierung. Die kleinste Größe wird durch die optimale Komprimierung erreicht.

Die Header für das Anfordern, Senden, Zwischenspeichern und Empfangen komprimierter Inhalte werden in der folgenden Tabelle beschrieben.

Header Rolle
Accept-Encoding Wird vom Client an den Server gesendet, um die inhaltscodierungsschemas anzugeben, die für den Client akzeptabel sind.
Content-Encoding Wird vom Server an den Client gesendet, um die Codierung des Inhalts in der Nutzlast anzugeben.
Content-Length Wenn die Komprimierung erfolgt, wird der Header entfernt, da sich Content-Length der Textinhalt ändert, wenn die Antwort komprimiert wird.
Content-MD5 Bei der Komprimierung wird der Content-MD5 Header entfernt, da sich der Textinhalt geändert hat und der Hash nicht mehr gültig ist.
Content-Type Gibt den MIME-Typ des Inhalts an. Jede Antwort sollte ihre Content-Type angeben. Die Middleware überprüft diesen Wert, um zu bestimmen, ob die Antwort komprimiert werden soll. Die Middleware gibt einen Satz von MIME-Standardtypen an, die codiert werden können. Sie können jedoch MIME-Typen ersetzen oder hinzufügen.
Vary Beim Senden durch den Server mit dem Wert Accept-Encoding an Clients und Proxys gibt der Header Vary dem Client oder Proxy an, dass antworten basierend auf dem Wert des Headers der Anforderung zwischengespeichert (variieren) werden Accept-Encoding sollen. Das Ergebnis der Rückgabe von Inhalten mit dem Vary: Accept-Encoding Header ist, dass sowohl komprimierte als auch nicht komprimierte Antworten separat zwischengespeichert werden.

Erkunden Sie die Features der Middleware für die Antwortkomprimierung mit der Beispiel-App. Das Beispiel veranschaulicht Folgendes:

  • Die Komprimierung von App-Antworten mithilfe von Gzip und benutzerdefinierten Komprimierungsanbietern.
  • Hinzufügen eines MIME-Typs zur Standardliste der MIME-Typen für die Komprimierung.

Paket

Um die Middleware in ein Projekt einzuschließen, fügen Sie einen Verweis auf das Microsoft.AspNetCore.App Metapakethinzu, das das Paket Microsoft.AspNetCore.ResponseCompression enthält.

Konfiguration

Der folgende Code zeigt, wie die Middleware für die Antwortkomprimierung für MIME-Standardtypen und den Gzip-Komprimierungsanbieteraktiviert wird:

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

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

Hinweise:

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

Senden Sie eine Anforderung an die Beispiel-App ohne den Accept-Encoding -Header, und stellen Sie fest, dass die Antwort nicht komprimiert ist. Die Content-Encoding Header und sind in der Antwort nicht Vary vorhanden.

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

Senden Sie eine Anforderung mit dem Header an die Beispiel-App, Accept-Encoding: gzip und beobachten Sie, dass die Antwort komprimiert ist. Die Content-Encoding Header und sind in der Antwort Vary vorhanden.

Fiddler-Fenster mit dem Ergebnis einer Anforderung mit dem Accept-Encoding-Header und dem Wert gzip. Die Vary- und Content-Encoding-Header werden der Antwort hinzugefügt. Die Antwort wird komprimiert.

Anbieter

Gzip-Komprimierungsanbieter

Verwenden Sie GzipCompressionProvider , um Antworten im Gzip-Dateiformatzu komprimieren.

Wenn dem keine Komprimierungsanbieter explizit hinzugefügt CompressionProviderCollection werden:

  • Der Gzip-Komprimierungsanbieter wird standardmäßig dem Array von Komprimierungsanbietern hinzugefügt.
  • Die Komprimierung ist standardmäßig auf Gzip eingestellt, wenn der Client die Gzip-Komprimierung unterstützt.
public void ConfigureServices(IServiceCollection services)
{
    services.AddResponseCompression();
}

Der Gzip-Komprimierungsanbieter muss hinzugefügt werden, wenn 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 den Komprimierungsgrad mit GzipCompressionProviderOptions fest. Der Gzip-Komprimierungsanbieter verwendet standardmäßig die schnellste Komprimierungsstufe(CompressionLevel.Fastest),die möglicherweise nicht die effizienteste Komprimierung erzeugt. Wenn die effizienteste Komprimierung gewünscht ist, konfigurieren Sie die Middleware für eine optimale Komprimierung.

Compression Level BESCHREIBUNG
CompressionLevel.Fastest 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 durchgeführt werden.
CompressionLevel.Optimal Antworten sollten optimal komprimiert werden, auch wenn die Komprimierung mehr Zeit in Anspruch nimmt.
public void ConfigureServices(IServiceCollection services)
{
    services.AddResponseCompression();

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

Benutzerdefinierte Anbieter

Erstellen Sie mit benutzerdefinierte Komprimierungsimplementierungen. ICompressionProvider EncodingNameStellt die Inhaltscodierung dar, die von ICompressionProvider diesem erzeugt wird. Die Middleware verwendet diese Informationen, um den Anbieter basierend auf der im Header der Anforderung angegebenen Liste Accept-Encoding auszuwählen.

Mithilfe der Beispiel-App sendet der Client eine Anforderung mit dem Accept-Encoding: mycustomcompression -Header. Die Middleware verwendet die benutzerdefinierte Komprimierungsimplementierung und gibt die Antwort mit einem Content-Encoding: mycustomcompression Header zurück. Der Client muss in der Lage sein, die benutzerdefinierte Codierung zu dekomprimieren, 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 mit dem -Header an die Beispiel-App, Accept-Encoding: mycustomcompression und beobachten Sie die Antwortheader. Die Vary Header und sind in der Antwort Content-Encoding 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 dem Ergebnis einer Anforderung mit dem Accept-Encoding-Header und dem Wert mycustomcompression. Die Vary- und Content-Encoding-Header werden der Antwort hinzugefügt.

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 Sie MIME-Typen durch die Middlewareoptionen für die Antwortkomprimierung, oder fügen Sie sie an. Beachten Sie, dass Platzhalter-MIME-Typen wie text/* nicht unterstützt werden. Die Beispiel-App fügt einen MIME-Typ für hinzu image/svg+xml und komprimiert und stellt das ASP.NET Core Bannerbild (banner.svg) zur Auswahl.

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 EnableForHttps werden, die standardmäßig deaktiviert ist. Die Verwendung der Komprimierung mit dynamisch generierten Seiten kann zu Sicherheitsproblemen führen, z. B. zu DEN ANGRIFFEN MITHILFE VON ANGRIFFEN und SICHERHEITSVERLETZUNGEN.

Hinzufügen des Vary-Headers

Beim Komprimieren von Antworten basierend auf dem Accept-Encoding Header gibt es möglicherweise 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.

Middlewareproblem, wenn hinter einem Nginx-Reverseproxy

Wenn eine Anforderung von Nginx übermittelt wird, wird der Accept-Encoding Header entfernt. Das Entfernen des Accept-Encoding Headers verhindert, dass die Middleware die Antwort komprimiert. Weitere Informationen finden Sie unter NGINX: Komprimierung und Dekomprimierung. Dieses Problem wird durch Abbildung der Pass-Through-Komprimierung für Nginx (aspnet/BasicMiddleware #123)nachverfolgt.

Arbeiten mit der dynamischen IIS-Komprimierung

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

Problembehandlung

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

  • Der Header ist mit dem Wert , oder der Accept-Encoding gzip * benutzerdefinierten Codierung vorhanden, die einem von Ihnen eingerichteten benutzerdefinierten Komprimierungsanbieter entspricht. Der Wert darf nicht identity sein oder eine Qualitätswerteinstellung (qvalue, q ) von 0 (null) aufweisen.
  • Der MIME-Typ ( Content-Type ) muss festgelegt werden und mit einem MIME-Typ übereinstimmen, der für konfiguriert ResponseCompressionOptions ist.
  • Die Anforderung darf den Header nicht Content-Range enthalten.
  • Die Anforderung muss unsicheres Protokoll (http) verwenden, es sei denn, das sichere Protokoll (https) ist in den Middlewareoptionen für die Antwortkomprimierung konfiguriert. Beachten Sie die oben beschriebene Gefahr beim Aktivieren der sicheren Inhaltskomprimierung.

Zusätzliche Ressourcen