Использование сжатия IIS

В этой статье представлен обзор использования сжатия IIS.

Уровень сжатия

Сжатие HTTP — это обмен ресурсов ЦП на пропускную способность. Для заданного алгоритма сжатия достижение более высокого коэффициента сжатия обычно сопровождается более медленной скоростью сжатия, и наоборот. Баланс между коэффициентом сжатия и скоростью контролируется уровнем сжатия. Уровни сжатия iiszlib.dll, iisbrotli.dllи gzip.dll не соответствуют друг другу с точки зрения диапазона, сжатия и скорости. Сравнение разрешенных уровней сжатия трех поставщиков схем сжатия приводится в таблице ниже.

Поставщик схемы сжатия	Уровень сжатия: нет сжатия	Уровень сжатия: оптимальная скорость	Уровень сжатия: лучшее соотношение сжатия
gzip.dll	N/A	0	10
iiszlib.dll	0	1	9
iisbrotli.dll	N/A	0	11

Замечание

Уровень 0 iiszlib.dll указывает отсутствие сжатия вместо сжатия с максимальной скоростью. Значение атрибута IIS dynamicCompressionLevel по умолчанию в элементе <httpCompression> равно 0. Поэтому dynamicCompressionLevel необходимо явно задать выше 0, чтобы разрешить iiszlib.dll сжимать динамически созданное содержимое.

Приоритет схемы сжатия

Согласование схемы сжатия HTTP

Согласование схемы сжатия между агентами пользователей и серверами IIS соответствует спецификации 7231 запроса на комментарий (RFC):

Согласование начинается с агента пользователя, указывающего список допустимых схем сжатия в заголовке запроса Accept-Encoding .
Сервер проверяет заголовок Accept-Encoding в запросе и выбирает схему, которую поддерживает сервер.
Сервер применяет соответствующий алгоритм для сжатия текста отклика.
Когда сервер отправляет ответ обратно, он добавляет заголовок ответа Content-Encoding с выбранной схемой сжатия в качестве значения заголовка.
Агент пользователя использует схему, указанную в заголовке ответа Content-Encoding , для распаковки текста ответа и отображения исходного содержимого пользователю.

Включение нескольких схем сжатия

Одним из ключевых идей для согласования схемы сжатия HTTP является возможность поддержки новых схем сжатия при сохранении обратной совместимости со старыми клиентами или серверами.

Хотя сжатие Brotli предлагает преимущество более высокого коэффициента сжатия и поддерживается многими браузерами, он по-прежнему не так широко принят, как Gzip во время написания. Таким образом, одна из возможных оптимизаций заключается в том, чтобы включить сжатие Brotli и Gzip , но определить приоритет Brotli , если агент пользователя на стороне клиента также поддерживает его.

IIS 10.0 версии 1803 или более поздней

Приоритет схемы сжатия поддерживается в IIS 10.0 версии 1803 или более поздней. Приоритет каждой схемы сжатия определяется его порядком в <scheme> коллекции <httpCompression>элемента:

Схема сжатия, отображаемая в верхней части <scheme> коллекции, имеет приоритет над схемой, отображаемой после, если указанные в значении заголовка запроса Accept-Encoding значения качества совпадают.
Схема сжатия с более высоким значением качества в заголовке запроса Accept-Encoding имеет приоритет над схемой с более низким значением качества независимо от их порядка в коллекции <scheme>.

Установка сжатия IIS регистрирует iisbrotli.dll и iiszlib.dll в качестве поставщиков схем сжатия br и gzip соответственно и размещает br перед gzip в коллекции <scheme>.

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

Такой порядок конфигурации позволяет серверу IIS определять приоритет Brotli над Gzip , если большинство браузеров, поддерживающих Brotli , используются Accept-Encoding: gzip, deflate, br для согласования схемы сжатия.

Замечание

Как правило, браузеры, поддерживающие сжатие Brotli, добавляют br в значение заголовка Accept-Encoding только при использовании HTTPS.

До IIS 10.0 версии 1803

Хотя IIS до версии 10.0 версии 1803 позволяет включить несколько схем сжатия, но он определяет схему сжатия на основе порядка схемы, отображаемой в значении заголовка запроса Accept-Encoding :

Схема сжатия, появляющаяся первой (слева направо) в значении заголовка запроса Accept-Encoding, имеет приоритет перед той, которая появляется позже, если у них одинаковые значения качества.
Схема сжатия с более высоким значением качества имеет приоритет перед схемой с более низким значением качества, независимо от их порядка в заголовке запроса Accept-Encoding.

Следовательно, IIS всегда отдает предпочтение gzip вместо br для типичного сценария, при установленном браузером заголовке Accept-Encoding: gzip, deflate, br в запросе.

Возможное решение заключается в установке модуля переопределения URL-адресов и настройке правила перезаписи для изменения значения заголовка Accept-Encoding . В следующей конфигурации показан пример правила переписывания, которое изменяет значение заголовка Accept-Encoding, чтобы оставить только схему br, если строка br найдена в значении заголовка с ненулевым значением качества.

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

Дополнительные сведения о настройке правил переопределения можно найти в разделе "Создание правил перезаписи" для модуля переопределения URL-адресов.

Тестирование сжатия IIS

Тестирование сжатия IIS можно выполнить следующими способами:

Открытие браузера и запрос определенного содержимого с сервера IIS.
Проверка запросов и ответов с помощью средств разработчика браузера.

Тестирование сжатия IIS для сжатия статического контента:

Убедитесь, что тип MIME запрошенного ресурса включен в <staticTypes> коллекции в элементе <httpCompression> .
Убедитесь, что запрошенный размер ресурса больше, чем minFileSizeForComp указано в <httpCompression> элементе.
Убедитесь, что пороговое значение "частота попадания" достигнуто для запрошенного URL-адреса. Пороговое значение указывается атрибутами frequentHitThresholdfrequentHitTimePeriod в элементе <serverRuntime> . Кроме того, задайте значение атрибута staticCompressionIgnoreHitFrequency в элементе <httpCompression> как true, чтобы отключить проверку 'частоты попаданий' только в целях тестирования.

Чтобы проверить сжатие IIS для динамического сжатия содержимого:

Убедитесь, что тип MIME запрошенного ресурса включен в <dynamicTypes> коллекции в элементе <httpCompression> .

Обратная связь

Были ли сведения на этой странице полезными?

Last updated on 2023-07-19