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.

Cloud Storage unterstützt keine dekomprimierende Transcodierung für Brotli-komprimierte Objekte.

Dekomprimierende Transcodierung

Mit der dekomprimierenden Transcodierung können Sie komprimierte Versionen von Dateien in Cloud Storage speichern. So werden inaktive Speicherkosten reduziert und die Datei wird trotzdem ohne Komprimierung an den Anfragenden gesendet. Dies ist zum Beispiel nützlich, wenn Sie Dateien an Kunden senden.

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

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

  2. Die Metadaten des Objekts enthalten Content-Encoding: gzip.

Wenn ein Objekt diese beiden Kriterien erfüllt, wird es bei der Bereitstellung einer dekomprimierenden Transcodierung unterzogen und die Antwort, die das Objekt enthält, enthält keinen Content-Encoding- oder Content-Length-Header.

Es gibt zwei Möglichkeiten, die dekomprimierende Transcodierung für ein Objekt zu verhindern, das ansonsten qualifiziert ist:

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

Eine dekomprimierende Transcodierung ist beispielsweise hilfreich, wenn Sie die Kosten für die ausgehende Datenübertragung oder die Zeit reduzieren möchten oder wenn Sie die heruntergeladenen Objekte auf die erwarteten crc32c/md5-Prüfsummen prüfen möchten.

Hinweise

Beachten Sie bei der Arbeit mit der dekomprimierenden Transcodierung Folgendes:

  • Dekomprimierende Transcodierung macht die Integritätsprüfung für in der Antwort zurückgegebene Daten ungültig. Das liegt daran, dass der mit einem Objekt gespeicherte Hash die Daten in dem komprimierten Zustand darstellt, während die bereitgestellten Daten ohne Komprimierung gesendet wurden und daher ein anderer Hash-Wert vorhanden ist. Wenn die Sender von Anfragen nach Ihren Daten auf die Prüfsumme für die Integritätsprüfung bestehen, sollten Sie keine dekomprimierende Transcodierung verwenden.

  • Mit der dekomprimierenden Transcodierung können Sie Objekte in Cloud Storage komprimiert speichern, um Speicherplatz und Kosten zu sparen. Die Gebühren für das Herunterladen des Objekts richten sich jedoch nach der dekomprimierten Größe, da es sich um die Größe des bereitgestellten Objekts handelt.

  • Wenn von einem von Cloud Storage FUSE bereitgestellten Bucket aus auf Objekte zugegriffen wird, durchlaufen diese Objekte keine dekomprimierenden Transcodierungen und werden als komprimiert gelesen.

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 bei der Einrichtung 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 „doppelt komprimierte“ Objekte (d. h. Objekte, die mit GZIP komprimiert sind, aber auch einen zugrunde liegenden Content-Type haben, der selbst komprimiert ist) zwar 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. Die vom Client empfangene Datei hat daher nicht dieselbe Prüfsumme wie das in Cloud Storage hochgeladene und gespeicherte Objekt, sodass alle Integritätsprüfungen fehlschlagen.

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.

Weitere Informationen