Mit GZIP komprimierte Dateien transcodieren

Auf dieser Seite wird das Komprimieren und Dekomprimieren von Dateien mit GZIP erklärt. Hier finden Sie einen Überblick über die Transcodierung, Best Practices für die Arbeit mit zugehörigen Metadaten sowie Informationen zum Verhalten von komprimierten Dateien in Cloud Storage.

Transcodierung und GZIP

GZIP dient der Datenkomprimierung: Damit wird normalerweise die Größe einer Datei reduziert. So kann sie schneller übertragen werden und benötigt weniger Speicherplatz, als wenn sie nicht komprimiert wäre. Durch das Komprimieren von Dateien sparen Sie sowohl Kosten als auch Übertragungszeit. Die Transcodierung in Cloud Storage sorgt für eine automatische Änderung der Komprimierung einer Datei, bevor sie an einen Anfragenden gesendet wird. Wenn durch die Transcodierung eine Datei entsteht, die mit GZIP komprimiert ist, gilt sie als komprimierend. Wenn dagegen eine Datei entsteht, die nicht mehr mit GZIP komprimiert ist, gilt sie als dekomprimierend. Cloud Storage unterstützt die dekomprimierende Form der Transcodierung.

Dekomprimierende Transcodierung

Dateien, die als mit GZIP komprimierte Objekte in Cloud Storage gespeichert sind, können automatisch dekomprimiert werden, bevor sie an einen Anfragenden gesendet werden. So entstehen Dateien, die mit einer Identität verschlüsselt (d. h. nicht komprimiert) sind. Dies sorgt für geringere Objektspeicherkosten in Cloud Storage. Der Anfragende erhält aber die unkomprimierte Datei. Dies ist zum Beispiel nützlich, wenn Sie Dateien an Kunden senden.

Für die dekomprimierende Transcodierung muss ein Objekt zwei Kriterien erfüllen:

  1. Die in Cloud Storage gespeicherte Datei ist mit GZIP komprimiert.

  2. Die zugehörigen Metadaten enthalten Content-Encoding: gzip.

Ein Objekt, das diese beiden Kriterien erfüllt, wird bei einer Anfrage einer dekomprimierenden Transcodierung unterzogen und dann auch ohne einen Content-Encoding-Header gesendet. Wenn Sie dagegen ein Objekt, das beide Kriterien erfüllt, komprimiert senden möchten (beispielsweise um die Kosten oder den Zeitaufwand für den Ausgang zu reduzieren), gibt es zwei Möglichkeiten, die dekomprimierende Transcodierung zu verhindern:

  • Wenn die Anfrage für das Objekt einen Accept-Encoding: gzip-Header enthält, wird das Objekt für diese Anfrage unverändert zusammen mit einem Content-Encoding: gzip-Antwortheader gesendet.

  • Wenn das Metadatenfeld Cache-Control für das Objekt auf no-transform gesetzt ist, wird das Objekt bei allen nachfolgenden Anfragen komprimiert gesendet, unabhängig vom Accept-Encoding-Anfrageheader.

Content-Type und Content-Encoding

Über die Auswirkungen von Content-Type und Content-Encoding bei der Transcodierung sollten Sie Verschiedenes wissen. Beides sind zusammen mit einem Objekt gespeicherte Metadaten. Im Kapitel Objektmetadaten ansehen und bearbeiten finden Sie eine detaillierte Anleitung, wie Sie Metadaten zu Objekten hinzufügen.

Content-Type muss in allen Uploads enthalten sein. Damit wird der Typ des hochgeladenen Objekts angegeben. Beispiel:

Content-Type: text/plain

In diesem Fall ist das hochgeladene Objekt eine Nur-Text-Datei. Es gibt zwar keine Möglichkeit zu prüfen, ob der angegebene Content-Type tatsächlich dem hochgeladenen Objekt entspricht, aber eine falsche Typangabe führt im besten Fall dazu, dass der Anfragende etwas anderes bekommt, als er erwartet hatte, und im schlechtesten Fall zu unerwünschtem Verhalten.

Content-Encoding ist optional und kann bei Bedarf in den Upload komprimierter Dateien eingefügt werden. Beispiel:

Content-Encoding: gzip

In diesem Fall ist das hochgeladene Objekt mit GZIP komprimiert. Wie bei Content-Type gibt es auch hier keine Möglichkeit zu prüfen, ob die Content-Encoding-Angabe tatsächlich auf das hochgeladene Objekt angewendet wird. Eine falsche Angabe der Objektcodierung kann jedoch zu unerwünschtem Verhalten bei nachfolgenden Downloadanfragen führen.

Bewährte Vorgehensweisen

  • Für das Hochladen eines mit GZIP komprimierten Objekts wird empfohlen, sowohl Content-Type als auch Content-Encoding in den Metadaten anzugeben. Für eine komprimierte Nur-Text-Datei würde das beispielsweise so aussehen:

    Content-Type: text/plain
    Content-Encoding: gzip
    

    Dadurch werden während des Zugriffs so viele Informationen wie möglich über den Zustand des Objekts geliefert. Außerdem eignet sich das Objekt beim Herunterladen auch für die dekomprimierende Transcodierung. So können Clientanwendungen die Content-Type-Semantik korrekt verarbeiten.

  • Alternativ haben Sie die Möglichkeit, das Objekt mit einem Content-Type hochzuladen, der die Komprimierung angibt und KEIN Content-Encoding. Beispiel:

    Content-Type: application/gzip
    

    In diesem Fall ist jedoch über das Objekt nur bekannt, dass es mit GZIP komprimiert ist. Informationen über den zugrunde liegenden Objekttyp stehen nicht zur Verfügung. Außerdem ist keine dekomprimierende Transcodierung möglich.

Nicht empfohlene Vorgehensweisen

  • Eine mit GZIP komprimierte Datei sollte nicht ohne Angabe der Komprimierung hochgeladen werden, auch wenn dies möglich ist. Bei einer mit GZIP komprimierten Nur-Text-Datei sollten Sie beispielsweise nicht nur Content-Type: text/plain festlegen. Dies würde dazu führen, dass der Status des Objekts beim Senden an einen Anfragenden falsch wiedergegeben wird.

  • Ebenso sollten Objekte nicht ohne Angabe des Content-Type hochgeladen werden, auch wenn Content-Encoding festgelegt ist. Sonst wird eventuell ein Standardwert für Content-Type verwendet und die Anfrage abgelehnt, je nachdem, wie der Upload vorgenommen wird.

Falsche Vorgehensweisen

  • Sie sollten beim Einrichten der Metadaten die Komprimierung des Objekts nicht redundant angeben:

    Content-Type: application/gzip
    Content-Encoding: gzip
    

    Diese Angabe bedeutet, dass Sie ein mit GZIP komprimiertes Objekt hochladen, das ein zweites Mal mit GZIP komprimiert wurde. In der Regel ist dies nicht der Fall. Wenn Sie tatsächlich eine Datei doppelt komprimieren möchten, lesen Sie weiter unten den Abschnitt GZIP für komprimierte Objekte verwenden. Wenn für ein solches falsch dargestelltes Objekt eine dekomprimierende Transcodierung durchgeführt wird, wird das Objekt mit einer Identität verschlüsselt gesendet, aber die Anfragenden gehen davon aus, dass sie ein Objekt empfangen haben, das immer noch komprimiert ist. Das Objekt lässt sich aber nicht dekomprimieren.

  • Ebenso sollte eine Datei, die nicht mit GZIP komprimiert ist, nicht mit Content-Encoding: gzip hochgeladen werden. Dadurch wird nämlich der Eindruck erweckt, dass eine Transcodierung möglich ist. Diese schlägt aber bei Objektanfragen fehl.

GZIP für komprimierte Objekte verwenden

Manche Objekte, darunter viele Video-, Audio- und Bilddateien sowie GZIP-Dateien selbst, sind bereits komprimiert. Diese mit GZIP zu komprimieren, bietet praktisch keine Vorteile. In fast allen Fällen werden Objekte dadurch aufgrund des GZIP-Aufwands größer. Aus diesem Grund wird die Verwendung von GZIP für komprimierte Daten generell nicht empfohlen, denn dies kann zu unerwünschtem Verhalten führen.

In Cloud Storage können zwar "doppelt komprimierte" Objekte (d. h. Objekte, die mit GZIP komprimiert sind, aber auch einen zugrunde liegenden Inhaltstyp haben, der selbst komprimiert ist) hochgeladen und gespeichert werden, aber Objekte dürfen nicht in einem doppelt komprimierten Zustand gesendet werden, es sei denn, ihre Cache-Control-Metadaten enthalten no-transform. Stattdessen werden die äußere GZIP-Komprimierung und der Content-Encoding-Antwortheader entfernt, bevor das Objekt gesendet wird. Dies gilt auch für Anfragen mit Accept-Encoding: gzip.

Range-Header verwenden

Wenn eine Objektanfrage einen Range-Header enthält, wird dieser bei der Transcodierung ignoriert. Dies bedeutet, dass Anfragen für Teilinhalte nicht erfüllt werden und die Antwort stattdessen das gesamte angefragte Objekt enthält. Wenn Sie beispielsweise ein 10 GB großes Objekt haben, das für eine Transcodierung geeignet ist, jedoch einen Range: bytes=0-10000-Header in der Anfrage hat, wird das Objekt dennoch in vollem Umfang zurückgegeben.

Dieses Verhalten tritt auf, weil es nicht möglich ist, einen Bereich aus einer komprimierten Datei auszuwählen, ohne zuerst die gesamte Datei zu dekomprimieren. Jede Anfrage für einen Teil einer Datei hätte eine Dekomprimierung der gesamten, möglicherweise großen Datei zur Folge, was zu einer schlechten Ressourcenauslastung führen würde. Sie sollten sich dessen bewusst sein und den Range-Header nicht zusammen mit der Transcodierung verwenden, da Gebühren für die Übertragung des gesamten Objekts und nicht nur des angefragten Bereichs anfallen. Weitere Informationen zu zulässigem Antwortverhalten auf Anfragen mit dem Header Range finden Sie in der Spezifikation.

Wenn Anfragen mit Range-Headern erforderlich sind, sollten Sie dafür sorgen, dass für das angefragte Objekt keine Transcodierung stattfindet. Dies erreichen Sie durch Auswählen geeigneter Attribute beim Hochladen von Objekten. Bereichsanfragen für Objekte mit Content-Type: application/gzip und ohne Content-Encoding werden beispielsweise wie gewünscht ausgeführt.

Nächste Schritte