Compresión de respuesta en ASP.NET Core
El ancho de banda de red es un recurso limitado. La reducción del tamaño de la respuesta suele aumentar la capacidad de respuesta de una aplicación, a menudo drásticamente. Una manera de reducir los tamaños de carga es comprimir las respuestas de una aplicación.
Vea o descargue el código de ejemplo (cómo descargarlo)
Cuándo usar el middleware de compresión de respuesta
Use tecnologías de compresión de respuesta basada en servidor en IIS, Apache o Nginx. Es probable que el rendimiento del middleware no coincida con el de los módulos de servidor. HTTP.sys servidor y servidor no ofrecen actualmente Kestrel compatibilidad con compresión integrada.
Use el middleware de compresión de respuesta cuando:
- No se pueden usar las siguientes tecnologías de compresión basadas en servidor:
- Hospedaje directamente en:
- HTTP.sys servidor (anteriormente denominado WebListener)
- Kestrel Servidor
Compresión de las respuestas
Normalmente, cualquier respuesta no comprimida de forma nativa puede beneficiarse de la compresión de respuesta. Las respuestas no comprimidas de forma nativa suelen incluir: CSS, JavaScript, HTML, XML y JSON. No debe comprimir los recursos comprimidos de forma nativa, como los archivos PNG. Si intenta comprimir aún más una respuesta comprimida de forma nativa, es probable que cualquier pequeña reducción adicional en el tamaño y el tiempo de transmisión se eclipse por el tiempo que se tardó en procesar la compresión. No comprima archivos menores que unos 150-1000 bytes (en función del contenido del archivo y la eficacia de la compresión). La sobrecarga de comprimir archivos pequeños puede producir un archivo comprimido mayor que el archivo sin comprimir.
Cuando un cliente puede procesar contenido comprimido, el cliente debe informar al servidor de sus funcionalidades mediante el envío Accept-Encoding del encabezado con la solicitud. Cuando un servidor envía contenido comprimido, debe incluir información en el encabezado sobre cómo se codifica la Content-Encoding respuesta comprimida. Las designaciones de codificación de contenido compatibles con el middleware se muestran en la tabla siguiente.
Accept-Encoding valores de encabezado |
Middleware compatible | Descripción |
|---|---|---|
br |
Sí (predeterminado) | Formato de datos comprimidos de Brotli |
deflate |
No | Formato de datos comprimidos DEFLATE |
exi |
No | Intercambio XML eficaz de W3C |
gzip |
Sí | Formato de archivo Gzip |
identity |
Sí | Identificador "Sin codificación": no se debe codificar la respuesta. |
pack200-gzip |
No | Formato de transferencia de red para archivos java |
* |
Sí | Cualquier codificación de contenido disponible no solicitada explícitamente |
Para obtener más información, vea la lista de codificación de contenido oficial de IANA.
El middleware permite agregar proveedores de compresión adicionales para los valores Accept-Encoding de encabezado personalizados. Para obtener más información, vea Proveedores personalizados a continuación.
El middleware es capaz de reaccionar a la ponderación del valor de calidad (qvalue, ) cuando lo envía el cliente para dar prioridad a q los esquemas de compresión. Para obtener más información, vea RFC 7231: Accept-Encoding.
Los algoritmos de compresión están sujetos a un equilibrio entre la velocidad de compresión y la eficacia de la compresión. La eficacia en este contexto hace referencia al tamaño de la salida después de la compresión. El tamaño más pequeño se logra con la compresión más óptima.
Los encabezados implicados en la solicitud, envío, almacenamiento en caché y recepción de contenido comprimido se describen en la tabla siguiente.
| Encabezado | Role |
|---|---|
Accept-Encoding |
Se envía desde el cliente al servidor para indicar los esquemas de codificación de contenido aceptables para el cliente. |
Content-Encoding |
Se envía desde el servidor al cliente para indicar la codificación del contenido en la carga. |
Content-Length |
Cuando se produce la compresión, se Content-Length quita el encabezado, ya que el contenido del cuerpo cambia cuando se comprime la respuesta. |
Content-MD5 |
Cuando se produce la compresión, se quita el encabezado, ya que el contenido del cuerpo ha Content-MD5 cambiado y el hash ya no es válido. |
Content-Type |
Especifica el tipo MIME del contenido. Cada respuesta debe especificar su Content-Type . El middleware comprueba este valor para determinar si se debe comprimir la respuesta. El middleware especifica un conjunto de tipos MIME predeterminados que puede codificar, pero puede reemplazar o agregar tipos MIME. |
Vary |
Cuando el servidor lo envía con un valor de a clientes y servidores proxy, el encabezado indica al cliente o proxy que debe almacenar en caché (variar) las respuestas en función del valor del encabezado de la Accept-Encoding Vary Accept-Encoding solicitud. El resultado de devolver contenido con el encabezado es que las respuestas comprimidas y sin comprimir se almacenan en Vary: Accept-Encoding caché por separado. |
Explore las características del middleware de compresión de respuesta con la aplicación de ejemplo. En el ejemplo se muestra lo siguiente:
- Compresión de respuestas de aplicaciones mediante Gzip y proveedores de compresión personalizados.
- Cómo agregar un tipo MIME a la lista predeterminada de tipos MIME para la compresión.
Paquete
El middleware de compresión de respuesta lo proporciona el paquete Microsoft.AspNetCore.ResponseCompression, que se incluye implícitamente en ASP.NET Core aplicaciones.
Configuración
El código siguiente muestra cómo habilitar el middleware de compresión de respuesta para los tipos MIME predeterminados y los proveedores de compresión (Brotli y Gzip):
public class Startup
{
public void ConfigureServices(IServiceCollection services)
{
services.AddResponseCompression();
}
public void Configure(IApplicationBuilder app, IHostingEnvironment env)
{
app.UseResponseCompression();
}
}
Notas:
app.UseResponseCompressiondebe llamarse antes que cualquier middleware que comprima las respuestas. Para más información, consulte Middleware de ASP.NET Core.- Use una herramienta como Fiddler, Firefox Browser Developero Postman para establecer el encabezado de solicitud y estudiar los encabezados de respuesta, el
Accept-Encodingtamaño y el cuerpo.
Envíe una solicitud a la aplicación de ejemplo sin Accept-Encoding el encabezado y observe que la respuesta está descomprimida. Los Content-Encoding Vary encabezados y no están presentes en la respuesta.

Envíe una solicitud a la aplicación de ejemplo con Accept-Encoding: br el encabezado (compresión Brotli) y observe que la respuesta está comprimida. Los Content-Encoding Vary encabezados y están presentes en la respuesta.

Proveedores
Proveedor de compresión brotli
Use para comprimir las respuestas con el formato BrotliCompressionProvider de datos comprimidos de Brotli.
Si no se agrega explícitamente ningún proveedor de compresión a CompressionProviderCollection :
- El proveedor de compresión Brotli se agrega de forma predeterminada a la matriz de proveedores de compresión junto con el proveedor de compresión Gzip.
- La compresión tiene como valor predeterminado la compresión brotli cuando el cliente admite el formato de datos comprimidos de Brotli. Si el cliente no admite Brotli, la compresión se establecerá de forma predeterminada en Gzip cuando el cliente admita la compresión Gzip.
public void ConfigureServices(IServiceCollection services)
{
services.AddResponseCompression();
}
El proveedor de compresión Brotli debe agregarse cuando se agrega explícitamente cualquier proveedor de compresión:
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" });
});
}
Establezca el nivel de compresión con BrotliCompressionProviderOptions . El proveedor de compresión Brotli tiene como valor predeterminado el nivel de compresión más rápido(CompressionLevel.Fastest),que podría no producir la compresión más eficaz. Si se desea la compresión más eficaz, configure el middleware para una compresión óptima.
| Nivel de compresión | Descripción |
|---|---|
| CompressionLevel.Fastest | La compresión debe completarse lo más rápido posible, incluso si la salida resultante no se comprime de forma óptima. |
| CompressionLevel.NoCompression | No se debe realizar ninguna compresión. |
| CompressionLevel.Optimal | Las respuestas deben comprimirse de forma óptima, incluso si la compresión tarda más tiempo en completarse. |
public void ConfigureServices(IServiceCollection services)
{
services.AddResponseCompression();
services.Configure<BrotliCompressionProviderOptions>(options =>
{
options.Level = CompressionLevel.Fastest;
});
}
Proveedor de compresión Gzip
Use para GzipCompressionProvider comprimir las respuestas con el formato de archivo Gzip.
Si no se agrega explícitamente ningún proveedor de compresión a CompressionProviderCollection :
- El proveedor de compresión Gzip se agrega de forma predeterminada a la matriz de proveedores de compresión junto con el proveedor de compresión Brotli.
- La compresión tiene como valor predeterminado la compresión brotli cuando el cliente admite el formato de datos comprimidos de Brotli. Si el cliente no admite Brotli, la compresión se establecerá de forma predeterminada en Gzip cuando el cliente admita la compresión Gzip.
public void ConfigureServices(IServiceCollection services)
{
services.AddResponseCompression();
}
El proveedor de compresión Gzip debe agregarse cuando se agregan explícitamente los proveedores de compresión:
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" });
});
}
Establezca el nivel de compresión con GzipCompressionProviderOptions . El proveedor de compresión Gzip tiene como valor predeterminado el nivel de compresión más rápido(CompressionLevel.Fastest),que podría no producir la compresión más eficaz. Si se desea la compresión más eficaz, configure el middleware para una compresión óptima.
| Nivel de compresión | Descripción |
|---|---|
| CompressionLevel.Fastest | La compresión debe completarse lo más rápido posible, incluso si la salida resultante no se comprime de forma óptima. |
| CompressionLevel.NoCompression | No se debe realizar ninguna compresión. |
| CompressionLevel.Optimal | Las respuestas deben comprimirse de forma óptima, incluso si la compresión tarda más tiempo en completarse. |
public void ConfigureServices(IServiceCollection services)
{
services.AddResponseCompression();
services.Configure<GzipCompressionProviderOptions>(options =>
{
options.Level = CompressionLevel.Fastest;
});
}
Proveedores personalizados
Cree implementaciones de compresión personalizadas con ICompressionProvider . representa EncodingName la codificación de contenido que ICompressionProvider genera. El middleware usa esta información para elegir el proveedor en función de la lista especificada en el Accept-Encoding encabezado de la solicitud.
Con la aplicación de ejemplo, el cliente envía una solicitud con el Accept-Encoding: mycustomcompression encabezado . El middleware usa la implementación de compresión personalizada y devuelve la respuesta con un Content-Encoding: mycustomcompression encabezado . El cliente debe poder descomprimir la codificación personalizada para que funcione una implementación de compresión personalizada.
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;
}
}
Envíe una solicitud a la aplicación de ejemplo con el Accept-Encoding: mycustomcompression encabezado y observe los encabezados de respuesta. Los Vary Content-Encoding encabezados y están presentes en la respuesta. El cuerpo de la respuesta (no se muestra) no se comprime mediante el ejemplo. No hay una implementación de compresión en la CustomCompressionProvider clase del ejemplo. Sin embargo, el ejemplo muestra dónde implementaría este algoritmo de compresión.

tipos MIME
El middleware especifica un conjunto predeterminado de tipos MIME para la compresión:
application/javascriptapplication/jsonapplication/xmltext/csstext/htmltext/jsontext/plaintext/xml
Reemplace o anexe tipos MIME por las opciones de Middleware de compresión de respuesta. Tenga en cuenta que no se admiten tipos MIME comodín, text/* como . La aplicación de ejemplo agrega un tipo MIME para y comprime y sirve la imagen ASP.NET Core image/svg+xml banner (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" });
});
}
Compresión con protocolo seguro
Las respuestas comprimidas a través de conexiones seguras se pueden controlar con la EnableForHttps opción , que está deshabilitada de forma predeterminada. El uso de la compresión con páginas generadas dinámicamente puede provocar problemas de seguridad como los ataques CRIME y BREACH.
Agregar el encabezado Vary
Al comprimir respuestas basadas en el encabezado, hay potencialmente varias versiones comprimidas de la respuesta Accept-Encoding y una versión sin comprimir. Para indicar a las cachés de cliente y proxy que existen varias versiones y que deben almacenarse, el encabezado Vary se agrega con un valor Accept-Encoding . En ASP.NET Core 2.0 o posterior, el middleware agrega el encabezado automáticamente Vary cuando se comprime la respuesta.
Problema de middleware cuando se está detrás de un proxy inverso de Nginx
Cuando Nginx proxya una solicitud, se Accept-Encoding quita el encabezado. La eliminación Accept-Encoding del encabezado impide que el middleware comprima la respuesta. Para obtener más información, vea NGINX: Compresión y descompresión. El seguimiento de este problema se realiza mediante La compresión de paso a través para Nginx (aspnet/BasicMiddleware #123).
Trabajar con la compresión dinámica de IIS
Si tiene un módulo de compresión dinámica de IIS activo configurado en el nivel de servidor que desea deshabilitar para una aplicación, deshabilite el módulo con una adición al archivoweb.config servidor. Para más información, vea Disabling IIS modules (Deshabilitación de módulos de IIS).
Solución de problemas
Use una herramienta como Fiddler, Firefox Browser Developero Postman,que le permite establecer el encabezado de solicitud y estudiar los encabezados de respuesta, el tamaño Accept-Encoding y el cuerpo. De forma predeterminada, el middleware de compresión de respuesta comprime las respuestas que cumplen las condiciones siguientes:
- El encabezado está presente con un valor de , , o codificación personalizada que coincide con un proveedor de compresión personalizado que
Accept-Encodingbrhagzip*establecido. El valor no debe seridentityni tener un valor de calidad (qvalue, ) deq0 (cero). - El tipo MIME (
Content-Type) debe establecerse y debe coincidir con un tipo MIME configurado en ResponseCompressionOptions . - La solicitud no debe incluir el
Content-Rangeencabezado . - La solicitud debe usar el protocolo no seguro (http), a menos que el protocolo seguro (https) esté configurado en las opciones del middleware de compresión de respuesta. Tenga en cuenta el peligro descrito anteriormente al habilitar la compresión de contenido segura.
Recursos adicionales
El ancho de banda de red es un recurso limitado. La reducción del tamaño de la respuesta suele aumentar la capacidad de respuesta de una aplicación, a menudo drásticamente. Una manera de reducir los tamaños de carga es comprimir las respuestas de una aplicación.
Vea o descargue el código de ejemplo (cómo descargarlo)
Cuándo usar el middleware de compresión de respuesta
Use tecnologías de compresión de respuesta basada en servidor en IIS, Apache o Nginx. Es probable que el rendimiento del middleware no coincida con el de los módulos de servidor. HTTP.sys servidor y servidor no ofrecen actualmente Kestrel compatibilidad con compresión integrada.
Use el middleware de compresión de respuesta cuando:
- No se pueden usar las siguientes tecnologías de compresión basadas en servidor:
- Hospedaje directamente en:
- HTTP.sys servidor (anteriormente denominado WebListener)
- Kestrel Servidor
Compresión de las respuestas
Normalmente, cualquier respuesta no comprimida de forma nativa puede beneficiarse de la compresión de respuesta. Las respuestas no comprimidas de forma nativa suelen incluir: CSS, JavaScript, HTML, XML y JSON. No debe comprimir los recursos comprimidos de forma nativa, como los archivos PNG. Si intenta comprimir aún más una respuesta comprimida de forma nativa, es probable que cualquier pequeña reducción adicional en el tamaño y el tiempo de transmisión se eclipse por el tiempo que se tardó en procesar la compresión. No comprima archivos menores que unos 150-1000 bytes (en función del contenido del archivo y la eficacia de la compresión). La sobrecarga de comprimir archivos pequeños puede producir un archivo comprimido mayor que el archivo sin comprimir.
Cuando un cliente puede procesar contenido comprimido, el cliente debe informar al servidor de sus funcionalidades mediante el envío Accept-Encoding del encabezado con la solicitud. Cuando un servidor envía contenido comprimido, debe incluir información en el encabezado sobre cómo se codifica la Content-Encoding respuesta comprimida. Las designaciones de codificación de contenido compatibles con el middleware se muestran en la tabla siguiente.
Accept-Encoding valores de encabezado |
Middleware compatible | Descripción |
|---|---|---|
br |
Sí (predeterminado) | Formato de datos comprimidos de Brotli |
deflate |
No | DEFLATE formato de datos comprimidos |
exi |
No | Intercambio XML eficaz de W3C |
gzip |
Sí | Formato de archivo Gzip |
identity |
Sí | Identificador "Sin codificación": no se debe codificar la respuesta. |
pack200-gzip |
No | Formato de transferencia de red para archivos java |
* |
Sí | Cualquier codificación de contenido disponible no solicitada explícitamente |
Para obtener más información, vea la Lista oficial de codificación de contenido de IANA.
El middleware permite agregar proveedores de compresión adicionales para los valores de Accept-Encoding encabezado personalizados. Para obtener más información, vea Proveedores personalizados a continuación.
El middleware es capaz de reaccionar a la ponderación del valor de calidad (qvalue, ) cuando lo envía el cliente para priorizar q los esquemas de compresión. Para obtener más información, vea RFC 7231: Accept-Encoding.
Los algoritmos de compresión están sujetos a un equilibrio entre la velocidad de compresión y la eficacia de la compresión. La eficacia en este contexto hace referencia al tamaño de la salida después de la compresión. El tamaño más pequeño se logra con la compresión más óptima.
Los encabezados implicados en la solicitud, el envío, el almacenamiento en caché y la recepción de contenido comprimido se describen en la tabla siguiente.
| Encabezado | Role |
|---|---|
Accept-Encoding |
Se envía desde el cliente al servidor para indicar los esquemas de codificación de contenido aceptables para el cliente. |
Content-Encoding |
Se envía desde el servidor al cliente para indicar la codificación del contenido en la carga. |
Content-Length |
Cuando se produce la compresión, se Content-Length quita el encabezado, ya que el contenido del cuerpo cambia cuando se comprime la respuesta. |
Content-MD5 |
Cuando se produce la compresión, se quita el encabezado, ya que el contenido del cuerpo ha Content-MD5 cambiado y el hash ya no es válido. |
Content-Type |
Especifica el tipo MIME del contenido. Cada respuesta debe especificar su Content-Type . El middleware comprueba este valor para determinar si se debe comprimir la respuesta. El middleware especifica un conjunto de tipos MIME predeterminados que puede codificar, pero puede reemplazar o agregar tipos MIME. |
Vary |
Cuando el servidor lo envía con un valor de a clientes y servidores proxy, el encabezado indica al cliente o proxy que debe almacenar en caché (variar) las respuestas en función del valor del encabezado de la Accept-Encoding Vary Accept-Encoding solicitud. El resultado de devolver contenido con el encabezado es que las respuestas comprimidas y sin comprimir se almacenan en Vary: Accept-Encoding caché por separado. |
Explore las características del middleware de compresión de respuesta con la aplicación de ejemplo. En el ejemplo se muestra lo siguiente:
- Compresión de respuestas de aplicación mediante Gzip y proveedores de compresión personalizados.
- Cómo agregar un tipo MIME a la lista predeterminada de tipos MIME para la compresión.
Paquete
Para incluir el middleware en un proyecto, agregue una referencia al metapaquete Microsoft.AspNetCore.App, que incluye el paquete Microsoft.AspNetCore.ResponseCompression.
Configuración
En el código siguiente se muestra cómo habilitar el middleware de compresión de respuesta para los tipos MIME predeterminados y los proveedores de compresión (Brotli y Gzip):
public class Startup
{
public void ConfigureServices(IServiceCollection services)
{
services.AddResponseCompression();
}
public void Configure(IApplicationBuilder app, IHostingEnvironment env)
{
app.UseResponseCompression();
}
}
Notas:
app.UseResponseCompressiondebe llamarse antes que cualquier middleware que comprime las respuestas. Para más información, consulte Middleware de ASP.NET Core.- Use una herramienta como Fiddler, Firefox Browser Developero Postman para establecer el encabezado de solicitud y estudiar los encabezados de respuesta, el tamaño
Accept-Encodingy el cuerpo.
Envíe una solicitud a la aplicación de ejemplo sin el Accept-Encoding encabezado y observe que la respuesta no está comprimida. Los Content-Encoding Vary encabezados y no están presentes en la respuesta.

Envíe una solicitud a la aplicación de ejemplo con el Accept-Encoding: br encabezado (compresión Brotli) y observe que la respuesta está comprimida. Los Content-Encoding Vary encabezados y están presentes en la respuesta.

Proveedores
Proveedor de compresión brotli
Use para comprimir las respuestas con el formato de datos BrotliCompressionProvider comprimidos brotli.
Si no se agrega explícitamente ningún proveedor de compresión a CompressionProviderCollection :
- El proveedor de compresión brotli se agrega de forma predeterminada a la matriz de proveedores de compresión junto con el proveedor de compresión de Gzip.
- La compresión tiene como valor predeterminado la compresión de Brotli cuando el cliente admite el formato de datos comprimidos de Brotli. Si brotli no es compatible con el cliente, la compresión tiene como valor predeterminado Gzip cuando el cliente admite la compresión Gzip.
public void ConfigureServices(IServiceCollection services)
{
services.AddResponseCompression();
}
El proveedor de compresión Brotli debe agregarse cuando se agrega explícitamente cualquier proveedor de compresión:
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" });
});
}
Establezca el nivel de compresión con BrotliCompressionProviderOptions . El proveedor de compresión brotli tiene como valor predeterminado el nivel de compresión más rápido(CompressionLevel.Fastest),que podría no generar la compresión más eficaz. Si se desea la compresión más eficaz, configure el middleware para una compresión óptima.
| Nivel de compresión | Descripción |
|---|---|
| CompressionLevel.Fastest | La compresión debe completarse lo más rápido posible, incluso si la salida resultante no se comprime de forma óptima. |
| CompressionLevel.NoCompression | No se debe realizar ninguna compresión. |
| CompressionLevel.Optimal | Las respuestas deben comprimirse de forma óptima, incluso si la compresión tarda más tiempo en completarse. |
public void ConfigureServices(IServiceCollection services)
{
services.AddResponseCompression();
services.Configure<BrotliCompressionProviderOptions>(options =>
{
options.Level = CompressionLevel.Fastest;
});
}
Proveedor de compresión Gzip
Use para GzipCompressionProvider comprimir las respuestas con el formato de archivo Gzip.
Si no se agrega explícitamente ningún proveedor de compresión a CompressionProviderCollection :
- El proveedor de compresión de Gzip se agrega de forma predeterminada a la matriz de proveedores de compresión junto con el proveedor de compresión brotli.
- La compresión tiene como valor predeterminado la compresión de Brotli cuando el cliente admite el formato de datos comprimidos de Brotli. Si brotli no es compatible con el cliente, la compresión tiene como valor predeterminado Gzip cuando el cliente admite la compresión Gzip.
public void ConfigureServices(IServiceCollection services)
{
services.AddResponseCompression();
}
El proveedor de compresión Gzip debe agregarse cuando se agrega explícitamente cualquier proveedor de compresión:
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" });
});
}
Establezca el nivel de compresión con GzipCompressionProviderOptions . El proveedor de compresión Gzip tiene como valor predeterminado el nivel de compresión más rápido(CompressionLevel.Fastest),que podría no generar la compresión más eficaz. Si se desea la compresión más eficaz, configure el middleware para una compresión óptima.
| Nivel de compresión | Descripción |
|---|---|
| CompressionLevel.Fastest | La compresión debe completarse lo más rápido posible, incluso si la salida resultante no se comprime de forma óptima. |
| CompressionLevel.NoCompression | No se debe realizar ninguna compresión. |
| CompressionLevel.Optimal | Las respuestas deben comprimirse de forma óptima, incluso si la compresión tarda más tiempo en completarse. |
public void ConfigureServices(IServiceCollection services)
{
services.AddResponseCompression();
services.Configure<GzipCompressionProviderOptions>(options =>
{
options.Level = CompressionLevel.Fastest;
});
}
Proveedores personalizados
Cree implementaciones de compresión personalizadas con ICompressionProvider . representa EncodingName la codificación de contenido que ICompressionProvider genera. El middleware usa esta información para elegir el proveedor en función de la lista especificada en el Accept-Encoding encabezado de la solicitud.
Con la aplicación de ejemplo, el cliente envía una solicitud con el Accept-Encoding: mycustomcompression encabezado . El middleware usa la implementación de compresión personalizada y devuelve la respuesta con un Content-Encoding: mycustomcompression encabezado . El cliente debe ser capaz de descomprimir la codificación personalizada para que funcione una implementación de compresión personalizada.
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;
}
}
Envíe una solicitud a la aplicación de ejemplo con el Accept-Encoding: mycustomcompression encabezado y observe los encabezados de respuesta. Los Vary Content-Encoding encabezados y están presentes en la respuesta. El cuerpo de la respuesta (no se muestra) no está comprimido por el ejemplo. No hay ninguna implementación de compresión en la CustomCompressionProvider clase del ejemplo. Sin embargo, el ejemplo muestra dónde implementaría este algoritmo de compresión.

tipos MIME
El middleware especifica un conjunto predeterminado de tipos MIME para la compresión:
application/javascriptapplication/jsonapplication/xmltext/csstext/htmltext/jsontext/plaintext/xml
Reemplace o anexe tipos MIME por las opciones de Middleware de compresión de respuesta. Tenga en cuenta que no se admiten tipos MIME comodín, text/* como . La aplicación de ejemplo agrega un tipo MIME para y comprime y sirve la imagen ASP.NET Core image/svg+xml banner (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" });
});
}
Compresión con protocolo seguro
Las respuestas comprimidas a través de conexiones seguras se pueden controlar con la EnableForHttps opción , que está deshabilitada de forma predeterminada. El uso de la compresión con páginas generadas dinámicamente puede provocar problemas de seguridad como los ataques CRIME y BREACH.
Agregar el encabezado Vary
Al comprimir respuestas basadas en el encabezado, hay potencialmente varias versiones comprimidas de la respuesta Accept-Encoding y una versión sin comprimir. Para indicar a las cachés de cliente y proxy que existen varias versiones y que deben almacenarse, el encabezado se Vary agrega con un valor Accept-Encoding . En ASP.NET Core 2.0 o posterior, el middleware agrega el encabezado automáticamente Vary cuando se comprime la respuesta.
Problema de middleware cuando se está detrás de un proxy inverso de Nginx
Cuando Nginx proxya una solicitud, se Accept-Encoding quita el encabezado. La eliminación Accept-Encoding del encabezado impide que el middleware comprima la respuesta. Para obtener más información, vea NGINX: Compression and Decompression. Para realizar el seguimiento de este problema, consulte Compresión de paso a través para Nginx (aspnet/BasicMiddleware #123).
Trabajar con compresión dinámica de IIS
Si tiene un módulo de compresión dinámica de IIS activo configurado en el nivel de servidor que desea deshabilitar para una aplicación, deshabilite el módulo con una adición al archivoweb.config servidor. Para más información, vea Disabling IIS modules (Deshabilitación de módulos de IIS).
Solución de problemas
Use una herramienta como Fiddler, Firefox Browser Developero Postman,que le permite establecer el encabezado de solicitud y estudiar los encabezados de respuesta, el tamaño Accept-Encoding y el cuerpo. De forma predeterminada, el middleware de compresión de respuesta comprime las respuestas que cumplen las condiciones siguientes:
- El encabezado está presente con un valor de , , o codificación personalizada que coincide con un proveedor de compresión
Accept-Encodingbrpersonalizado que hayagzip*establecido. El valor no debe seridentityni tener un valor de calidad (qvalue, ) deq0 (cero). - El tipo MIME (
Content-Type) debe establecerse y debe coincidir con un tipo MIME configurado en ResponseCompressionOptions . - La solicitud no debe incluir el
Content-Rangeencabezado . - La solicitud debe usar el protocolo no seguro (http), a menos que el protocolo seguro (https) esté configurado en las opciones de middleware de compresión de respuesta. Tenga en cuenta el peligro descrito anteriormente al habilitar la compresión de contenido segura.
Recursos adicionales
El ancho de banda de red es un recurso limitado. La reducción del tamaño de la respuesta suele aumentar la capacidad de respuesta de una aplicación, a menudo drásticamente. Una manera de reducir los tamaños de carga es comprimir las respuestas de una aplicación.
Vea o descargue el código de ejemplo (cómo descargarlo)
Cuándo usar middleware de compresión de respuesta
Use tecnologías de compresión de respuesta basada en servidor en IIS, Apache o Nginx. Es probable que el rendimiento del middleware no coincida con el de los módulos del servidor. HTTP.sys servidor y servidor no ofrecen actualmente Kestrel compatibilidad con compresión integrada.
Use el middleware de compresión de respuesta cuando:
- No se pueden usar las siguientes tecnologías de compresión basadas en servidor:
- Hospedaje directamente en:
- HTTP.sys servidor (anteriormente denominado WebListener)
- Kestrel Servidor
Compresión de las respuestas
Normalmente, cualquier respuesta no comprimida de forma nativa puede beneficiarse de la compresión de respuesta. Las respuestas que no se comprimen de forma nativa suelen incluir: CSS, JavaScript, HTML, XML y JSON. No debe comprimir los recursos comprimidos de forma nativa, como los archivos PNG. Si intenta comprimir aún más una respuesta comprimida de forma nativa, es probable que cualquier pequeña reducción adicional en el tamaño y el tiempo de transmisión se eclipse por el tiempo que se tardó en procesar la compresión. No comprima archivos menores que unos 150-1000 bytes (según el contenido del archivo y la eficacia de la compresión). La sobrecarga de comprimir archivos pequeños puede producir un archivo comprimido mayor que el archivo sin comprimir.
Cuando un cliente puede procesar contenido comprimido, el cliente debe informar al servidor de sus funcionalidades mediante el envío del Accept-Encoding encabezado con la solicitud. Cuando un servidor envía contenido comprimido, debe incluir información en el encabezado sobre cómo se codifica Content-Encoding la respuesta comprimida. Las designaciones de codificación de contenido compatibles con el middleware se muestran en la tabla siguiente.
Accept-Encoding valores de encabezado |
Middleware compatible | Descripción |
|---|---|---|
br |
No | Formato de datos comprimidos de Brotli |
deflate |
No | DEFLATE formato de datos comprimidos |
exi |
No | Intercambio XML eficaz de W3C |
gzip |
Sí (predeterminado) | Formato de archivo Gzip |
identity |
Sí | Identificador "Sin codificación": no se debe codificar la respuesta. |
pack200-gzip |
No | Formato de transferencia de red para archivos java |
* |
Sí | Cualquier codificación de contenido disponible no solicitada explícitamente |
Para obtener más información, vea la Lista oficial de codificación de contenido de IANA.
El middleware permite agregar proveedores de compresión adicionales para los valores de Accept-Encoding encabezado personalizados. Para obtener más información, vea Proveedores personalizados a continuación.
El middleware es capaz de reaccionar a la ponderación del valor de calidad (qvalue, ) cuando lo envía el cliente para priorizar q los esquemas de compresión. Para obtener más información, vea RFC 7231: Accept-Encoding.
Los algoritmos de compresión están sujetos a un equilibrio entre la velocidad de compresión y la eficacia de la compresión. La eficacia en este contexto hace referencia al tamaño de la salida después de la compresión. El tamaño más pequeño se logra con la compresión más óptima.
Los encabezados implicados en la solicitud, el envío, el almacenamiento en caché y la recepción de contenido comprimido se describen en la tabla siguiente.
| Encabezado | Role |
|---|---|
Accept-Encoding |
Se envía desde el cliente al servidor para indicar los esquemas de codificación de contenido aceptables para el cliente. |
Content-Encoding |
Se envía desde el servidor al cliente para indicar la codificación del contenido en la carga. |
Content-Length |
Cuando se produce la compresión, se Content-Length quita el encabezado, ya que el contenido del cuerpo cambia cuando se comprime la respuesta. |
Content-MD5 |
Cuando se produce la compresión, se quita el encabezado, ya que el contenido del cuerpo ha Content-MD5 cambiado y el hash ya no es válido. |
Content-Type |
Especifica el tipo MIME del contenido. Cada respuesta debe especificar su Content-Type . El middleware comprueba este valor para determinar si se debe comprimir la respuesta. El middleware especifica un conjunto de tipos MIME predeterminados que puede codificar, pero puede reemplazar o agregar tipos MIME. |
Vary |
Cuando el servidor lo envía con un valor de a clientes y servidores proxy, el encabezado indica al cliente o proxy que debe almacenar en caché (variar) las respuestas en función del valor del encabezado de la Accept-Encoding Vary Accept-Encoding solicitud. El resultado de devolver contenido con el encabezado es que las respuestas comprimidas y sin comprimir se almacenan en Vary: Accept-Encoding caché por separado. |
Explore las características del middleware de compresión de respuesta con la aplicación de ejemplo. En el ejemplo se muestra lo siguiente:
- Compresión de respuestas de aplicación mediante Gzip y proveedores de compresión personalizados.
- Cómo agregar un tipo MIME a la lista predeterminada de tipos MIME para la compresión.
Paquete
Para incluir el middleware en un proyecto, agregue una referencia al metapaquete Microsoft.AspNetCore.App, que incluye el paquete Microsoft.AspNetCore.ResponseCompression.
Configuración
El código siguiente muestra cómo habilitar el middleware de compresión de respuesta para los tipos MIME predeterminados y el proveedor de compresión Gzip:
public class Startup
{
public void ConfigureServices(IServiceCollection services)
{
services.AddResponseCompression();
}
public void Configure(IApplicationBuilder app, IHostingEnvironment env)
{
app.UseResponseCompression();
}
}
Notas:
app.UseResponseCompressiondebe llamarse antes que cualquier middleware que comprime las respuestas. Para más información, consulte Middleware de ASP.NET Core.- Use una herramienta como Fiddler, Firefox Browser Developero Postman para establecer el encabezado de solicitud y estudiar los encabezados de respuesta, el tamaño
Accept-Encodingy el cuerpo.
Envíe una solicitud a la aplicación de ejemplo sin el Accept-Encoding encabezado y observe que la respuesta no está comprimida. Los Content-Encoding Vary encabezados y no están presentes en la respuesta.

Envíe una solicitud a la aplicación de ejemplo con el Accept-Encoding: gzip encabezado y observe que la respuesta está comprimida. Los Content-Encoding Vary encabezados y están presentes en la respuesta.

Proveedores
Proveedor de compresión Gzip
Use para GzipCompressionProvider comprimir las respuestas con el formato de archivo Gzip.
Si no se agrega explícitamente ningún proveedor de compresión a CompressionProviderCollection :
- El proveedor de compresión Gzip se agrega de forma predeterminada a la matriz de proveedores de compresión.
- La compresión tiene como valor predeterminado Gzip cuando el cliente admite la compresión Gzip.
public void ConfigureServices(IServiceCollection services)
{
services.AddResponseCompression();
}
El proveedor de compresión Gzip debe agregarse cuando se agrega explícitamente cualquier proveedor de compresión:
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" });
});
}
Establezca el nivel de compresión con GzipCompressionProviderOptions . El proveedor de compresión Gzip tiene como valor predeterminado el nivel de compresión más rápido(CompressionLevel.Fastest),que podría no generar la compresión más eficaz. Si se desea la compresión más eficaz, configure el middleware para una compresión óptima.
| Nivel de compresión | Descripción |
|---|---|
| CompressionLevel.Fastest | La compresión debe completarse lo más rápido posible, incluso si la salida resultante no se comprime de forma óptima. |
| CompressionLevel.NoCompression | No se debe realizar ninguna compresión. |
| CompressionLevel.Optimal | Las respuestas deben comprimirse de forma óptima, incluso si la compresión tarda más tiempo en completarse. |
public void ConfigureServices(IServiceCollection services)
{
services.AddResponseCompression();
services.Configure<GzipCompressionProviderOptions>(options =>
{
options.Level = CompressionLevel.Fastest;
});
}
Proveedores personalizados
Cree implementaciones de compresión personalizadas con ICompressionProvider . representa EncodingName la codificación de contenido que ICompressionProvider genera. El middleware usa esta información para elegir el proveedor en función de la lista especificada en el Accept-Encoding encabezado de la solicitud.
Con la aplicación de ejemplo, el cliente envía una solicitud con el Accept-Encoding: mycustomcompression encabezado . El middleware usa la implementación de compresión personalizada y devuelve la respuesta con un Content-Encoding: mycustomcompression encabezado . El cliente debe ser capaz de descomprimir la codificación personalizada para que funcione una implementación de compresión personalizada.
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;
}
}
Envíe una solicitud a la aplicación de ejemplo con el Accept-Encoding: mycustomcompression encabezado y observe los encabezados de respuesta. Los Vary Content-Encoding encabezados y están presentes en la respuesta. El cuerpo de la respuesta (no se muestra) no está comprimido por el ejemplo. No hay ninguna implementación de compresión en la CustomCompressionProvider clase del ejemplo. Sin embargo, el ejemplo muestra dónde implementaría este algoritmo de compresión.

tipos MIME
El middleware especifica un conjunto predeterminado de tipos MIME para la compresión:
application/javascriptapplication/jsonapplication/xmltext/csstext/htmltext/jsontext/plaintext/xml
Reemplace o anexe tipos MIME por las opciones de Middleware de compresión de respuesta. Tenga en cuenta que no se admiten tipos MIME comodín, text/* como . La aplicación de ejemplo agrega un tipo MIME para y comprime y sirve la imagen ASP.NET Core image/svg+xml banner (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" });
});
}
Compresión con protocolo seguro
Las respuestas comprimidas a través de conexiones seguras se pueden controlar con la EnableForHttps opción , que está deshabilitada de forma predeterminada. El uso de la compresión con páginas generadas dinámicamente puede provocar problemas de seguridad como los ataques CRIME y BREACH.
Agregar el encabezado Vary
Al comprimir respuestas basadas en el encabezado, hay potencialmente varias versiones comprimidas de la respuesta Accept-Encoding y una versión sin comprimir. Para indicar a las cachés de cliente y proxy que existen varias versiones y que deben almacenarse, el encabezado se Vary agrega con un valor Accept-Encoding . En ASP.NET Core 2.0 o posterior, el middleware agrega el encabezado automáticamente Vary cuando se comprime la respuesta.
Problema de middleware cuando se está detrás de un proxy inverso de Nginx
Cuando Nginx proxya una solicitud, se Accept-Encoding quita el encabezado. La eliminación Accept-Encoding del encabezado impide que el middleware comprima la respuesta. Para obtener más información, vea NGINX: Compression and Decompression. Para realizar el seguimiento de este problema, consulte Compresión de paso a través para Nginx (aspnet/BasicMiddleware #123).
Trabajar con compresión dinámica de IIS
Si tiene un módulo de compresión dinámica de IIS activo configurado en el nivel de servidor que desea deshabilitar para una aplicación, deshabilite el módulo con una adición al archivoweb.config servidor. Para más información, vea Disabling IIS modules (Deshabilitación de módulos de IIS).
Solución de problemas
Use una herramienta como Fiddler, Firefox Browser Developero Postman,que le permite establecer el encabezado de solicitud y estudiar los encabezados de respuesta, el tamaño Accept-Encoding y el cuerpo. De forma predeterminada, el middleware de compresión de respuesta comprime las respuestas que cumplen las condiciones siguientes:
- El encabezado está presente con un valor de , o una codificación personalizada que coincide con un proveedor de compresión
Accept-Encodinggzippersonalizado que ha*establecido. El valor no debe seridentityni tener un valor de calidad (qvalue, ) deq0 (cero). - El tipo MIME (
Content-Type) debe establecerse y debe coincidir con un tipo MIME configurado en ResponseCompressionOptions . - La solicitud no debe incluir el
Content-Rangeencabezado . - La solicitud debe usar el protocolo no seguro (http), a menos que el protocolo seguro (https) esté configurado en las opciones de middleware de compresión de respuesta. Tenga en cuenta el peligro descrito anteriormente al habilitar la compresión de contenido segura.