Hashes und ETags: Best Practices

Mit Cloud Storage können Sie die Daten validieren, die Sie zu und aus Ihren Buckets übertragen. Auf dieser Seite werden Best Practices für Validierungen mit CRC32C- oder MD5-Prüfsummen erläutert.

Vor Datenbeschädigung durch Hashes schützen

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

• Fehler im Arbeitsspeicher des Client- oder Servercomputers oder eines Routers entlang des Pfads
• Softwarefehler, z. B. in einer von den Kunden verwendeten Bibliothek
• Änderungen an der Quelldatei, wenn ein Upload über einen längeren Zeitraum erfolgt

Cloud Storage unterstützt zwei Arten von Hashes, mit denen Sie die Integrität Ihrer Daten prüfen können: CRC32C und MD5. CRC32C ist die empfohlene Validierungsmethode für Integritätsprüfungen. Kunden, die MD5 bevorzugen, können diesen Hash jederzeit verwenden. MD5-Hashes werden aber nicht für zusammengesetzte Objekte und nicht für Objekte unterstützt, die aus einem mehrteiligen XML API-Upload erstellt wurden.

Achtung: Die Prüfsummen, die beim Herunterladen von Daten aus Cloud Storage zurückgegeben werden, beziehen sich auf den gesamten Objektinhalt. Wenn Sie einen Anfragebereich festlegen, ist es daher unmöglich, eine Beschädigung der Daten nur für diesen Bytebereich zu erkennen. Für Cloud Storage wird deshalb empfohlen, Anfragebereiche nur für den Neustart des Downloads eines kompletten Objekts nach dem letzten erhaltenen Versatz zu verwenden. In diesem Fall können Sie die Prüfsumme berechnen und validieren, wenn der vollständige Download abgeschlossen ist.

CRC32C

Alle Cloud Storage-Objekte haben einen CRC32C-Hash. Zu den Bibliotheken für die Berechnung von CRC32C gehören:

• CRC32C von Google für C++.
• hash/crc32 für Go
• Google APIs Guava für Java
• google-crc32c für Python
• digest-crc für Ruby

Hinweis: Der CRC, der allgemein als CRC32 bekannt ist, unterscheidet sich vom CRC32C-Algorithmus, der von Cloud Storage verwendet wird.

Der mit Base64 codierte CRC32C wird in Big-Endian-Bytereihenfolge angeordnet.

MD5

Cloud Storage unterstützt einen MD5-Hash für Objekte, die die folgenden Kriterien erfüllen:

• Das Objekt ist kein zusammengesetztes Objekt
• Das Objekt wurde nicht mit einem mehrteiligen XML API-Upload hochgeladen.

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

Der ETag-Header eines Objekts gibt den MD5-Wert des Objekts zurück, wenn alle folgenden Bedingungen erfüllt sind:

• Die Anfrage wird über die XML API gesendet.
• Das Objekt verwendet nur von Google verwaltete Verschlüsselungsschlüssel für die serverseitige Verschlüsselung.
• Das Objekt ist kein zusammengesetztes Objekt und wurde nicht mit einem mehrteiligen XML API-Upload hochgeladen.

In allen anderen Fällen sollten Nutzer keine Annahmen über den in einem ETag verwendeten Wert treffen, es sei denn, er ändert sich, wenn sich die zugrunde liegenden Daten oder Metadaten gemäß der Spezifikation ändern.

Dasselbe Objekt kann einen anderen ETag-Wert haben, wenn es von der XML API im Vergleich zur JSON API angefordert wird.

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.

In folgenden Fällen führt Cloud Storage eine serverseitige Validierung durch:

• Wenn Sie eine Kopier- oder Umschreibungsanfrage in Cloud Storage ausführen.

• Wenn Sie den erwarteten MD5- oder CRC32C-Hash eines Objekts in einer Uploadanfrage angeben. Cloud Storage erstellt das Objekt nur, wenn der Hash mit dem Wert übereinstimmt, den Cloud Storage berechnet. Wenn es nicht übereinstimmt, wird die Anfrage mit dem Fehler BadRequestException: 400 abgelehnt.

Alternativ können Nutzer eine clientseitige Validierung ihrer Uploads durchführen, indem sie eine Anfrage für die Metadaten des hochgeladenen Objekts stellen, sodass ein Abgleich mit dem gemeldeten Hash-Wert erfolgt und das Objekt im Fall einer Nichtübereinstimmung gelöscht wird. Diese Methode ist nützlich, wenn der MD5- oder CRC32C-Hash des Objekts nicht zu Beginn des Uploads bekannt ist. Zur Vermeidung von Race-Bedingungen, bei denen voneinander unabhängige Prozesse gegenseitig ihre Daten löschen oder ersetzen, sollten Sie Objektgenerierungen und Vorbedingungen verwenden.

Bei parallelen zusammengesetzten Uploads sollten Nutzer für den Upload jeder 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.

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 manche Objekte intransparente ETag-Werte verwenden, die keine Garantien bieten, abgesehen davon, dass sie sich bei Veränderungen am Objekt ändern.

Die serverseitige Upload-Validierung 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. Wenn Sie eines der beiden Attribute im Rahmen eines fortsetzbaren Uploads oder JSON API-Mehrteiligen Uploads angeben, wird eine serverseitige Validierung für das neue Objekt ausgelöst. Wenn Cloud Storage für ein Attribut einen Wert berechnet, der nicht dem angegebenen Wert entspricht, wird das Objekt nicht erstellt. Werden die Attribute beim Hochladen eines Objekts nicht bereitgestellt, berechnet Cloud Storage die Werte und schreibt sie in die Metadaten des Objekts.

gcloud storage und gsutil

Sowohl für das gcloud storage- als auch für das gsutil-Befehlszeilentool werden Daten, die in oder aus einem Cloud Storage-Bucket kopiert werden, validiert. Dies gilt für die Befehle cp, mv und rsync. Wenn die Prüfsumme der Quelldaten nicht mit der Prüfsumme der Zieldaten übereinstimmt, löschen die Tools die ungültige Kopie und geben eine Warnmeldung aus. Dies geschieht nur sehr selten. Sollte dieser Fall eintreten, sollten Sie versuchen, den Vorgang zu wiederholen.

Bei beiden Befehlszeilen erfolgt diese automatische Validierung nach Abschluss des Objekts selbst. Daher sind ungültige Objekte ein bis drei Sekunden lang sichtbar, bevor sie identifiziert und gelöscht werden. Außerdem kann es vorkommen, dass die Tools nach dem Upload unterbrochen werden, bevor sie jedoch validiert werden. Das ungültige Objekt bleibt also bestehen. Diese Probleme können beim Hochladen einzelner Dateien in Cloud Storage mithilfe der serverseitigen Validierung vermieden werden. Diese tritt auf, wenn folgende Flags verwendet werden:

• Verwenden Sie für gcloud storage das Flag --content-md5=MD5.
• Verwenden Sie für gsutil das Flag -h Content-MD5:MD5.

Hinweis: Diese Flags werden ignoriert, wenn Objekte nur eine CRC32C-Prüfsumme haben, z. B. zusammengesetzte Objekte oder Objekte, die aus einem mehrteiligen XML API-Upload erstellt wurden.

Nächste Schritte

• Upload- und Downloadoptionen für Cloud Storage
• Wiederholungsstrategien für Cloud Storage