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.

CRC32C

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

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:

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:

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

Google Cloud CLI

Für die Google Cloud CLI werden Daten validiert, die in einen oder aus einem Cloud Storage-Bucket kopiert wurden. 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öscht die gcloud CLI die ungültige Kopie und gibt eine Warnmeldung aus. Dies geschieht nur sehr selten. Sollte dieser Fall eintreten, sollten Sie versuchen, den Vorgang zu wiederholen.

Diese automatische Validierung erfolgt nach Abschluss des Objekts selbst, sodass ungültige Objekte 1 bis 3 Sekunden lang sichtbar sind, bevor sie identifiziert und gelöscht werden. Außerdem kann es vorkommen, dass die gcloud CLI nach Abschluss des Uploads, aber vor der Validierung unterbrochen wird, wodurch das ungültige Objekt beibehalten wird. Diese Probleme können beim Hochladen einzelner Dateien in Cloud Storage mithilfe der serverseitigen Validierung vermieden werden. Diese tritt bei Verwendung des Flags --content-md5=MD5 auf.

Nächste Schritte