Hashes und ETags: Best Practices

Bei Cloud Storage können Nutzer die Daten, die sie an ihren Bucket übertragen oder von diesem erhalten, mithilfe der CRC32C- oder MD5-Prüfsummen validieren. In diesem Abschnitt sind Best Practices für die Durchführung dieser Validierungen beschrieben.

Integritätsprüfung mit Hashes

Es gibt eine Vielzahl von Möglichkeiten, wie Daten beim Hochladen in die Cloud oder beim Herunterladen beschädigt werden können:

  • Fehler während der Netzwerkübertragung
  • Fehler im Arbeitsspeicher des Client- oder Servercomputers oder eines Routers entlang des Pfads
  • Softwarefehler, z. B. in einer von den Kunden verwendeten Bibliothek

Damit die Daten vor einer Beschädigung geschützt sind, unterstützt Cloud Storage zwei Arten von Hashes: CRC32C und MD5 (siehe unten). Google empfiehlt Kunden, in allen Fällen CRC32C zu verwenden, wie unten im Abschnitt "Validierung" erläutert. Kunden, die MD5 bevorzugen, können diesen Hash verwenden, er wird jedoch nicht für zusammengesetzte Objekte unterstützt.

CRC32C

Alle Cloud Storage-Objekte haben einen CRC32C-Hash. CRC32C ist eine zyklische 32-Bit-Redundanzprüfung (Cyclic Redundancy Check, CRC) auf Grundlage eines Castagnoli-Polynoms. Dieser CRC wird durch die IETF-Spezifikation für SCTP beschrieben. Zu den Bibliotheken für die Berechnung von CRC32C gehören unter anderem CRC32C von Google und Boost für C++, crcmod für Python und digest-crc für Ruby. Java-Nutzer finden im Google Cloud Platform-CRC32C-Java-Projekt eine Implementierung des Algorithmus.

Der base64-codierte CRC32C wird in der Big-Endian-Bytereihenfolge angeordnet.

MD5

Cloud Storage unterstützt einen MD5-Hash für nicht zusammengesetzte Objekte. Dieser Hash gilt nur für ein vollständiges Objekt. Bei GET-Anfragen mit Anfragebereich kann er deshalb nicht für die Integritätsprüfung von Teil-Downloads verwendet werden.

ETags

Bisher wurde der MD5 eines Objekts über einen ETag-Header ausgedrückt. Dieses Verhalten bleibt für nicht zusammengesetzte Objekte in der XML API unverändert. Da zusammengesetzte Objekte die MD5-Hashes jedoch nicht unterstützen, sollten Nutzer keine Annahmen über diese ETags anstellen, außer dass sie sich gemäß den Spezifikationen immer ändern, wenn sich die zugrunde liegenden Daten ändern.

Validierung

Die Integritätsprüfung eines Downloads kann erfolgen, indem heruntergeladene Daten in einen Hash umgewandelt und Ihre Ergebnisse mit Hashes verglichen werden, die der Server bereitstellt. Sie sollten heruntergeladene Daten mit falschen Hash-Werten verwerfen und eine Wiederholungslogik verwenden, um potenziell teure Endlosschleifen zu vermeiden.

Cloud Storage unterstützt die serverseitige Validierung von Uploads. Die clientseitige Validierung ist aber ebenfalls ein geläufiger Ansatz. Wenn Ihre Anwendung den MD5 oder CRC32C des Objekts bereits vor Beginn des Uploads berechnet hat, können Sie diesen zusammen mit der Uploadanfrage angeben. Cloud Storage erstellt das Objekt nur, wenn der Hash, den Sie angegeben haben, dem von uns berechneten Wert entspricht.

Alternativ können Nutzer eine clientseitige Validierung durchführen, indem sie eine Anfrage für die Metadaten des neuen Objekts stellen, sodass ein Abgleich mit dem gemeldeten Hash-Wert erfolgt und das Objekt im Fall einer Nichtübereinstimmung gelöscht wird. Zur Vermeidung von Race-Bedingungen, bei denen unabhängige Prozesse gegenseitig ihre Daten löschen oder überschreiben, empfehlen wir Ihnen außerdem die Verwendung von Objektgenerierungen und Vorbedingungen.

Bei parallelen Uploads unter Verwendung von zusammengesetzten Objekten sollten Nutzer für jede Komponente eine Integritätsprüfung durchführen und anschließend bei ihren Zusammensetzungsanfragen Vorbedingungen für die Komponenten verwenden, um diese vor Race-Bedingungen zu schützen. Die Objektzusammensetzung ermöglicht keine serverseitige MD5-Validierung. Nutzer, die eine End-to-End-Integritätsprüfung durchführen möchten, sollten deshalb eine clientseitige Validierung für das neue zusammengesetzte Objekt verwenden.

Am Ende des jeweiligen Kopiervorgangs wird mit den gsutil-Befehlen cp und rsync überprüft, ob die Prüfsumme der lokalen Datei der Prüfsumme des Objekts entspricht, das in Cloud Storage gespeichert ist. Ist dies nicht der Fall, wird die ungültige Kopie durch gsutil gelöscht und eine Warnmeldung ausgegeben. Dies geschieht nur sehr selten. Sollte dieser Fall eintreten, können Sie versuchen, den Vorgang zu wiederholen.

XML API

In der XML API werden base64-codierte MD5- und CRC32C-Hashes über den Header x-goog-hash veröffentlicht und akzeptiert. In der Vergangenheit wurden MD5-Hashes als Objekt-ETags verwendet. Nutzer sollten jedoch nicht davon ausgehen, weil zusammengesetzte Objekte intransparente ETag-Werte verwenden, die keine Garantien bieten, abgesehen davon, dass sie sich bei Veränderungen am Objekt ändern.

Die serverseitige Validierung von Uploads kann durch die Bereitstellung lokal berechneter Hashes über den Anfrage-Header x-goog-hash erfolgen. Außerdem kann der MD5 mithilfe des standardmäßigen HTTP-Headers Content-MD5 bereitgestellt werden (siehe Spezifikation).

JSON API

In der JSON API enthalten die Objektressourcen-Attribute md5Hash und crc32c jeweils einen base64-codierten MD5- bzw. CRC32C-Hash. Die Bereitstellung dieser Metadatenattribute ist optional. Werden die Attribute beim Einfügen eines Objekts nicht bereitgestellt, berechnet Cloud Storage die Werte und schreibt sie in die Metadaten des Objekts. Die Bereitstellung eines dieser Attribute bei einer Anfrage zum Einfügen löst eine serverseitige Validierung für das neue Objekt aus. Wenn Cloud Storage für ein Attribut einen Wert berechnet, der nicht dem angegebenen Wert entspricht, wird das Objekt nicht erstellt. Bei fortsetzbaren und aus mehreren Teilen bestehenden Uploads verwenden Sie die Attribute md5Hash und crc32c genauso wie beim Einfügen eines einzelnen Objekts.

Hat Ihnen diese Seite weitergeholfen? Teilen Sie uns Ihr Feedback mit:

Feedback geben zu...