ASP.NET Core での応答圧縮Response compression in ASP.NET Core

ネットワーク帯域幅はリソースが限られています。Network bandwidth is a limited resource. 通常、応答のサイズを小さくすると、アプリの応答性が大幅に向上します。Reducing the size of the response usually increases the responsiveness of an app, often dramatically. ペイロードサイズを減らす方法の1つは、アプリの応答を圧縮することです。One way to reduce payload sizes is to compress an app's responses.

サンプル コードを表示またはダウンロードします (ダウンロード方法)。View or download sample code (how to download)

応答圧縮ミドルウェアを使用する場合When to use Response Compression Middleware

IIS、Apache、または Nginx のサーバーベースの応答圧縮テクノロジを使用します。Use server-based response compression technologies in IIS, Apache, or Nginx. ミドルウェアのパフォーマンスがサーバーモジュールのパフォーマンスと一致しない場合があります。The performance of the middleware probably won't match that of the server modules. HTTP.sys server Server と kestrel server では、現在、組み込みの圧縮サポートは提供されていません。HTTP.sys server server and Kestrel server don't currently offer built-in compression support.

次の場合に応答圧縮ミドルウェアを使用します。Use Response Compression Middleware when you're:

応答圧縮Response compression

通常、ネイティブに圧縮されていない応答は、応答圧縮の恩恵を受けることができます。Usually, any response not natively compressed can benefit from response compression. ネイティブに圧縮されていない応答には、通常、CSS、JavaScript、HTML、XML、JSON が含まれます。Responses not natively compressed typically include: CSS, JavaScript, HTML, XML, and JSON. PNG ファイルなど、ネイティブに圧縮されたアセットを圧縮することはできません。You shouldn't compress natively compressed assets, such as PNG files. ネイティブ圧縮応答をさらに圧縮しようとすると、サイズが小さく、転送時間が短縮されると、圧縮の処理に要する時間が大きくなります。If you attempt to further compress a natively compressed response, any small additional reduction in size and transmission time will likely be overshadowed by the time it took to process the compression. ファイルの内容や圧縮の効率によっては、約150-1000 バイトを下回るファイルを圧縮しないようにしてください。Don't compress files smaller than about 150-1000 bytes (depending on the file's content and the efficiency of compression). 小さいファイルを圧縮すると、圧縮されていないファイルよりも大きな圧縮ファイルが生成される可能性があります。The overhead of compressing small files may produce a compressed file larger than the uncompressed file.

クライアントは、圧縮されたコンテンツを処理できる場合、 Accept-Encoding 要求と共にヘッダーを送信することによって、その機能をサーバーに通知する必要があります。When a client can process compressed content, the client must inform the server of its capabilities by sending the Accept-Encoding header with the request. サーバーは、圧縮されたコンテンツを送信するときに、 Content-Encoding 圧縮された応答のエンコード方法に関する情報をヘッダーに含める必要があります。When a server sends compressed content, it must include information in the Content-Encoding header on how the compressed response is encoded. 次の表に、ミドルウェアでサポートされているコンテンツエンコードの表記を示します。Content encoding designations supported by the middleware are shown in the following table.

Accept-Encoding ヘッダー値Accept-Encoding header values サポートされているミドルウェアMiddleware Supported [説明]Description
br あり (既定)Yes (default) Brotli 圧縮データ形式Brotli compressed data format
deflate いいえNo 圧縮データ形式の DEFLATEDEFLATE compressed data format
exi いいえNo W3C の効率的な XML インターチェンジW3C Efficient XML Interchange
gzip はいYes Gzip ファイル形式Gzip file format
identity はいYes "エンコードなし" 識別子: 応答をエンコードすることはできません。"No encoding" identifier: The response must not be encoded.
pack200-gzip いいえNo Java アーカイブのネットワーク転送形式Network Transfer Format for Java Archives
* はいYes 明示的に要求されていない利用可能なコンテンツエンコーディングAny available content encoding not explicitly requested

詳細については、「 IANA 公式コンテンツコーディングリスト」を参照してください。For more information, see the IANA Official Content Coding List.

ミドルウェアを使用すると、カスタムヘッダー値の圧縮プロバイダーを追加でき Accept-Encoding ます。The middleware allows you to add additional compression providers for custom Accept-Encoding header values. 詳細については、以下の「 カスタムプロバイダー 」を参照してください。For more information, see Custom Providers below.

ミドルウェアは、 q 圧縮スキームの優先順位を決定するためにクライアントから送信されるときに、品質の値 (qvalue,) の重み付けに対応できます。The middleware is capable of reacting to quality value (qvalue, q) weighting when sent by the client to prioritize compression schemes. 詳細については、「 RFC 7231: Accept-Encoding」を参照してください。For more information, see RFC 7231: Accept-Encoding.

圧縮アルゴリズムは、圧縮速度と圧縮の効果のトレードオフの影響を受けます。Compression algorithms are subject to a tradeoff between compression speed and the effectiveness of the compression. このコンテキストの 効果 は、圧縮後の出力のサイズを示します。Effectiveness in this context refers to the size of the output after compression. 最小サイズは 最適 な圧縮によって実現されます。The smallest size is achieved by the most optimal compression.

次の表では、圧縮されたコンテンツの要求、送信、キャッシュ、および受信に関連するヘッダーについて説明します。The headers involved in requesting, sending, caching, and receiving compressed content are described in the table below.

ヘッダーHeader RoleRole
Accept-Encoding クライアントからサーバーに送信され、クライアントが使用できるコンテンツエンコーディングスキームを示します。Sent from the client to the server to indicate the content encoding schemes acceptable to the client.
Content-Encoding ペイロード内のコンテンツのエンコードを示すために、サーバーからクライアントに送信されます。Sent from the server to the client to indicate the encoding of the content in the payload.
Content-Length 圧縮が発生すると、 Content-Length 応答が圧縮されるときに本文の内容が変更されるため、ヘッダーは削除されます。When compression occurs, the Content-Length header is removed, since the body content changes when the response is compressed.
Content-MD5 圧縮が行われると、 Content-MD5 本文の内容が変更され、ハッシュが有効でなくなったため、ヘッダーは削除されます。When compression occurs, the Content-MD5 header is removed, since the body content has changed and the hash is no longer valid.
Content-Type コンテンツの MIME の種類を指定します。Specifies the MIME type of the content. すべての応答で、を指定する必要があり Content-Type ます。Every response should specify its Content-Type. ミドルウェアは、この値をチェックして、応答を圧縮する必要があるかどうかを判断します。The middleware checks this value to determine if the response should be compressed. ミドルウェアはエンコードできる既定の mime の種類 のセットを指定しますが、mime の種類を置き換えたり追加したりすることができます。The middleware specifies a set of default MIME types that it can encode, but you can replace or add MIME types.
Vary の値がであるサーバーからクライアントとプロキシに送信された場合 Accept-Encoding 、ヘッダーは、 Vary 要求のヘッダーの値に基づいて応答をキャッシュ (変更) する必要があることをクライアントまたはプロキシに示し Accept-Encoding ます。When sent by the server with a value of Accept-Encoding to clients and proxies, the Vary header indicates to the client or proxy that it should cache (vary) responses based on the value of the Accept-Encoding header of the request. ヘッダーを使用してコンテンツを返すと、 Vary: Accept-Encoding 圧縮された応答と圧縮されていない応答の両方が個別にキャッシュされることになります。The result of returning content with the Vary: Accept-Encoding header is that both compressed and uncompressed responses are cached separately.

サンプルアプリを使用して、応答圧縮ミドルウェアの機能を検証します。Explore the features of the Response Compression Middleware with the sample app. このサンプルでは、次のことを示します。The sample illustrates:

  • Gzip およびカスタム圧縮プロバイダーを使用したアプリ応答の圧縮。The compression of app responses using Gzip and custom compression providers.
  • 圧縮する mime の種類の既定の一覧に MIME の種類を追加する方法について説明します。How to add a MIME type to the default list of MIME types for compression.

パッケージPackage

応答圧縮ミドルウェアは、AspNetCore アプリ ASP.NET Core に暗黙的に含まれる ResponseCompression パッケージによって提供されます。Response Compression Middleware is provided by the Microsoft.AspNetCore.ResponseCompression package, which is implicitly included in ASP.NET Core apps.

構成Configuration

次のコードは、既定の MIME の種類と圧縮プロバイダー (BrotliGzip) に対して応答圧縮ミドルウェアを有効にする方法を示しています。The following code shows how to enable the Response Compression Middleware for default MIME types and compression providers (Brotli and Gzip):

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

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

メモ:Notes:

  • app.UseResponseCompression 応答を圧縮するミドルウェアの前にを呼び出す必要があります。app.UseResponseCompression must be called before any middleware that compresses responses. 詳細については、「ASP.NET Core のミドルウェア」を参照してください。For more information, see ASP.NET Core のミドルウェア.
  • Fiddler消火バグPostmanなどのツールを使用して要求ヘッダーを設定 Accept-Encoding し、応答ヘッダー、サイズ、および本文を調査します。Use a tool such as Fiddler, Firebug, or Postman to set the Accept-Encoding request header and study the response headers, size, and body.

ヘッダーを使用せずにサンプルアプリに要求を送信 Accept-Encoding し、応答が圧縮されていないことを確認します。Submit a request to the sample app without the Accept-Encoding header and observe that the response is uncompressed. Content-Encoding Vary 応答にヘッダーとヘッダーが存在しません。The Content-Encoding and Vary headers aren't present on the response.

Accept-Encoding ヘッダーのない要求の結果を示す Fiddler ウィンドウ。

ヘッダー (Brotli compression) を使用してサンプルアプリに要求を送信 Accept-Encoding: br し、応答が圧縮されていることを確認します。Submit a request to the sample app with the Accept-Encoding: br header (Brotli compression) and observe that the response is compressed. Content-Encoding Vary 応答には、ヘッダーとヘッダーが存在します。The Content-Encoding and Vary headers are present on the response.

Accept-Encoding ヘッダーと br の値を含む要求の結果を示す Fiddler ウィンドウ。

プロバイダーProviders

Brotli 圧縮プロバイダーBrotli Compression Provider

BrotliCompressionProvider Brotli 圧縮データ形式で応答を圧縮するには、を使用します。Use the BrotliCompressionProvider to compress responses with the Brotli compressed data format.

圧縮プロバイダーがに明示的に追加されていない場合は、次のように CompressionProviderCollection なります。If no compression providers are explicitly added to the CompressionProviderCollection:

  • 既定では、Brotli 圧縮プロバイダーは、 Gzip 圧縮プロバイダーと共に、圧縮プロバイダーの配列に追加されます。The Brotli Compression Provider is added by default to the array of compression providers along with the Gzip compression provider.
  • Brotli 圧縮データ形式がクライアントでサポートされている場合、圧縮は既定で Brotli 圧縮になります。Compression defaults to Brotli compression when the Brotli compressed data format is supported by the client. Brotli がクライアントでサポートされていない場合、クライアントで Gzip 圧縮がサポートされていると、圧縮の既定値は Gzip になります。If Brotli isn't supported by the client, compression defaults to Gzip when the client supports Gzip compression.
public void ConfigureServices(IServiceCollection services)
{
    services.AddResponseCompression();
}

圧縮プロバイダーが明示的に追加されている場合は、Brotli 圧縮プロバイダーを追加する必要があります。The Brotli Compression Provider must be added when any compression providers are explicitly added:

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

圧縮レベルをに設定 BrotliCompressionProviderOptions します。Set the compression level with BrotliCompressionProviderOptions. Brotli 圧縮プロバイダーは、既定で最も高速な圧縮レベル (CompressionLevel) に設定されています。これにより、圧縮率が最も高くなる可能性があります。The Brotli Compression Provider defaults to the fastest compression level (CompressionLevel.Fastest), which might not produce the most efficient compression. 最も効率的な圧縮が必要な場合は、最適な圧縮のためにミドルウェアを構成します。If the most efficient compression is desired, configure the middleware for optimal compression.

Compression LevelCompression Level [説明]Description
CompressionLevelCompressionLevel.Fastest 圧縮は、結果の出力が最適に圧縮されない場合でも、できるだけ早く完了する必要があります。Compression should complete as quickly as possible, even if the resulting output isn't optimally compressed.
CompressionLevelCompressionLevel.NoCompression 圧縮は実行されません。No compression should be performed.
CompressionLevelCompressionLevel.Optimal 圧縮が完了するまでに時間がかかる場合でも、応答は最適に圧縮される必要があります。Responses should be optimally compressed, even if the compression takes more time to complete.
public void ConfigureServices(IServiceCollection services)
{
    services.AddResponseCompression();

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

Gzip 圧縮プロバイダーGzip Compression Provider

を使用して、 GzipCompressionProvider Gzip ファイル形式で応答を圧縮します。Use the GzipCompressionProvider to compress responses with the Gzip file format.

圧縮プロバイダーがに明示的に追加されていない場合は、次のように CompressionProviderCollection なります。If no compression providers are explicitly added to the CompressionProviderCollection:

  • Gzip 圧縮プロバイダーは、既定では、 Brotli 圧縮プロバイダーと共に、圧縮プロバイダーの配列に追加されます。The Gzip Compression Provider is added by default to the array of compression providers along with the Brotli Compression Provider.
  • Brotli 圧縮データ形式がクライアントでサポートされている場合、圧縮は既定で Brotli 圧縮になります。Compression defaults to Brotli compression when the Brotli compressed data format is supported by the client. Brotli がクライアントでサポートされていない場合、クライアントで Gzip 圧縮がサポートされていると、圧縮の既定値は Gzip になります。If Brotli isn't supported by the client, compression defaults to Gzip when the client supports Gzip compression.
public void ConfigureServices(IServiceCollection services)
{
    services.AddResponseCompression();
}

圧縮プロバイダーが明示的に追加されている場合は、Gzip 圧縮プロバイダーを追加する必要があります。The Gzip Compression Provider must be added when any compression providers are explicitly added:

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

圧縮レベルをに設定 GzipCompressionProviderOptions します。Set the compression level with GzipCompressionProviderOptions. Gzip 圧縮プロバイダーは、既定で最も高速な圧縮レベル (CompressionLevel) に設定されています。これにより、圧縮率が最も高くなる可能性があります。The Gzip Compression Provider defaults to the fastest compression level (CompressionLevel.Fastest), which might not produce the most efficient compression. 最も効率的な圧縮が必要な場合は、最適な圧縮のためにミドルウェアを構成します。If the most efficient compression is desired, configure the middleware for optimal compression.

Compression LevelCompression Level [説明]Description
CompressionLevelCompressionLevel.Fastest 圧縮は、結果の出力が最適に圧縮されない場合でも、できるだけ早く完了する必要があります。Compression should complete as quickly as possible, even if the resulting output isn't optimally compressed.
CompressionLevelCompressionLevel.NoCompression 圧縮は実行されません。No compression should be performed.
CompressionLevelCompressionLevel.Optimal 圧縮が完了するまでに時間がかかる場合でも、応答は最適に圧縮される必要があります。Responses should be optimally compressed, even if the compression takes more time to complete.
public void ConfigureServices(IServiceCollection services)
{
    services.AddResponseCompression();

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

カスタム プロバイダーCustom providers

を使用して、カスタム圧縮実装を作成 ICompressionProvider します。Create custom compression implementations with ICompressionProvider. は、 EncodingName このによって生成されるコンテンツエンコーディングを表し ICompressionProvider ます。The EncodingName represents the content encoding that this ICompressionProvider produces. ミドルウェアは、この情報を使用して、要求のヘッダーに指定されている一覧に基づいてプロバイダーを選択し Accept-Encoding ます。The middleware uses this information to choose the provider based on the list specified in the Accept-Encoding header of the request.

サンプルアプリを使用して、クライアントはヘッダーを使用して要求を送信し Accept-Encoding: mycustomcompression ます。Using the sample app, the client submits a request with the Accept-Encoding: mycustomcompression header. ミドルウェアはカスタム圧縮実装を使用して、応答をヘッダーと共に返し Content-Encoding: mycustomcompression ます。The middleware uses the custom compression implementation and returns the response with a Content-Encoding: mycustomcompression header. カスタム圧縮実装を機能させるには、クライアントがカスタムエンコードを圧縮解除できる必要があります。The client must be able to decompress the custom encoding in order for a custom compression implementation to work.

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

ヘッダーを使用してサンプルアプリに要求を送信し、応答ヘッダーを確認し Accept-Encoding: mycustomcompression ます。Submit a request to the sample app with the Accept-Encoding: mycustomcompression header and observe the response headers. Vary Content-Encoding 応答には、ヘッダーとヘッダーが存在します。The Vary and Content-Encoding headers are present on the response. このサンプルでは、応答本文 (表示されません) は圧縮されません。The response body (not shown) isn't compressed by the sample. サンプルのクラスには圧縮実装がありません CustomCompressionProviderThere isn't a compression implementation in the CustomCompressionProvider class of the sample. ただし、このサンプルでは、このような圧縮アルゴリズムを実装する場所を示しています。However, the sample shows where you would implement such a compression algorithm.

Accept-Encoding ヘッダーと mycustomcompression の値を含む要求の結果を示す Fiddler ウィンドウ。

MIME タイプMIME types

ミドルウェアは、圧縮のために既定の MIME の種類のセットを指定します。The middleware specifies a default set of MIME types for compression:

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

応答の圧縮ミドルウェアオプションを使用して、MIME の種類を置換または追加します。Replace or append MIME types with the Response Compression Middleware options. などのワイルドカードの MIME 型はサポートされていないことに注意して text/* ください。Note that wildcard MIME types, such as text/* aren't supported. このサンプルアプリでは、の MIME の種類を追加 image/svg+xml し、ASP.NET Core バナーイメージ ( 横断幕 ) を圧縮して提供します。The sample app adds a MIME type for image/svg+xml and compresses and serves the ASP.NET Core banner image ( 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" });
    });
}

セキュリティで保護されたプロトコルを使用した圧縮Compression with secure protocol

セキュリティで保護された接続での圧縮された応答は、 EnableForHttps 既定では無効になっているオプションを使用して制御できます。Compressed responses over secure connections can be controlled with the EnableForHttps option, which is disabled by default. 動的に生成されたページで圧縮を使用すると、 犯罪侵害 攻撃などのセキュリティ上の問題が発生する可能性があります。Using compression with dynamically generated pages can lead to security problems such as the CRIME and BREACH attacks.

Vary ヘッダーを追加するAdding the Vary header

ヘッダーに基づいて応答を圧縮する場合 Accept-Encoding 、応答の複数の圧縮バージョンと圧縮されていないバージョンが存在する可能性があります。When compressing responses based on the Accept-Encoding header, there are potentially multiple compressed versions of the response and an uncompressed version. 複数のバージョンが存在し、格納する必要があることをクライアントキャッシュとプロキシキャッシュに指示するために、 Vary ヘッダーに値を追加し Accept-Encoding ます。In order to instruct client and proxy caches that multiple versions exist and should be stored, the Vary header is added with an Accept-Encoding value. ASP.NET Core 2.0 以降では、 Vary 応答が圧縮されるときに、ミドルウェアによってヘッダーが自動的に追加されます。In ASP.NET Core 2.0 or later, the middleware adds the Vary header automatically when the response is compressed.

Nginx リバースプロキシの背後にあるミドルウェアの問題Middleware issue when behind an Nginx reverse proxy

要求が Nginx によってプロキシされている場合、 Accept-Encoding ヘッダーは削除されます。When a request is proxied by Nginx, the Accept-Encoding header is removed. ヘッダーを削除すると、 Accept-Encoding ミドルウェアが応答を圧縮できなくなります。Removal of the Accept-Encoding header prevents the middleware from compressing the response. 詳細については、「 NGINX: Compression And 伸張」を参照してください。For more information, see NGINX: Compression and Decompression. この問題は、 Nginx (aspnet/BasicMiddleware #123) のパススルー圧縮によって追跡されます。This issue is tracked by Figure out pass-through compression for Nginx (aspnet/BasicMiddleware #123).

IIS 動的圧縮の使用Working with IIS dynamic compression

アプリケーションに対して無効にする、アクティブな IIS 動的圧縮モジュールがサーバーレベルで構成されている場合は、 web.config ファイルを追加してモジュールを無効にします。If you have an active IIS Dynamic Compression Module configured at the server level that you would like to disable for an app, disable the module with an addition to the web.config file. 詳細については、「Disabling IIS modules」 (IIS モジュールの無効化) を参照してください。For more information, see Disabling IIS modules.

トラブルシューティングTroubleshooting

Fiddler消火バグPostmanなどのツールを使用します。これにより、 Accept-Encoding 要求ヘッダーを設定し、応答ヘッダー、サイズ、本文を調べることができます。Use a tool like Fiddler, Firebug, or Postman, which allow you to set the Accept-Encoding request header and study the response headers, size, and body. 既定では、応答圧縮ミドルウェアは、次の条件を満たす応答を圧縮します。By default, Response Compression Middleware compresses responses that meet the following conditions:

  • Accept-Encodingヘッダーには br 、設定した gzip * カスタム圧縮プロバイダーに一致する値、、、またはカスタムエンコーディングが含まれています。The Accept-Encoding header is present with a value of br, gzip, *, or custom encoding that matches a custom compression provider that you've established. 値は、 identity または品質値 (qvalue, q ) の 0 (ゼロ) に設定することはできません。The value must not be identity or have a quality value (qvalue, q) setting of 0 (zero).
  • MIME の種類 ( Content-Type ) を設定し、で構成されている mime の種類と一致させる必要があり ResponseCompressionOptions ます。The MIME type (Content-Type) must be set and must match a MIME type configured on the ResponseCompressionOptions.
  • 要求にヘッダーを含めることはできません Content-RangeThe request must not include the Content-Range header.
  • 応答圧縮ミドルウェアのオプションで secure protocol (https) が構成されている場合を除き、要求では安全でないプロトコル (http) を使用する必要があります。The request must use insecure protocol (http), unless secure protocol (https) is configured in the Response Compression Middleware options. セキュリティで保護されたコンテンツの圧縮を有効にする場合は、 前述 の危険に注意してください。Note the danger described above when enabling secure content compression.

その他の資料Additional resources

ネットワーク帯域幅はリソースが限られています。Network bandwidth is a limited resource. 通常、応答のサイズを小さくすると、アプリの応答性が大幅に向上します。Reducing the size of the response usually increases the responsiveness of an app, often dramatically. ペイロードサイズを減らす方法の1つは、アプリの応答を圧縮することです。One way to reduce payload sizes is to compress an app's responses.

サンプル コードを表示またはダウンロードします (ダウンロード方法)。View or download sample code (how to download)

応答圧縮ミドルウェアを使用する場合When to use Response Compression Middleware

IIS、Apache、または Nginx のサーバーベースの応答圧縮テクノロジを使用します。Use server-based response compression technologies in IIS, Apache, or Nginx. ミドルウェアのパフォーマンスがサーバーモジュールのパフォーマンスと一致しない場合があります。The performance of the middleware probably won't match that of the server modules. HTTP.sys server Server と kestrel server では、現在、組み込みの圧縮サポートは提供されていません。HTTP.sys server server and Kestrel server don't currently offer built-in compression support.

次の場合に応答圧縮ミドルウェアを使用します。Use Response Compression Middleware when you're:

応答圧縮Response compression

通常、ネイティブに圧縮されていない応答は、応答圧縮の恩恵を受けることができます。Usually, any response not natively compressed can benefit from response compression. ネイティブに圧縮されていない応答には、通常、CSS、JavaScript、HTML、XML、JSON が含まれます。Responses not natively compressed typically include: CSS, JavaScript, HTML, XML, and JSON. PNG ファイルなど、ネイティブに圧縮されたアセットを圧縮することはできません。You shouldn't compress natively compressed assets, such as PNG files. ネイティブ圧縮応答をさらに圧縮しようとすると、サイズが小さく、転送時間が短縮されると、圧縮の処理に要する時間が大きくなります。If you attempt to further compress a natively compressed response, any small additional reduction in size and transmission time will likely be overshadowed by the time it took to process the compression. ファイルの内容や圧縮の効率によっては、約150-1000 バイトを下回るファイルを圧縮しないようにしてください。Don't compress files smaller than about 150-1000 bytes (depending on the file's content and the efficiency of compression). 小さいファイルを圧縮すると、圧縮されていないファイルよりも大きな圧縮ファイルが生成される可能性があります。The overhead of compressing small files may produce a compressed file larger than the uncompressed file.

クライアントは、圧縮されたコンテンツを処理できる場合、 Accept-Encoding 要求と共にヘッダーを送信することによって、その機能をサーバーに通知する必要があります。When a client can process compressed content, the client must inform the server of its capabilities by sending the Accept-Encoding header with the request. サーバーは、圧縮されたコンテンツを送信するときに、 Content-Encoding 圧縮された応答のエンコード方法に関する情報をヘッダーに含める必要があります。When a server sends compressed content, it must include information in the Content-Encoding header on how the compressed response is encoded. 次の表に、ミドルウェアでサポートされているコンテンツエンコードの表記を示します。Content encoding designations supported by the middleware are shown in the following table.

Accept-Encoding ヘッダー値Accept-Encoding header values サポートされているミドルウェアMiddleware Supported [説明]Description
br あり (既定)Yes (default) Brotli 圧縮データ形式Brotli compressed data format
deflate いいえNo 圧縮データ形式の DEFLATEDEFLATE compressed data format
exi いいえNo W3C の効率的な XML インターチェンジW3C Efficient XML Interchange
gzip はいYes Gzip ファイル形式Gzip file format
identity はいYes "エンコードなし" 識別子: 応答をエンコードすることはできません。"No encoding" identifier: The response must not be encoded.
pack200-gzip いいえNo Java アーカイブのネットワーク転送形式Network Transfer Format for Java Archives
* はいYes 明示的に要求されていない利用可能なコンテンツエンコーディングAny available content encoding not explicitly requested

詳細については、「 IANA 公式コンテンツコーディングリスト」を参照してください。For more information, see the IANA Official Content Coding List.

ミドルウェアを使用すると、カスタムヘッダー値の圧縮プロバイダーを追加でき Accept-Encoding ます。The middleware allows you to add additional compression providers for custom Accept-Encoding header values. 詳細については、以下の「 カスタムプロバイダー 」を参照してください。For more information, see Custom Providers below.

ミドルウェアは、 q 圧縮スキームの優先順位を決定するためにクライアントから送信されるときに、品質の値 (qvalue,) の重み付けに対応できます。The middleware is capable of reacting to quality value (qvalue, q) weighting when sent by the client to prioritize compression schemes. 詳細については、「 RFC 7231: Accept-Encoding」を参照してください。For more information, see RFC 7231: Accept-Encoding.

圧縮アルゴリズムは、圧縮速度と圧縮の効果のトレードオフの影響を受けます。Compression algorithms are subject to a tradeoff between compression speed and the effectiveness of the compression. このコンテキストの 効果 は、圧縮後の出力のサイズを示します。Effectiveness in this context refers to the size of the output after compression. 最小サイズは 最適 な圧縮によって実現されます。The smallest size is achieved by the most optimal compression.

次の表では、圧縮されたコンテンツの要求、送信、キャッシュ、および受信に関連するヘッダーについて説明します。The headers involved in requesting, sending, caching, and receiving compressed content are described in the table below.

ヘッダーHeader RoleRole
Accept-Encoding クライアントからサーバーに送信され、クライアントが使用できるコンテンツエンコーディングスキームを示します。Sent from the client to the server to indicate the content encoding schemes acceptable to the client.
Content-Encoding ペイロード内のコンテンツのエンコードを示すために、サーバーからクライアントに送信されます。Sent from the server to the client to indicate the encoding of the content in the payload.
Content-Length 圧縮が発生すると、 Content-Length 応答が圧縮されるときに本文の内容が変更されるため、ヘッダーは削除されます。When compression occurs, the Content-Length header is removed, since the body content changes when the response is compressed.
Content-MD5 圧縮が行われると、 Content-MD5 本文の内容が変更され、ハッシュが有効でなくなったため、ヘッダーは削除されます。When compression occurs, the Content-MD5 header is removed, since the body content has changed and the hash is no longer valid.
Content-Type コンテンツの MIME の種類を指定します。Specifies the MIME type of the content. すべての応答で、を指定する必要があり Content-Type ます。Every response should specify its Content-Type. ミドルウェアは、この値をチェックして、応答を圧縮する必要があるかどうかを判断します。The middleware checks this value to determine if the response should be compressed. ミドルウェアはエンコードできる既定の mime の種類 のセットを指定しますが、mime の種類を置き換えたり追加したりすることができます。The middleware specifies a set of default MIME types that it can encode, but you can replace or add MIME types.
Vary の値がであるサーバーからクライアントとプロキシに送信された場合 Accept-Encoding 、ヘッダーは、 Vary 要求のヘッダーの値に基づいて応答をキャッシュ (変更) する必要があることをクライアントまたはプロキシに示し Accept-Encoding ます。When sent by the server with a value of Accept-Encoding to clients and proxies, the Vary header indicates to the client or proxy that it should cache (vary) responses based on the value of the Accept-Encoding header of the request. ヘッダーを使用してコンテンツを返すと、 Vary: Accept-Encoding 圧縮された応答と圧縮されていない応答の両方が個別にキャッシュされることになります。The result of returning content with the Vary: Accept-Encoding header is that both compressed and uncompressed responses are cached separately.

サンプルアプリを使用して、応答圧縮ミドルウェアの機能を検証します。Explore the features of the Response Compression Middleware with the sample app. このサンプルでは、次のことを示します。The sample illustrates:

  • Gzip およびカスタム圧縮プロバイダーを使用したアプリ応答の圧縮。The compression of app responses using Gzip and custom compression providers.
  • 圧縮する mime の種類の既定の一覧に MIME の種類を追加する方法について説明します。How to add a MIME type to the default list of MIME types for compression.

パッケージPackage

ミドルウェアをプロジェクトに含めるには、 AspNetCore メタパッケージへの参照を追加します。これには、 AspNetCore パッケージが含まれています。To include the middleware in a project, add a reference to the Microsoft.AspNetCore.App metapackage, which includes the Microsoft.AspNetCore.ResponseCompression package.

構成Configuration

次のコードは、既定の MIME の種類と圧縮プロバイダー (BrotliGzip) に対して応答圧縮ミドルウェアを有効にする方法を示しています。The following code shows how to enable the Response Compression Middleware for default MIME types and compression providers (Brotli and Gzip):

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

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

メモ:Notes:

  • app.UseResponseCompression 応答を圧縮するミドルウェアの前にを呼び出す必要があります。app.UseResponseCompression must be called before any middleware that compresses responses. 詳細については、「ASP.NET Core のミドルウェア」を参照してください。For more information, see ASP.NET Core のミドルウェア.
  • Fiddler消火バグPostmanなどのツールを使用して要求ヘッダーを設定 Accept-Encoding し、応答ヘッダー、サイズ、および本文を調査します。Use a tool such as Fiddler, Firebug, or Postman to set the Accept-Encoding request header and study the response headers, size, and body.

ヘッダーを使用せずにサンプルアプリに要求を送信 Accept-Encoding し、応答が圧縮されていないことを確認します。Submit a request to the sample app without the Accept-Encoding header and observe that the response is uncompressed. Content-Encoding Vary 応答にヘッダーとヘッダーが存在しません。The Content-Encoding and Vary headers aren't present on the response.

Accept-Encoding ヘッダーのない要求の結果を示す Fiddler ウィンドウ。

ヘッダー (Brotli compression) を使用してサンプルアプリに要求を送信 Accept-Encoding: br し、応答が圧縮されていることを確認します。Submit a request to the sample app with the Accept-Encoding: br header (Brotli compression) and observe that the response is compressed. Content-Encoding Vary 応答には、ヘッダーとヘッダーが存在します。The Content-Encoding and Vary headers are present on the response.

Accept-Encoding ヘッダーと br の値を含む要求の結果を示す Fiddler ウィンドウ。

プロバイダーProviders

Brotli 圧縮プロバイダーBrotli Compression Provider

BrotliCompressionProvider Brotli 圧縮データ形式で応答を圧縮するには、を使用します。Use the BrotliCompressionProvider to compress responses with the Brotli compressed data format.

圧縮プロバイダーがに明示的に追加されていない場合は、次のように CompressionProviderCollection なります。If no compression providers are explicitly added to the CompressionProviderCollection:

  • 既定では、Brotli 圧縮プロバイダーは、 Gzip 圧縮プロバイダーと共に、圧縮プロバイダーの配列に追加されます。The Brotli Compression Provider is added by default to the array of compression providers along with the Gzip compression provider.
  • Brotli 圧縮データ形式がクライアントでサポートされている場合、圧縮は既定で Brotli 圧縮になります。Compression defaults to Brotli compression when the Brotli compressed data format is supported by the client. Brotli がクライアントでサポートされていない場合、クライアントで Gzip 圧縮がサポートされていると、圧縮の既定値は Gzip になります。If Brotli isn't supported by the client, compression defaults to Gzip when the client supports Gzip compression.
public void ConfigureServices(IServiceCollection services)
{
    services.AddResponseCompression();
}

圧縮プロバイダーが明示的に追加されている場合は、Brotli 圧縮プロバイダーを追加する必要があります。The Brotli Compression Provider must be added when any compression providers are explicitly added:

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

圧縮レベルをに設定 BrotliCompressionProviderOptions します。Set the compression level with BrotliCompressionProviderOptions. Brotli 圧縮プロバイダーは、既定で最も高速な圧縮レベル (CompressionLevel) に設定されています。これにより、圧縮率が最も高くなる可能性があります。The Brotli Compression Provider defaults to the fastest compression level (CompressionLevel.Fastest), which might not produce the most efficient compression. 最も効率的な圧縮が必要な場合は、最適な圧縮のためにミドルウェアを構成します。If the most efficient compression is desired, configure the middleware for optimal compression.

Compression LevelCompression Level [説明]Description
CompressionLevelCompressionLevel.Fastest 圧縮は、結果の出力が最適に圧縮されない場合でも、できるだけ早く完了する必要があります。Compression should complete as quickly as possible, even if the resulting output isn't optimally compressed.
CompressionLevelCompressionLevel.NoCompression 圧縮は実行されません。No compression should be performed.
CompressionLevelCompressionLevel.Optimal 圧縮が完了するまでに時間がかかる場合でも、応答は最適に圧縮される必要があります。Responses should be optimally compressed, even if the compression takes more time to complete.
public void ConfigureServices(IServiceCollection services)
{
    services.AddResponseCompression();

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

Gzip 圧縮プロバイダーGzip Compression Provider

を使用して、 GzipCompressionProvider Gzip ファイル形式で応答を圧縮します。Use the GzipCompressionProvider to compress responses with the Gzip file format.

圧縮プロバイダーがに明示的に追加されていない場合は、次のように CompressionProviderCollection なります。If no compression providers are explicitly added to the CompressionProviderCollection:

  • Gzip 圧縮プロバイダーは、既定では、 Brotli 圧縮プロバイダーと共に、圧縮プロバイダーの配列に追加されます。The Gzip Compression Provider is added by default to the array of compression providers along with the Brotli Compression Provider.
  • Brotli 圧縮データ形式がクライアントでサポートされている場合、圧縮は既定で Brotli 圧縮になります。Compression defaults to Brotli compression when the Brotli compressed data format is supported by the client. Brotli がクライアントでサポートされていない場合、クライアントで Gzip 圧縮がサポートされていると、圧縮の既定値は Gzip になります。If Brotli isn't supported by the client, compression defaults to Gzip when the client supports Gzip compression.
public void ConfigureServices(IServiceCollection services)
{
    services.AddResponseCompression();
}

圧縮プロバイダーが明示的に追加されている場合は、Gzip 圧縮プロバイダーを追加する必要があります。The Gzip Compression Provider must be added when any compression providers are explicitly added:

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

圧縮レベルをに設定 GzipCompressionProviderOptions します。Set the compression level with GzipCompressionProviderOptions. Gzip 圧縮プロバイダーは、既定で最も高速な圧縮レベル (CompressionLevel) に設定されています。これにより、圧縮率が最も高くなる可能性があります。The Gzip Compression Provider defaults to the fastest compression level (CompressionLevel.Fastest), which might not produce the most efficient compression. 最も効率的な圧縮が必要な場合は、最適な圧縮のためにミドルウェアを構成します。If the most efficient compression is desired, configure the middleware for optimal compression.

Compression LevelCompression Level [説明]Description
CompressionLevelCompressionLevel.Fastest 圧縮は、結果の出力が最適に圧縮されない場合でも、できるだけ早く完了する必要があります。Compression should complete as quickly as possible, even if the resulting output isn't optimally compressed.
CompressionLevelCompressionLevel.NoCompression 圧縮は実行されません。No compression should be performed.
CompressionLevelCompressionLevel.Optimal 圧縮が完了するまでに時間がかかる場合でも、応答は最適に圧縮される必要があります。Responses should be optimally compressed, even if the compression takes more time to complete.
public void ConfigureServices(IServiceCollection services)
{
    services.AddResponseCompression();

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

カスタム プロバイダーCustom providers

を使用して、カスタム圧縮実装を作成 ICompressionProvider します。Create custom compression implementations with ICompressionProvider. は、 EncodingName このによって生成されるコンテンツエンコーディングを表し ICompressionProvider ます。The EncodingName represents the content encoding that this ICompressionProvider produces. ミドルウェアは、この情報を使用して、要求のヘッダーに指定されている一覧に基づいてプロバイダーを選択し Accept-Encoding ます。The middleware uses this information to choose the provider based on the list specified in the Accept-Encoding header of the request.

サンプルアプリを使用して、クライアントはヘッダーを使用して要求を送信し Accept-Encoding: mycustomcompression ます。Using the sample app, the client submits a request with the Accept-Encoding: mycustomcompression header. ミドルウェアはカスタム圧縮実装を使用して、応答をヘッダーと共に返し Content-Encoding: mycustomcompression ます。The middleware uses the custom compression implementation and returns the response with a Content-Encoding: mycustomcompression header. カスタム圧縮実装を機能させるには、クライアントがカスタムエンコードを圧縮解除できる必要があります。The client must be able to decompress the custom encoding in order for a custom compression implementation to work.

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

ヘッダーを使用してサンプルアプリに要求を送信し、応答ヘッダーを確認し Accept-Encoding: mycustomcompression ます。Submit a request to the sample app with the Accept-Encoding: mycustomcompression header and observe the response headers. Vary Content-Encoding 応答には、ヘッダーとヘッダーが存在します。The Vary and Content-Encoding headers are present on the response. このサンプルでは、応答本文 (表示されません) は圧縮されません。The response body (not shown) isn't compressed by the sample. サンプルのクラスには圧縮実装がありません CustomCompressionProviderThere isn't a compression implementation in the CustomCompressionProvider class of the sample. ただし、このサンプルでは、このような圧縮アルゴリズムを実装する場所を示しています。However, the sample shows where you would implement such a compression algorithm.

Accept-Encoding ヘッダーと mycustomcompression の値を含む要求の結果を示す Fiddler ウィンドウ。

MIME タイプMIME types

ミドルウェアは、圧縮のために既定の MIME の種類のセットを指定します。The middleware specifies a default set of MIME types for compression:

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

応答の圧縮ミドルウェアオプションを使用して、MIME の種類を置換または追加します。Replace or append MIME types with the Response Compression Middleware options. などのワイルドカードの MIME 型はサポートされていないことに注意して text/* ください。Note that wildcard MIME types, such as text/* aren't supported. このサンプルアプリでは、の MIME の種類を追加 image/svg+xml し、ASP.NET Core バナーイメージ ( 横断幕 ) を圧縮して提供します。The sample app adds a MIME type for image/svg+xml and compresses and serves the ASP.NET Core banner image ( 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" });
    });
}

セキュリティで保護されたプロトコルを使用した圧縮Compression with secure protocol

セキュリティで保護された接続での圧縮された応答は、 EnableForHttps 既定では無効になっているオプションを使用して制御できます。Compressed responses over secure connections can be controlled with the EnableForHttps option, which is disabled by default. 動的に生成されたページで圧縮を使用すると、 犯罪侵害 攻撃などのセキュリティ上の問題が発生する可能性があります。Using compression with dynamically generated pages can lead to security problems such as the CRIME and BREACH attacks.

Vary ヘッダーを追加するAdding the Vary header

ヘッダーに基づいて応答を圧縮する場合 Accept-Encoding 、応答の複数の圧縮バージョンと圧縮されていないバージョンが存在する可能性があります。When compressing responses based on the Accept-Encoding header, there are potentially multiple compressed versions of the response and an uncompressed version. 複数のバージョンが存在し、格納する必要があることをクライアントキャッシュとプロキシキャッシュに指示するために、 Vary ヘッダーに値を追加し Accept-Encoding ます。In order to instruct client and proxy caches that multiple versions exist and should be stored, the Vary header is added with an Accept-Encoding value. ASP.NET Core 2.0 以降では、 Vary 応答が圧縮されるときに、ミドルウェアによってヘッダーが自動的に追加されます。In ASP.NET Core 2.0 or later, the middleware adds the Vary header automatically when the response is compressed.

Nginx リバースプロキシの背後にあるミドルウェアの問題Middleware issue when behind an Nginx reverse proxy

要求が Nginx によってプロキシされている場合、 Accept-Encoding ヘッダーは削除されます。When a request is proxied by Nginx, the Accept-Encoding header is removed. ヘッダーを削除すると、 Accept-Encoding ミドルウェアが応答を圧縮できなくなります。Removal of the Accept-Encoding header prevents the middleware from compressing the response. 詳細については、「 NGINX: Compression And 伸張」を参照してください。For more information, see NGINX: Compression and Decompression. この問題は、 Nginx (aspnet/BasicMiddleware #123) のパススルー圧縮によって追跡されます。This issue is tracked by Figure out pass-through compression for Nginx (aspnet/BasicMiddleware #123).

IIS 動的圧縮の使用Working with IIS dynamic compression

アプリケーションに対して無効にする、アクティブな IIS 動的圧縮モジュールがサーバーレベルで構成されている場合は、 web.config ファイルを追加してモジュールを無効にします。If you have an active IIS Dynamic Compression Module configured at the server level that you would like to disable for an app, disable the module with an addition to the web.config file. 詳細については、「Disabling IIS modules」 (IIS モジュールの無効化) を参照してください。For more information, see Disabling IIS modules.

トラブルシューティングTroubleshooting

Fiddler消火バグPostmanなどのツールを使用します。これにより、 Accept-Encoding 要求ヘッダーを設定し、応答ヘッダー、サイズ、本文を調べることができます。Use a tool like Fiddler, Firebug, or Postman, which allow you to set the Accept-Encoding request header and study the response headers, size, and body. 既定では、応答圧縮ミドルウェアは、次の条件を満たす応答を圧縮します。By default, Response Compression Middleware compresses responses that meet the following conditions:

  • Accept-Encodingヘッダーには br 、設定した gzip * カスタム圧縮プロバイダーに一致する値、、、またはカスタムエンコーディングが含まれています。The Accept-Encoding header is present with a value of br, gzip, *, or custom encoding that matches a custom compression provider that you've established. 値は、 identity または品質値 (qvalue, q ) の 0 (ゼロ) に設定することはできません。The value must not be identity or have a quality value (qvalue, q) setting of 0 (zero).
  • MIME の種類 ( Content-Type ) を設定し、で構成されている mime の種類と一致させる必要があり ResponseCompressionOptions ます。The MIME type (Content-Type) must be set and must match a MIME type configured on the ResponseCompressionOptions.
  • 要求にヘッダーを含めることはできません Content-RangeThe request must not include the Content-Range header.
  • 応答圧縮ミドルウェアのオプションで secure protocol (https) が構成されている場合を除き、要求では安全でないプロトコル (http) を使用する必要があります。The request must use insecure protocol (http), unless secure protocol (https) is configured in the Response Compression Middleware options. セキュリティで保護されたコンテンツの圧縮を有効にする場合は、 前述 の危険に注意してください。Note the danger described above when enabling secure content compression.

その他の資料Additional resources

ネットワーク帯域幅はリソースが限られています。Network bandwidth is a limited resource. 通常、応答のサイズを小さくすると、アプリの応答性が大幅に向上します。Reducing the size of the response usually increases the responsiveness of an app, often dramatically. ペイロードサイズを減らす方法の1つは、アプリの応答を圧縮することです。One way to reduce payload sizes is to compress an app's responses.

サンプル コードを表示またはダウンロードします (ダウンロード方法)。View or download sample code (how to download)

応答圧縮ミドルウェアを使用する場合When to use Response Compression Middleware

IIS、Apache、または Nginx のサーバーベースの応答圧縮テクノロジを使用します。Use server-based response compression technologies in IIS, Apache, or Nginx. ミドルウェアのパフォーマンスがサーバーモジュールのパフォーマンスと一致しない場合があります。The performance of the middleware probably won't match that of the server modules. HTTP.sys server Server と kestrel server では、現在、組み込みの圧縮サポートは提供されていません。HTTP.sys server server and Kestrel server don't currently offer built-in compression support.

次の場合に応答圧縮ミドルウェアを使用します。Use Response Compression Middleware when you're:

応答圧縮Response compression

通常、ネイティブに圧縮されていない応答は、応答圧縮の恩恵を受けることができます。Usually, any response not natively compressed can benefit from response compression. ネイティブに圧縮されていない応答には、通常、CSS、JavaScript、HTML、XML、JSON が含まれます。Responses not natively compressed typically include: CSS, JavaScript, HTML, XML, and JSON. PNG ファイルなど、ネイティブに圧縮されたアセットを圧縮することはできません。You shouldn't compress natively compressed assets, such as PNG files. ネイティブ圧縮応答をさらに圧縮しようとすると、サイズが小さく、転送時間が短縮されると、圧縮の処理に要する時間が大きくなります。If you attempt to further compress a natively compressed response, any small additional reduction in size and transmission time will likely be overshadowed by the time it took to process the compression. ファイルの内容や圧縮の効率によっては、約150-1000 バイトを下回るファイルを圧縮しないようにしてください。Don't compress files smaller than about 150-1000 bytes (depending on the file's content and the efficiency of compression). 小さいファイルを圧縮すると、圧縮されていないファイルよりも大きな圧縮ファイルが生成される可能性があります。The overhead of compressing small files may produce a compressed file larger than the uncompressed file.

クライアントは、圧縮されたコンテンツを処理できる場合、 Accept-Encoding 要求と共にヘッダーを送信することによって、その機能をサーバーに通知する必要があります。When a client can process compressed content, the client must inform the server of its capabilities by sending the Accept-Encoding header with the request. サーバーは、圧縮されたコンテンツを送信するときに、 Content-Encoding 圧縮された応答のエンコード方法に関する情報をヘッダーに含める必要があります。When a server sends compressed content, it must include information in the Content-Encoding header on how the compressed response is encoded. 次の表に、ミドルウェアでサポートされているコンテンツエンコードの表記を示します。Content encoding designations supported by the middleware are shown in the following table.

Accept-Encoding ヘッダー値Accept-Encoding header values サポートされているミドルウェアMiddleware Supported [説明]Description
br いいえNo Brotli 圧縮データ形式Brotli compressed data format
deflate いいえNo 圧縮データ形式の DEFLATEDEFLATE compressed data format
exi いいえNo W3C の効率的な XML インターチェンジW3C Efficient XML Interchange
gzip あり (既定)Yes (default) Gzip ファイル形式Gzip file format
identity はいYes "エンコードなし" 識別子: 応答をエンコードすることはできません。"No encoding" identifier: The response must not be encoded.
pack200-gzip いいえNo Java アーカイブのネットワーク転送形式Network Transfer Format for Java Archives
* はいYes 明示的に要求されていない利用可能なコンテンツエンコーディングAny available content encoding not explicitly requested

詳細については、「 IANA 公式コンテンツコーディングリスト」を参照してください。For more information, see the IANA Official Content Coding List.

ミドルウェアを使用すると、カスタムヘッダー値の圧縮プロバイダーを追加でき Accept-Encoding ます。The middleware allows you to add additional compression providers for custom Accept-Encoding header values. 詳細については、以下の「 カスタムプロバイダー 」を参照してください。For more information, see Custom Providers below.

ミドルウェアは、 q 圧縮スキームの優先順位を決定するためにクライアントから送信されるときに、品質の値 (qvalue,) の重み付けに対応できます。The middleware is capable of reacting to quality value (qvalue, q) weighting when sent by the client to prioritize compression schemes. 詳細については、「 RFC 7231: Accept-Encoding」を参照してください。For more information, see RFC 7231: Accept-Encoding.

圧縮アルゴリズムは、圧縮速度と圧縮の効果のトレードオフの影響を受けます。Compression algorithms are subject to a tradeoff between compression speed and the effectiveness of the compression. このコンテキストの 効果 は、圧縮後の出力のサイズを示します。Effectiveness in this context refers to the size of the output after compression. 最小サイズは 最適 な圧縮によって実現されます。The smallest size is achieved by the most optimal compression.

次の表では、圧縮されたコンテンツの要求、送信、キャッシュ、および受信に関連するヘッダーについて説明します。The headers involved in requesting, sending, caching, and receiving compressed content are described in the table below.

ヘッダーHeader RoleRole
Accept-Encoding クライアントからサーバーに送信され、クライアントが使用できるコンテンツエンコーディングスキームを示します。Sent from the client to the server to indicate the content encoding schemes acceptable to the client.
Content-Encoding ペイロード内のコンテンツのエンコードを示すために、サーバーからクライアントに送信されます。Sent from the server to the client to indicate the encoding of the content in the payload.
Content-Length 圧縮が発生すると、 Content-Length 応答が圧縮されるときに本文の内容が変更されるため、ヘッダーは削除されます。When compression occurs, the Content-Length header is removed, since the body content changes when the response is compressed.
Content-MD5 圧縮が行われると、 Content-MD5 本文の内容が変更され、ハッシュが有効でなくなったため、ヘッダーは削除されます。When compression occurs, the Content-MD5 header is removed, since the body content has changed and the hash is no longer valid.
Content-Type コンテンツの MIME の種類を指定します。Specifies the MIME type of the content. すべての応答で、を指定する必要があり Content-Type ます。Every response should specify its Content-Type. ミドルウェアは、この値をチェックして、応答を圧縮する必要があるかどうかを判断します。The middleware checks this value to determine if the response should be compressed. ミドルウェアはエンコードできる既定の mime の種類 のセットを指定しますが、mime の種類を置き換えたり追加したりすることができます。The middleware specifies a set of default MIME types that it can encode, but you can replace or add MIME types.
Vary の値がであるサーバーからクライアントとプロキシに送信された場合 Accept-Encoding 、ヘッダーは、 Vary 要求のヘッダーの値に基づいて応答をキャッシュ (変更) する必要があることをクライアントまたはプロキシに示し Accept-Encoding ます。When sent by the server with a value of Accept-Encoding to clients and proxies, the Vary header indicates to the client or proxy that it should cache (vary) responses based on the value of the Accept-Encoding header of the request. ヘッダーを使用してコンテンツを返すと、 Vary: Accept-Encoding 圧縮された応答と圧縮されていない応答の両方が個別にキャッシュされることになります。The result of returning content with the Vary: Accept-Encoding header is that both compressed and uncompressed responses are cached separately.

サンプルアプリを使用して、応答圧縮ミドルウェアの機能を検証します。Explore the features of the Response Compression Middleware with the sample app. このサンプルでは、次のことを示します。The sample illustrates:

  • Gzip およびカスタム圧縮プロバイダーを使用したアプリ応答の圧縮。The compression of app responses using Gzip and custom compression providers.
  • 圧縮する mime の種類の既定の一覧に MIME の種類を追加する方法について説明します。How to add a MIME type to the default list of MIME types for compression.

パッケージPackage

ミドルウェアをプロジェクトに含めるには、 AspNetCore メタパッケージへの参照を追加します。これには、 AspNetCore パッケージが含まれています。To include the middleware in a project, add a reference to the Microsoft.AspNetCore.App metapackage, which includes the Microsoft.AspNetCore.ResponseCompression package.

構成Configuration

次のコードは、既定の MIME の種類と Gzip 圧縮プロバイダーの応答圧縮ミドルウェアを有効にする方法を示しています。The following code shows how to enable the Response Compression Middleware for default MIME types and the Gzip Compression Provider:

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

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

メモ:Notes:

  • app.UseResponseCompression 応答を圧縮するミドルウェアの前にを呼び出す必要があります。app.UseResponseCompression must be called before any middleware that compresses responses. 詳細については、「ASP.NET Core のミドルウェア」を参照してください。For more information, see ASP.NET Core のミドルウェア.
  • Fiddler消火バグPostmanなどのツールを使用して要求ヘッダーを設定 Accept-Encoding し、応答ヘッダー、サイズ、および本文を調査します。Use a tool such as Fiddler, Firebug, or Postman to set the Accept-Encoding request header and study the response headers, size, and body.

ヘッダーを使用せずにサンプルアプリに要求を送信 Accept-Encoding し、応答が圧縮されていないことを確認します。Submit a request to the sample app without the Accept-Encoding header and observe that the response is uncompressed. Content-Encoding Vary 応答にヘッダーとヘッダーが存在しません。The Content-Encoding and Vary headers aren't present on the response.

Accept-Encoding ヘッダーのない要求の結果を示す Fiddler ウィンドウ。

ヘッダーを使用してサンプルアプリに要求を送信 Accept-Encoding: gzip し、応答が圧縮されていることを確認します。Submit a request to the sample app with the Accept-Encoding: gzip header and observe that the response is compressed. Content-Encoding Vary 応答には、ヘッダーとヘッダーが存在します。The Content-Encoding and Vary headers are present on the response.

Accept-Encoding ヘッダーと gzip の値を持つ要求の結果を示す Fiddler ウィンドウ。

プロバイダーProviders

Gzip 圧縮プロバイダーGzip Compression Provider

を使用して、 GzipCompressionProvider Gzip ファイル形式で応答を圧縮します。Use the GzipCompressionProvider to compress responses with the Gzip file format.

圧縮プロバイダーがに明示的に追加されていない場合は、次のように CompressionProviderCollection なります。If no compression providers are explicitly added to the CompressionProviderCollection:

  • Gzip 圧縮プロバイダーは、既定で圧縮プロバイダーの配列に追加されます。The Gzip Compression Provider is added by default to the array of compression providers.
  • クライアントで Gzip 圧縮がサポートされている場合、圧縮の既定値は Gzip です。Compression defaults to Gzip when the client supports Gzip compression.
public void ConfigureServices(IServiceCollection services)
{
    services.AddResponseCompression();
}

圧縮プロバイダーが明示的に追加されている場合は、Gzip 圧縮プロバイダーを追加する必要があります。The Gzip Compression Provider must be added when any compression providers are explicitly added:

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

圧縮レベルをに設定 GzipCompressionProviderOptions します。Set the compression level with GzipCompressionProviderOptions. Gzip 圧縮プロバイダーは、既定で最も高速な圧縮レベル (CompressionLevel) に設定されています。これにより、圧縮率が最も高くなる可能性があります。The Gzip Compression Provider defaults to the fastest compression level (CompressionLevel.Fastest), which might not produce the most efficient compression. 最も効率的な圧縮が必要な場合は、最適な圧縮のためにミドルウェアを構成します。If the most efficient compression is desired, configure the middleware for optimal compression.

Compression LevelCompression Level [説明]Description
CompressionLevelCompressionLevel.Fastest 圧縮は、結果の出力が最適に圧縮されない場合でも、できるだけ早く完了する必要があります。Compression should complete as quickly as possible, even if the resulting output isn't optimally compressed.
CompressionLevelCompressionLevel.NoCompression 圧縮は実行されません。No compression should be performed.
CompressionLevelCompressionLevel.Optimal 圧縮が完了するまでに時間がかかる場合でも、応答は最適に圧縮される必要があります。Responses should be optimally compressed, even if the compression takes more time to complete.
public void ConfigureServices(IServiceCollection services)
{
    services.AddResponseCompression();

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

カスタム プロバイダーCustom providers

を使用して、カスタム圧縮実装を作成 ICompressionProvider します。Create custom compression implementations with ICompressionProvider. は、 EncodingName このによって生成されるコンテンツエンコーディングを表し ICompressionProvider ます。The EncodingName represents the content encoding that this ICompressionProvider produces. ミドルウェアは、この情報を使用して、要求のヘッダーに指定されている一覧に基づいてプロバイダーを選択し Accept-Encoding ます。The middleware uses this information to choose the provider based on the list specified in the Accept-Encoding header of the request.

サンプルアプリを使用して、クライアントはヘッダーを使用して要求を送信し Accept-Encoding: mycustomcompression ます。Using the sample app, the client submits a request with the Accept-Encoding: mycustomcompression header. ミドルウェアはカスタム圧縮実装を使用して、応答をヘッダーと共に返し Content-Encoding: mycustomcompression ます。The middleware uses the custom compression implementation and returns the response with a Content-Encoding: mycustomcompression header. カスタム圧縮実装を機能させるには、クライアントがカスタムエンコードを圧縮解除できる必要があります。The client must be able to decompress the custom encoding in order for a custom compression implementation to work.

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

ヘッダーを使用してサンプルアプリに要求を送信し、応答ヘッダーを確認し Accept-Encoding: mycustomcompression ます。Submit a request to the sample app with the Accept-Encoding: mycustomcompression header and observe the response headers. Vary Content-Encoding 応答には、ヘッダーとヘッダーが存在します。The Vary and Content-Encoding headers are present on the response. このサンプルでは、応答本文 (表示されません) は圧縮されません。The response body (not shown) isn't compressed by the sample. サンプルのクラスには圧縮実装がありません CustomCompressionProviderThere isn't a compression implementation in the CustomCompressionProvider class of the sample. ただし、このサンプルでは、このような圧縮アルゴリズムを実装する場所を示しています。However, the sample shows where you would implement such a compression algorithm.

Accept-Encoding ヘッダーと mycustomcompression の値を含む要求の結果を示す Fiddler ウィンドウ。

MIME タイプMIME types

ミドルウェアは、圧縮のために既定の MIME の種類のセットを指定します。The middleware specifies a default set of MIME types for compression:

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

応答の圧縮ミドルウェアオプションを使用して、MIME の種類を置換または追加します。Replace or append MIME types with the Response Compression Middleware options. などのワイルドカードの MIME 型はサポートされていないことに注意して text/* ください。Note that wildcard MIME types, such as text/* aren't supported. このサンプルアプリでは、の MIME の種類を追加 image/svg+xml し、ASP.NET Core バナーイメージ ( 横断幕 ) を圧縮して提供します。The sample app adds a MIME type for image/svg+xml and compresses and serves the ASP.NET Core banner image ( 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" });
    });
}

セキュリティで保護されたプロトコルを使用した圧縮Compression with secure protocol

セキュリティで保護された接続での圧縮された応答は、 EnableForHttps 既定では無効になっているオプションを使用して制御できます。Compressed responses over secure connections can be controlled with the EnableForHttps option, which is disabled by default. 動的に生成されたページで圧縮を使用すると、 犯罪侵害 攻撃などのセキュリティ上の問題が発生する可能性があります。Using compression with dynamically generated pages can lead to security problems such as the CRIME and BREACH attacks.

Vary ヘッダーを追加するAdding the Vary header

ヘッダーに基づいて応答を圧縮する場合 Accept-Encoding 、応答の複数の圧縮バージョンと圧縮されていないバージョンが存在する可能性があります。When compressing responses based on the Accept-Encoding header, there are potentially multiple compressed versions of the response and an uncompressed version. 複数のバージョンが存在し、格納する必要があることをクライアントキャッシュとプロキシキャッシュに指示するために、 Vary ヘッダーに値を追加し Accept-Encoding ます。In order to instruct client and proxy caches that multiple versions exist and should be stored, the Vary header is added with an Accept-Encoding value. ASP.NET Core 2.0 以降では、 Vary 応答が圧縮されるときに、ミドルウェアによってヘッダーが自動的に追加されます。In ASP.NET Core 2.0 or later, the middleware adds the Vary header automatically when the response is compressed.

Nginx リバースプロキシの背後にあるミドルウェアの問題Middleware issue when behind an Nginx reverse proxy

要求が Nginx によってプロキシされている場合、 Accept-Encoding ヘッダーは削除されます。When a request is proxied by Nginx, the Accept-Encoding header is removed. ヘッダーを削除すると、 Accept-Encoding ミドルウェアが応答を圧縮できなくなります。Removal of the Accept-Encoding header prevents the middleware from compressing the response. 詳細については、「 NGINX: Compression And 伸張」を参照してください。For more information, see NGINX: Compression and Decompression. この問題は、 Nginx (aspnet/BasicMiddleware #123) のパススルー圧縮によって追跡されます。This issue is tracked by Figure out pass-through compression for Nginx (aspnet/BasicMiddleware #123).

IIS 動的圧縮の使用Working with IIS dynamic compression

アプリケーションに対して無効にする、アクティブな IIS 動的圧縮モジュールがサーバーレベルで構成されている場合は、 web.config ファイルを追加してモジュールを無効にします。If you have an active IIS Dynamic Compression Module configured at the server level that you would like to disable for an app, disable the module with an addition to the web.config file. 詳細については、「Disabling IIS modules」 (IIS モジュールの無効化) を参照してください。For more information, see Disabling IIS modules.

トラブルシューティングTroubleshooting

Fiddler消火バグPostmanなどのツールを使用します。これにより、 Accept-Encoding 要求ヘッダーを設定し、応答ヘッダー、サイズ、本文を調べることができます。Use a tool like Fiddler, Firebug, or Postman, which allow you to set the Accept-Encoding request header and study the response headers, size, and body. 既定では、応答圧縮ミドルウェアは、次の条件を満たす応答を圧縮します。By default, Response Compression Middleware compresses responses that meet the following conditions:

  • Accept-Encodingヘッダーには gzip 、設定した * カスタム圧縮プロバイダーに一致する値、、またはカスタムエンコーディングが含まれています。The Accept-Encoding header is present with a value of gzip, *, or custom encoding that matches a custom compression provider that you've established. 値は、 identity または品質値 (qvalue, q ) の 0 (ゼロ) に設定することはできません。The value must not be identity or have a quality value (qvalue, q) setting of 0 (zero).
  • MIME の種類 ( Content-Type ) を設定し、で構成されている mime の種類と一致させる必要があり ResponseCompressionOptions ます。The MIME type (Content-Type) must be set and must match a MIME type configured on the ResponseCompressionOptions.
  • 要求にヘッダーを含めることはできません Content-RangeThe request must not include the Content-Range header.
  • 応答圧縮ミドルウェアのオプションで secure protocol (https) が構成されている場合を除き、要求では安全でないプロトコル (http) を使用する必要があります。The request must use insecure protocol (http), unless secure protocol (https) is configured in the Response Compression Middleware options. セキュリティで保護されたコンテンツの圧縮を有効にする場合は、 前述 の危険に注意してください。Note the danger described above when enabling secure content compression.

その他の資料Additional resources