Verwenden der IIS-Komprimierung

Von Yanbing Shi

Der Artikel enthält eine Übersicht über die Verwendung der IIS-Komprimierung.

Compression Level

Die HTTP-Komprimierung ist ein Kompromiss zwischen CPU und Bandbreite. Bei einem bestimmten Komprimierungsalgorithmus geht eine höhere Komprimierungsrate in der Regel mit einer niedrigeren Komprimierungsgeschwindigkeit einher und umgekehrt. Das Gleichgewicht zwischen Komprimierungsverhältnis und Geschwindigkeit wird durch die Komprimierungsebene gesteuert. Die Komprimierungsebenen von iiszlib.dll, iisbrotli.dll und gzip.dll in Bezug auf Bereich, Komprimierungsverhältnis und Geschwindigkeit stimmen nicht miteinander überein. Der Vergleich der zulässigen Komprimierungsebenen der drei Komprimierungsverfahrenanbieter ist in der folgenden Tabelle zusammengefasst.

Komprimierungsverfahrenanbieter	Komprimierungsebene: Keine Komprimierung	Komprimierungsebene: Beste Geschwindigkeit	Komprimierungsebene: Bestes Komprimierungsverhältnis
gzip.dll	N/V	0	10
iiszlib.dll	0	1	9
iisbrotli.dll	N/V	0	11

Hinweis

Ebene 0 von iiszlib.dll gibt keine Komprimierung an, sondern nur eine Komprimierung mit der besten Geschwindigkeit. Der standardmäßige IIS-Attributwert dynamicCompressionLevel im <httpCompression>-Element ist ebenfalls 0. Daher muss dynamicCompressionLevel explizit über 0 festgelegt werden, damit iiszlib.dll dynamisch generierte Inhalte komprimieren kann.

Priorisierung des Komprimierungsverfahrens

HTTP-Komprimierungsverfahrensverhandlung

Die Komprimierungsverfahrensverhandlung zwischen Benutzer-Agents und IIS-Servern entspricht der RFC-Spezifikation (Requests For Comment) 7231:

1. Die Verhandlung beginnt damit, dass der Benutzer-Agent die Liste der zulässigen Komprimierungsverfahren im Accept-Encoding-Anforderungsheader angibt.

2. Der Server untersucht den Accept-Encoding-Header in der Anforderung und wählt ein vom Server unterstütztes Verfahren aus.

3. Der Server wendet den entsprechenden Algorithmus an, um den Antworttext zu komprimieren.

4. Wenn der Server die Antwort zurücksendet, fügt er den Inhaltscodierungsantwortheader mit dem ausgewählten Komprimierungsverfahren als Headerwert hinzu.

5. Der Benutzer-Agent verwendet das im Inhaltscodierung-Antwortheader angegebene Verfahren, um den Antworttext zu dekomprimieren und den ursprünglichen Inhalt für den Benutzer zu rendern.

Aktivieren mehrerer Komprimierungsverfahren

Eine der wichtigsten Ideen hinter der Aushandlung von HTTP-Komprimierungsverfahren ist die Möglichkeit, neue Komprimierungsverfahren zu unterstützen und gleichzeitig die Abwärtskompatibilität mit alten Clients oder Servern zu wahren.

Während Brotli-Komprimierung den Vorteil eines höheren Komprimierungsverhältnisses bietet und von vielen Browsern unterstützt wurde, ist es zum Zeitpunkt des Schreibens immer noch nicht so weit verbreitet wie Gzip. Daher besteht eine mögliche Optimierung darin, sowohl Brotli- als auch Gzip-Komprimierung zu aktivieren, aber Brotli zu priorisieren, wenn der clientseitige Benutzer-Agent es ebenfalls unterstützt.

IIS 10.0 Version 1803 oder höher

Die Priorisierung des Komprimierungsverfahrens wird in IIS 10.0 Version 1803 oder höher unterstützt. Die Priorität jedes Komprimierungsverfahrens wird durch seine Reihenfolge in der <scheme>-Auflistung des <httpCompression>-Elements bestimmt:

• Ein Komprimierungsverfahren, das oben in der <scheme>-Auflistung angezeigt wird, wird vor dem angezeigten Verfahren priorisiert, wenn die im Accept-Encoding- Anforderungsheaderwert angegebenen Qualitätswerte identisch sind.
• Ein Komprimierungsverfahren mit einem höheren Qualitätswert im Header der Accept-Encoding-Anforderung hat Vorrang vor einem Verfahren mit einem niedrigeren Qualitätswert, unabhängig von ihrer Reihenfolge in der <scheme>-Sammlung.

Die Installation der IIS-Komprimierung registriert iisbrotli.dll und iiszlib.dll als br- bzw gzip-Komprimierungsverfahrensanbieter und platziert br vor gzip in der <scheme>-Sammlung:

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

Mit dieser Konfigurationsreihenfolge kann der IIS-Server Brotli über Gzip priorisieren, wenn die meisten Browser, die Brotli unterstützen, Accept-Encoding: gzip, deflate, br für die Komprimierungsverfahrensverhandlung verwenden.

Hinweis

Die Browser, die die Brotli-Komprimierung unterstützen, geben br in der Regel nur im Accept-Encoding-Header-Wert an, wenn HTTPS verwendet wird.

Vor IIS 10.0 Version 1803

Obwohl IIS vor Version 10.0 Version 1803, die Aktivierung mehrerer Komprimierungsverfahren zulässt, wird das Komprimierungsverfahren auf der Grundlage der Reihenfolge des Verfahrens im Wert des Accept-Encoding-Anforderungsheader priorisiert:

• Ein Komprimierungsverfahren wird zuerst (von links nach rechts) im Headerwert der Accept-Encoding-Anforderung priorisiert, wenn sie dieselben Qualitätswerte aufweisen.
• Ein Komprimierungsverfahren mit höherem Qualitätswert wird unabhängig von der Reihenfolge im Headerwert der Accept-Encoding-Anforderung priorisiert.

Folglich bevorzugt IIS immer gzip gegenüber br für das typische Szenario, dass der Browser Accept-Encoding: gzip, deflate, br-Header in der Anforderung setzt.

Eine mögliche Problemumgehung besteht darin, das URL Rewrite-Modul zu installieren und eine Neuschreibregel zu konfigurieren, um den Accept-Encoding-Headerwert zu ändern. Die folgende Konfiguration zeigt eine Beispiel-Neuschreibregel, die den Accept-Encoding- Headerwert umschreibt, um nur br-Verfahren einzuschließen, wenn die Zeichenfolge br im Headerwert mit einem Wert ungleich Null gefunden wird.

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

Weitere Details zum Konfigurieren von Neuschreibregeln finden Sie in Erstellen von Neuschreibregeln für das URL Rewrite-Modul.

Testen der IIS-Komprimierung

Das Testen der IIS-Komprimierung kann wie folgt durchgeführt werden:

• Öffnen eines Browsers und Anfordern bestimmter Inhalte vom IIS-Server.
• Überprüfen der Anforderungen und Antworten über die Entwicklertools des Browsers.

So testen Sie die IIS-Komprimierung für statische Inhalte:

• Stellen Sie sicher, dass der MIME-Typ der angeforderten Ressource in der <staticTypes>-Auflistung im <httpCompression>-Element aktiviert ist.
• Stellen Sie sicher, dass die angeforderte Ressourcengröße größer ist als minFileSizeForComp im <httpCompression>-Element angegeben.
• Stellen Sie sicher, dass der Schwellenwert für die angeforderte URL erreicht ist. Der Schwellenwert wird durch die frequentHitThreshold- und frequentHitTimePeriod-Attribute des <serverRuntime>-Elements angegeben. Legen Sie alternativ den Wert des staticCompressionIgnoreHitFrequency-Attributs im <httpCompression>-Element als true fest, sodass die Überprüfung „Trefferhäufigkeit“ nur zu Testzwecken deaktiviert wird.

So testen Sie die IIS-Komprimierung für dynamische Inhaltskomprimierung:

• Stellen Sie sicher, dass der MIME-Typ der angeforderten Ressource in der <dynamicTypes>-Auflistung im <httpCompression>-Element aktiviert ist.