Kompression in HTTP

Kompression ist eine wichtige Methode, um die Leistung einer Website zu erhöhen. Bei einigen Dokumenten senkt eine Größenreduktion von bis zu 70 % den Bandbreitenbedarf erheblich. Im Laufe der Jahre wurden Algorithmen effizienter, und neue werden von Clients und Servern unterstützt.

In der Praxis müssen Webentwickler keine Kompressionsmechanismen implementieren, da sowohl Browser als auch Server diese bereits integriert haben. Sie müssen jedoch sicherstellen, dass der Server richtig konfiguriert ist. Kompression erfolgt auf drei verschiedenen Ebenen:

  • Zuerst werden einige Dateiformate mit spezifisch optimierten Methoden komprimiert,
  • dann kann eine allgemeine Kompression auf HTTP-Ebene stattfinden (die Ressource wird komprimiert von Ende zu Ende übertragen),
  • und schließlich kann die Kompression auf der Verbindungsebene zwischen zwei Knoten einer HTTP-Verbindung definiert werden.

Dateiformat-Kompression

Jeder Datentyp enthält eine gewisse Redundanz, also verschwendeten Platz. Während Text typischerweise bis zu 60 % Redundanz aufweisen kann, kann diese Rate bei anderen Medien wie Audio und Video noch höher sein. Anders als Text verwenden diese anderen Medientypen viel Platz, um ihre Daten zu speichern, und der Bedarf zur Optimierung von Speicherplatz wurde sehr früh erkannt. Ingenieure entwickelten den optimierten Kompressionsalgorithmus, der für Dateiformate entwickelt wurde, die speziell für diesen Zweck konzipiert sind. Kompressionsalgorithmen für Dateien können in zwei Hauptkategorien unterteilt werden:

  • Verlustfreie Kompression, bei der der Kompressions-Dekompressionszyklus die wiederhergestellten Daten nicht verändert. Diese entsprechen (Byte für Byte) den Originaldaten. Für Bilder verwenden gif oder png verlustfreie Kompression.
  • Verlustbehaftete Kompression, bei welcher der Zyklus die Originaldaten auf eine (hoffentlich) für den Benutzer unmerkliche Weise verändert. Videoformate im Web sind verlustbehaftet; auch das jpeg-Bildformat ist verlustbehaftet.

Einige Formate können sowohl für verlustfreie als auch für verlustbehaftete Kompression verwendet werden, wie webp, und in der Regel kann der verlustbehaftete Algorithmus so konfiguriert werden, dass mehr oder weniger stark komprimiert wird, was natürlich zu einer geringeren oder höheren Qualität führt. Für eine bessere Leistung einer Website ist es ideal, so viel wie möglich zu komprimieren und dabei ein akzeptables Qualitätsniveau beizubehalten. Bei Bildern kann es vorkommen, dass ein mit einem Werkzeug generiertes Bild nicht ausreichend für das Web optimiert ist. Es wird empfohlen, Werkzeuge zu verwenden, die so viel wie möglich mit der erforderlichen Qualität komprimieren. Es gibt zahlreiche Werkzeuge, die darauf spezialisiert sind.

Verlustbehaftete Kompressionsalgorithmen sind in der Regel effizienter als verlustfreie.

Hinweis: Da die Kompression bei einer bestimmten Art von Dateien besser funktioniert, bringt es in der Regel nichts, sie ein zweites Mal zu komprimieren. Tatsächlich kann dies oft kontraproduktiv sein, da die Kosten für den Overhead (Algorithmen benötigen in der Regel ein Wörterbuch, das zur ursprünglichen Größe hinzufügt) höher sein können als der zusätzliche Gewinn durch die Kompression, was zu einer größeren Datei führt. Verwenden Sie die beiden folgenden Techniken nicht für Dateien in einem komprimierten Format.

End-to-End-Kompression

Bei der Kompression liegen die größten Leistungsverbesserungen von Websites in der End-to-End-Kompression. End-to-End-Kompression bezieht sich auf eine Kompression des Nachrichtentextes, die vom Server vorgenommen wird und unverändert bleibt, bis sie den Client erreicht. Welche Zwischenknoten auch immer vorhanden sind, sie lassen den Text unberührt.

Ein Server sendet einen komprimierten HTTP-Text an einen Client über Netzwerkknoten. Der Text wird an keinem Übergang im Netzwerk dekomprimiert, bis er den Client erreicht.

Alle modernen Browser und Server unterstützen dies, und das Einzige, was zu verhandeln ist, ist der zu verwendende Kompressionsalgorithmus. Diese Algorithmen sind für Text optimiert. In den 1990er Jahren entwickelte sich die Kompressionstechnologie rasant, und viele aufeinanderfolgende Algorithmen wurden zu den möglichen Optionen hinzugefügt. Heutzutage sind nur zwei relevant: gzip, der häufigste Algorithmus, und br, der neue Herausforderer.

Um den Algorithmus auszuwählen, verwenden Browser und Server die proaktive Inhaltsaushandlung. Der Browser sendet einen Accept-Encoding-Header mit den von ihm unterstützten Algorithmen und deren Prioritätsreihenfolge; der Server wählt einen aus, verwendet ihn, um den Text der Antwort zu komprimieren, und verwendet den Content-Encoding-Header, um dem Browser mitzuteilen, welchen Algorithmus er ausgewählt hat. Da die Inhaltsaushandlung verwendet wurde, um eine Darstellung basierend auf ihrer Kodierung auszuwählen, muss der Server einen Vary-Header senden, der mindestens Accept-Encoding zusammen mit diesem Header in der Antwort enthält; so können Caches die unterschiedlichen Darstellungen der Ressource zwischenspeichern.

Ein Client fordert Inhalte mit einem 'Accept-Encoding: br, gzip'-Header an. Der Server antwortet mit einem Text, der mit dem Brotli-Algorithmus komprimiert wurde, und den erforderlichen 'Content-Encoding'- und 'Vary'-Headers.

Da Kompression erhebliche Leistungsverbesserungen mit sich bringt, wird empfohlen, sie für alle Dateien außer bereits komprimierten wie Bildern, Audiodateien und Videos zu aktivieren.

Apache unterstützt Kompression und verwendet mod_deflate; für Nginx gibt es ngx_http_gzip_module; für IIS das <httpCompression>-Element.

Hop-by-Hop-Kompression

Hop-by-Hop-Kompression, obwohl ähnlich zur End-to-End-Kompression, unterscheidet sich durch ein grundlegendes Element: Die Kompression erfolgt nicht auf der Ressource im Server, wodurch eine spezifische Darstellung erstellt wird, die dann übertragen wird, sondern auf dem Nachrichtentext zwischen zwei beliebigen Knoten auf dem Pfad zwischen Client und Server. Verbindungen zwischen aufeinanderfolgenden Zwischenknoten können eine andere Kompression anwenden.

Ein Server sendet einen unkomprimierten HTTP-Text an einen Client über Netzwerkknoten. Der Text wird von Knoten im Netzwerk abhängig von 'Transfer-Encoding'-Headers komprimiert und dekomprimiert, bevor er den Client erreicht.

Dazu verwendet HTTP einen Mechanismus ähnlich der Inhaltsaushandlung für die End-to-End-Kompression: Der Knoten, der die Anfrage überträgt, gibt mit dem TE-Header seine Absicht bekannt, und der andere Knoten wählt die geeignete Methode, wendet sie an und zeigt seine Wahl mit dem Transfer-Encoding-Header an.

Ein Client fordert Inhalte von einem Server ohne kompressionsbezogene Headers an. Der Server antwortet mit einem unkomprimierten Text. Der Text wird von Knoten im Netzwerk komprimiert und dekomprimiert, bevor er den Client erreicht.

In der Praxis ist die Hop-by-Hop-Kompression für den Server und den Client transparent und wird selten verwendet. TE und Transfer-Encoding werden hauptsächlich verwendet, um eine Antwort in Teilen zu senden, was es ermöglicht, mit der Übertragung einer Ressource zu beginnen, ohne deren Länge zu kennen.

Beachten Sie, dass die Verwendung von Transfer-Encoding und Kompression auf Hoplevel so selten ist, dass die meisten Server, wie Apache, Nginx oder IIS, keine einfache Möglichkeit haben, dies zu konfigurieren. Solche Konfigurationen erfolgen in der Regel auf Proxyebene.

Siehe auch