Uso de la compresión de IIS

Por Yanbing Shi

En el artículo se proporciona información general sobre cómo usar la compresión de IIS.

Nivel de compresión

La compresión HTTP es un intercambio entre el uso de la CPU y el ancho de banda. Para un algoritmo de compresión determinado, lograr una mayor relación de compresión normalmente viene con una velocidad de compresión más lenta y viceversa. El equilibrio entre la relación de compresión y la velocidad se controla mediante el nivel de compresión. Los niveles de compresión de iiszlib.dll, iisbrotli.dlly gzip.dll no coinciden entre sí en términos de intervalo, relación de compresión y velocidad. La comparación de los niveles de compresión permitidos de los tres proveedores de esquemas de compresión se resume en la tabla siguiente.

Proveedor de esquemas de compresión Nivel de compresión: sin compresión Nivel de compresión: mejor velocidad Nivel de compresión: mejor relación de compresión
gzip.dll N/A 0 10
iiszlib.dll 0 1 9
iisbrotli.dll N/A 0 11

Nota:

El nivel 0 de iiszlib.dll especifica que no hay compresión en vez de la compresión de máxima velocidad. El valor predeterminado del atributo dynamicCompressionLevel en el elemento <httpCompression> es 0 también. Por lo tanto, dynamicCompressionLevel debe establecerse explícitamente por encima de 0 para permitir que iiszlib.dll comprima el contenido generado dinámicamente.

Priorización de esquemas de compresión

Negociación del esquema de compresión HTTP

La negociación del esquema de compresión entre agentes de usuario y servidores IIS cumple con la especificación Requests For Comment (RFC) 7231:

  1. La negociación comienza con el agente de usuario que especifica la lista de esquemas de compresión aceptables en el encabezado de solicitud Accept-Encoding .

  2. El servidor examina el encabezado Accept-Encoding en la solicitud y selecciona un esquema que admite el servidor.

  3. El servidor aplica el algoritmo correspondiente para comprimir el cuerpo de la respuesta.

  4. Cuando el servidor devuelve la respuesta, agrega el encabezado de respuesta Content-Encoding con el esquema de compresión seleccionado como valor de encabezado.

  5. El agente de usuario usa el esquema indicado en el encabezado de respuesta Content-Encoding para descomprimir el cuerpo de la respuesta y para representar el contenido original al usuario.

Habilitación de varios esquemas de compresión

Una de las ideas clave detrás de la negociación del esquema de compresión HTTP es la posibilidad de admitir nuevos esquemas de compresión al tiempo que mantiene la compatibilidad con versiones anteriores con clientes o servidores antiguos.

Aunque la compresión Brotli ofrece la ventaja de una mayor relación de compresión y ha sido compatible con muchos exploradores, todavía no se adopta tan ampliamente como Gzip en el momento de escribir. Por lo tanto, una posible optimización es habilitar la compresión Brotli y Gzip , pero priorizar Brotli si el agente de usuario del lado cliente también lo admite.

IIS 10.0 versión 1803 o posterior

La priorización del esquema de compresión se admite en IIS 10.0 versión 1803 o superior. La prioridad de cada esquema de compresión viene determinada por su orden en la <scheme> colección del <httpCompression>elemento :

  • Un esquema de compresión que aparece en la parte superior de la <scheme> colección tiene prioridad sobre el que aparece después, si sus valores de calidad especificados en el valor de encabezado de solicitud Accept-Encoding son los mismos.
  • Un esquema de compresión con un valor de mayor calidad en el valor de encabezado de solicitud Accept-Encoding se prioriza sobre el que tiene un valor de calidad inferior independientemente de su orden en la <scheme> colección.

La instalación de IIS Compression registra iisbrotli.dll y iiszlib.dll como proveedores de esquemas de compresión br y gzip , respectivamente, y coloca br antes de gzip en la <scheme> colección:

<scheme name="br" dll="%ProgramFiles%\IIS\IIS Compression\iisbrotli.dll" />
<scheme name="gzip" dll="%ProgramFiles%\IIS\IIS Compression\iiszlib.dll" />

Este orden de configuración permite al servidor IIS priorizar Brotli sobre Gzip cuando la mayoría de los exploradores que admiten Brotli usan Accept-Encoding: gzip, deflate, br para la negociación del esquema de compresión.

Nota:

Normalmente, los navegadores que admiten compresión Brotli solo declaran br en el valor del encabezado Accept-Encoding cuando se usa HTTPS.

Antes de IIS 10.0, versión 1803

Aunque IIS anterior a la versión 10.0 versión 1803 permite habilitar varios esquemas de compresión, prioriza el esquema de compresión de acuerdo al orden de los esquemas que aparece en el valor del encabezado de solicitud Accept-Encoding:

  • El método de compresión que aparece primero (de izquierda a derecha) en el valor del encabezado de solicitud Accept-Encoding tiene prioridad sobre el que aparece después, si tienen los mismos valores de calidad.
  • Se prioriza un esquema de compresión con un valor de mayor calidad sobre el que tiene un valor de calidad inferior, independientemente de su orden en el valor del encabezado de solicitud Accept-Encoding .

En consecuencia, IIS siempre da prioridad a gzip sobre br para el escenario típico en el que el explorador establece Accept-Encoding: gzip, deflate, br el encabezado en la solicitud.

Una posible solución alternativa consiste en instalar el módulo de reescritura de direcciones URL y configurar una regla de reescritura para modificar el valor del encabezado Accept-Encoding . La siguiente configuración muestra una regla de reescritura de ejemplo que vuelve a escribir el valor del encabezado Accept-Encoding para incluir solo el esquema br si encuentra la cadena br en el valor de encabezado con un valor de calidad distinto de cero.

<rewrite>
    <allowedServerVariables>
        <add name="HTTP_ACCEPT_ENCODING" />
    </allowedServerVariables>
    <rules>
        <rule name="Prioritize Brotli">
            <match url=".*" />
            <conditions>
                <add input="{HTTP_ACCEPT_ENCODING}" pattern="\bbr(?!;q=0)\b" />
            </conditions>
            <serverVariables>
                <set name="HTTP_ACCEPT_ENCODING" value="br" />
            </serverVariables>
        </rule>
    </rules>
</rewrite>

Puede encontrar más detalles sobre cómo configurar las reglas de reescritura en Creación de reglas de reescritura para el módulo de reescritura de direcciones URL.

Prueba de la compresión de IIS

La compresión de IIS de prueba se puede realizar mediante:

  • Abrir un explorador y solicitar cierto contenido desde el servidor IIS.
  • Comprobar las solicitudes y respuestas a través de las herramientas de desarrollo del explorador.

Encabezados de respuesta de las herramientas de F12

Para probar la compresión de IIS para la compresión de contenido estático:

  • Asegúrese de que el tipo MIME del recurso solicitado está habilitado en la <staticTypes> colección del <httpCompression> elemento .
  • Asegúrese de que el tamaño del recurso solicitado es mayor que minFileSizeForComp el especificado en el <httpCompression> elemento .
  • Asegúrese de que se alcanza el umbral de "frecuencia de aciertos" para la dirección URL solicitada. El umbral se especifica mediante los frequentHitThreshold atributos y frequentHitTimePeriod del <serverRuntime> elemento . Como alternativa, establezca el valor del staticCompressionIgnoreHitFrequency atributo en el <httpCompression> elemento como true para deshabilitar la comprobación de "frecuencia de aciertos" solo con fines de prueba.

Para probar la compresión de IIS para la compresión de contenido dinámico:

  • Asegúrese de que el tipo MIME del recurso solicitado está habilitado en la <dynamicTypes> colección del <httpCompression> elemento .
  • Last updated on