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:
Die in Cloud Storage gespeicherte Datei ist mit GZIP komprimiert.
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 einemContent-Encoding: gzip
-Antwortheader gesendet.Wenn das Metadatenfeld
Cache-Control
für das Objekt aufno-transform
gesetzt ist, wird das Objekt bei allen nachfolgenden Anfragen komprimiert gesendet, unabhängig vomAccept-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
Beachte bei der Arbeit mit dekomprimierendem Transcodieren Folgendes:
Dekomprimierende Transcodierung macht die Integritätsprüfung ungültig. 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 komprimiert in Cloud Storage 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 auchContent-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 KEINContent-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 wennContent-Encoding
festgelegt ist. Sonst wird eventuell ein Standardwert fürContent-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
- Informationen zum Flag
--gzip-local
bei Verwendung vongcloud storage cp
, mit dem die GZIP-Inhaltscodierung auf Dateiuploads angewendet wird - Objektmetadaten ansehen und bearbeiten