Komprese odpovědí v ASP.NET Core

Šířka pásma sítě je omezený prostředek. Zmenšení velikosti odpovědi obvykle zvyšuje rychlost odezvy aplikace, často výrazně. Jedním ze způsobů, jak zmenšit velikost datové části, je komprimovat odpovědi z aplikace. Tento článek popisuje, jak implementovat kompresi odpovědí pro vaše aplikace pomocí middlewaru Komprese odpovědí v ASP.NET Core.

Prozkoumání komprese pomocí protokolu HTTPS

Komprimované odpovědi přes zabezpečená připojení je možné řídit pomocí EnableForHttps možnosti, která je ve výchozím nastavení zakázaná z důvodu rizika zabezpečení. Použití komprese u dynamicky generovaných stránek může aplikaci vystavit CRIME a BREACH útokům. CRIME a BREACH útoky je možné zmírnit v ASP.NET Core pomocí antiforgery tokenů. Další informace najdete v tématu Prevence útoků založených na padělání žádosti posílané mezi weby (XSRF/CSRF) v ASP.NET Core. Informace o zmírnění BREACH útoků najdete v tématu Zmírnění rizik na adrese http://www.breachattack.com/.

I když aplikace zakáže vlastnost EnableForHttps (false), Internetové Informační Služby (IIS), IIS Express a Azure App Service může použít Gzip na webovém serveru IIS. Při kontrole hlaviček odpovědí si poznamenejte hodnotu hlavičky serveru . Neočekávaná hodnota hlavičky odpovědi content-encoding může být výsledkem webového serveru, nikoli konfigurace ASP.NET Core aplikace.

Určení, kdy použít middleware pro kompresi odpovědí

Používejte technologie komprese odpovědí založené na serveru ve službě IIS, Apache nebo Nginx. Výkon middlewaru komprese odpovědí pravděpodobně nemůže odpovídat výkonu modulů serveru. Server HTTP.sys a Kestrel server v současné době nenabízejí integrovanou podporu komprese.

Middleware pro kompresi odpovědí použijte, když je aplikace:

• Nelze použít následující technologie komprese založené na serveru:

  • Dynamické ukládání do mezipaměti a komprese služby IIS
  • Modul Apache mod_deflate
  • Komprese a dekomprese Nginx

• Hostování přímo na:

  • server HTTP.sys
  • Kestrel Server

Prozkoumejte kompresi odpovědí

Každá odpověď, která není nativně komprimovaná, může obvykle těžit z komprese odpovědí. Mezi odpovědi, které nejsou nativně komprimované, obvykle patří CSS, JavaScript, HTML, XML a JSON. Nekomprimujte nativně komprimované soubory, jako jsou například soubory PNG. Při pokusu o další komprimaci nativně komprimované odpovědi je pravděpodobné, že jakékoli malé zmenšení velikosti a času přenosu je pravděpodobně zastíněno časem potřebným ke zpracování komprese. Nekomprimujte soubory menší než asi 150 – 1 000 bajtů v závislosti na obsahu souboru a efektivitě komprese. Náklady na komprimaci malých souborů mohou způsobit, že komprimovaný soubor bude větší než nekomprimovaný.

Když klient může zpracovávat komprimovaný obsah, musí klient informovat server o jeho schopnostech odesláním hlavičky Accept-Encoding s požadavkem. Když server odesílá komprimovaný obsah, musí obsahovat informace v hlavičce Content-Encoding týkající se kódování komprimované odpovědi.

Následující tabulka uvádí označení kódování obsahu pro hlavičku Accept-Encoding a označuje, jestli middleware komprese odpovědí podporuje označení.

Označení	Middleware	Formát	Podrobnosti
br	Ano (výchozí)	Formát komprimovaných dat Brotli	RFC 7932
deflate	No	DEFLATE Komprimovaný formát dat	RFC 1951
exi	No	Efektivní výměna XML (EXI)	Doporučení W3C
gzip	Yes	Formát souboru Gzip	RFC 1952
identity	Yes	"Bez kódování" – odpověď nesmí být zakódovaná.	Řešení potíží s kompresí odpovědí
pack200-gzip	No	Formát přenosu sítě pro archivy Java	JSR 200
* (hvězdička)	Yes	Zástupný znak – jakékoli dostupné kódování obsahu, které není explicitně požadováno	Řešení potíží s kompresí odpovědí

Další informace najdete v oficiálním seznamu kódování obsahu IANA pro parametry HTTP.

Middleware komprese odpovědí umožňuje přidat další zprostředkovatele komprese pro vlastní Accept-Encoding hodnoty hlaviček. Další informace najdete v části Vlastní zprostředkovatelé dále v tomto článku.

Middleware komprese odpovědí je schopen reagovat na hodnotu kvality (qvalue, q) zohledněnou při odesílání klientem k upřednostnění schémat komprese. Další informace naleznete v dokumentu RFC 9110: Sémantika HTTP (oddíl 12.5.3 Accept-Encoding).

Algoritmy komprese podléhají kompromisu mezi rychlostí komprese a účinností komprese. Účinnost v tomto kontextu odkazuje na velikost výstupu po kompresi. Nejmenší velikosti je dosaženo pomocí optimální komprese.

Hlavičky, které se týkají vyžádání, odesílání, ukládání do mezipaměti a příjmu komprimovaného obsahu, jsou popsány v následující tabulce.

Header	Role	Podrobnosti
Accept-Encoding	Odesláno z klienta na server, aby indikuje schémata kódování obsahu přijatelná pro klienta.	záhlaví Accept-Encoding
Content-Encoding	Odesláno ze serveru klientovi, aby označil kódování obsahu v datové části.	Hlavička Content-Encoding
Content-Length	Když dojde k kompresi, Content-Length záhlaví se odebere, protože se obsah těla změní při kompresi odpovědi.	Hlavička Content-Length
Content-MD5	Když dojde ke kompresi, Content-MD5 se hlavička odebere, protože se změní obsah těla a hodnota hash už není platná.	RFC 1864: Pole hlavičky Content-MD5
Content-Type	Určuje typ MIME obsahu. Každá odpověď by měla zadat její Content-Type hodnotu. Middleware komprese odpovědi zkontroluje tuto hodnotu a určí, jestli má být odpověď komprimována. Middleware komprese odpovědí určuje sadu výchozích typů MIME , které může kódovat, a mohou být nahrazeny nebo přidány.	Hlavička typu obsahu
Vary	Když server odešle hodnotu Accept-Encoding klientům a proxy serverům, Vary hlavička značí klientovi nebo proxy serveru, že by se měly ukládat odpovědi (různé) v závislosti na hodnotě Accept-Encoding hlavičky požadavku. Výsledkem vrácení obsahu s hlavičkou Vary: Accept-Encoding je, že komprimované i nekomprimované odpovědi se ukládají do mezipaměti samostatně.	Různá záhlaví

Prozkoumejte funkce middlewaru pro kompresi odpovědí pomocí ukázkové aplikace. Ukázka ukazuje:

• Komprese odpovědí aplikace pomocí Gzip a vlastních poskytovatelů komprese.
• Jak přidat typ MIME do výchozího seznamu typů MIME pro kompresi.
• Postup přidání vlastního zprostředkovatele komprese odpovědí

Konfigurace middlewaru komprese odpovědí

Následující kód ukazuje, jak povolit middleware pro kompresi odpovědí pro výchozí MIME typy a poskytovatele komprese (Brotli a Gzip):

var builder = WebApplication.CreateBuilder(args);

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

var app = builder.Build();

app.UseResponseCompression();

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

app.Run();

Poznámky k middlewaru pro kompresi odpovědí

Při práci s middlewarem Pro kompresi odpovědí mějte na paměti následující body:

• Nastavení EnableForHttps vlastnosti true je bezpečnostní riziko. Další informace najdete v části Komprese s HTTPS výše v tomto článku.
• Aplikace musí zavolat metodu app.UseResponseCompressionpřed jakýmkoli middlewarem, který komprimuje odpovědi. Další informace najdete v tématu ASP.NET Core Middleware > pořadí middlewaru.
• K nastavení hlavičky požadavku a prozkoumání hlaviček, velikosti a textu požadavku použijte nástroj, jako je Accept-Encoding Edition.

Odešlete požadavek do ukázkové aplikace bez hlavičky Accept-Encoding a všimněte si, že odpověď není dekomprimovaná. Záhlaví Content-Encoding není v kolekci odpovědi Headers.

Například ve Firefoxu Developer:

1. Vyberte kartu sítě.
2. Klikněte pravým tlačítkem myši na požadavek v seznamu síťových požadavků a vyberte Upravit a znovu odeslat.
3. Accept-Encoding: Změňte hodnotu z gzip, deflate, br na none.
4. Vyberte Odeslat.

Odešlete žádost do ukázkové aplikace v prohlížeči pomocí vývojářských nástrojů a všimněte si, že odpověď je komprimovaná. Na odpovědi jsou přítomny hlavičky Content-Encoding a Vary.

Posouzení poskytovatelů

Tato část obsahuje podrobnosti o poskytovatelích komprese, včetně Brotli, Gzip a vlastních poskytovatelů.

Poskytovatelé komprese Brotli a Gzip

Třídu BrotliCompressionProvider použijte ke komprimaci odpovědí pomocí RFC 7932: Brotli Compressed Data Format.

Pokud do třídy nejsou explicitně přidáni žádní zprostředkovatelé komprese:CompressionProviderCollection

• Ve výchozím nastavení jsou zprostředkovatelé komprese Brotli a Gzip přidány do pole zprostředkovatelů komprese.
• Když klient podporuje formát komprimovaných dat Brotli, ve výchozím nastavení se použije komprese Brotli.
• Pokud klient nepodporuje Brotli, komprese se ve výchozím nastavení nastaví na Gzip, pokud klient podporuje kompresi Gzip.

Když přidáte poskytovatele komprese, ostatní poskytovatelé se nepřidají. Pokud je například zprostředkovatel komprese Gzip jediným přidaným zprostředkovatelem, nepřidají se žádní další zprostředkovatelé komprese.

Note

Odkazy na dokumentaci k referenčnímu zdroji .NET obvykle načítají výchozí větev úložiště, která představuje aktuální vývoj pro příští verzi .NET. Pokud chcete vybrat značku pro konkrétní verzi, použijte rozevírací seznam pro přepnutí větví nebo značek. Další informace najdete v tématu Jak vybrat značku verze zdrojového kódu ASP.NET Core (dotnet/AspNetCore.Docs #26205).

Následující kód:

• Povolí kompresi odpovědí pro požadavky HTTPS.
• Přidá poskytovatele komprese odpovědí Brotli a Gzip.

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

Nastavte úroveň komprese pomocí BrotliCompressionProviderOptions třídy a GzipCompressionProviderOptions třídy. Poskytovatelé komprese Brotli a Gzip mají ve výchozím nastavení nastavenu nejrychlejší úroveň komprese, jak je určeno ve výčtu CompressionLevel.Fastest. Tento přístup však nemusí způsobit nejúčinnější kompresi. Pokud je požadovaná nejúčinnější komprese, nakonfigurujte middleware komprese odpovědí pro optimální kompresi.

Hodnoty, které označují, zda operace komprese upřednostňuje rychlost nebo velikost, najdete ve výčtu CompressionLevel.

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

Vlastní poskytovatelé

Vytvořte vlastní implementace komprese pomocí ICompressionProvider rozhraní. Vlastnost EncodingName představuje kódování obsahu, které to ICompressionProvider vytvoří. Middleware komprese odpovědí používá tyto informace k výběru poskytovatele na základě seznamu zadaného v Accept-Encoding hlavičce požadavku.

Požadavky na ukázkovou aplikaci s Accept-Encoding: mycustomcompression hlavičkou vrátí odpověď s hlavičkou Content-Encoding: mycustomcompression . Aby vlastní implementace komprese fungovala, musí být klient schopen dekomprimovat vlastní kódování.

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;
    }
}

V předchozím kódu příklad nekomprimuje tělo odpovědi. Ukázka ale ukazuje, kde implementovat vlastní algoritmus komprese.

Kontrola typů MIME

Middleware komprese odpovědí určuje výchozí sadu typů MIME pro kompresi. Úplný seznam podporovaných typů MIME najdete ve zdrojovém kódu.

Note

Odkazy na dokumentaci k referenčnímu zdroji .NET obvykle načítají výchozí větev úložiště, která představuje aktuální vývoj pro příští verzi .NET. Pokud chcete vybrat značku pro konkrétní verzi, použijte rozevírací seznam pro přepínání větví nebo značek. Další informace najdete v tématu Jak vybrat značku verze zdrojového kódu ASP.NET Core (dotnet/AspNetCore.Docs #26205).

Nahraďte nebo připojte typy MIME pomocí vlastnosti ResponseCompressionOptions.MimeTypes. Typy MIME se zástupnými znaky, jako text/* jsou nepodporovaná. Ukázková aplikace přidá typ MIME pro image/svg+xml a komprimuje a poskytuje bannerový obrázek ASP.NET Core 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();

Přidejte hlavičku Vary

Pokud jsou odpovědi komprimovány na základě hlavičky požadavku Accept-Encoding, může existovat jedna nekomprimovaná a více komprimovaných verzí odpovědi. Pokud je potřeba informovat klientské a proxy servery, že existuje více verzí a měly by být uloženy, přidá se hlavička Vary s hodnotou Accept-Encoding. Middleware odpovědi přidá hlavičku Vary do souboru ResponseCompressionBody.cs automaticky při komprimaci odpovědi.

Note

Odkazy na dokumentaci k referenčnímu zdroji .NET obvykle načítají výchozí větev úložiště, která představuje aktuální vývoj pro příští verzi .NET. Pokud chcete vybrat značku pro určité vydání, použijte rozbalovací seznam pro přepnutí větví nebo značek. Další informace najdete v tématu Jak vybrat značku verze zdrojového kódu ASP.NET Core (dotnet/AspNetCore.Docs #26205).

Problémy s reverzním proxy serverem Nginx

Když Nginx proxy zpracovává požadavek, Accept-Encoding záhlaví je odstraněno. Odebrání hlavičky Accept-Encoding zabraňuje middlewaru pro kompresi odpovědí komprimovat odpověď. Další informace naleznete v tématu Nginx: Komprese a dekomprese. Tento problém se sleduje v problému na GitHubu dotnet/aspnetcore #5989 - Vyřešte průchozí kompresi pro Nginx.

Zakázání dynamické komprese služby IIS

Pokud chcete zakázat modul dynamické komprese služby IIS nakonfigurovaný na úrovni serveru, přečtěte si téma Zakázání modulů SLUŽBY IIS.

Řešení potíží s kompresí odpovědí

Použijte nástroj, jako je Firefox Browser – Edice Developer , která umožňuje nastavit hlavičku Accept-Encoding požadavku a studovat hlavičky, velikost a text odpovědi. Middleware komprese odpovědí ve výchozím nastavení komprimuje odpovědi, které splňují následující podmínky:

• Hlavička Accept-Encoding se nachází s hodnotou br, gzip, * (hvězdička) nebo vlastní kódování odpovídající vlastnímu poskytovateli komprese. Hodnota nesmí být identity (bez kódování) nebo musí mít hodnotu kvality (qvalue, q) nastavenou na hodnotu 0 (nula).

• Musí být nastaven typ MIME (Content-Type) a musí odpovídat typu MIME nakonfigurovaného ve ResponseCompressionOptions třídě.

• Požadavek nesmí obsahovat hlavičku Content-Range.

• Požadavek musí používat nezabezpečený hypertextový protokol (http), pokud není v možnostech middlewaru komprese odpovědi nakonfigurovaný zabezpečený protokol hypertextu (https).

  Important

  Projděte si rizika spojená s povolením zabezpečené komprese obsahu, jak je popsáno v části Komprese s HTTPS výše v tomto článku.

Kontrola ukázky nasazené v Azure

Ukázková aplikace nasazená do Azure má následující soubor Program.cs:

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

Související obsah

• Zobrazení nebo stažení ukázkového kódu (postup stažení)
• Zdroj middlewaru pro kompresi odpovědí
• RFC 9110: Sémantika HTTP (oddíl 8.4.1 Kódování obsahu)
• RFC 9110: Sémantika HTTP (oddíl 8.4.1.3 Gzip Kódování)
• RFC 1952: Specifikace formátu souboru GZIP verze 4.3