Para validar la integridad de los datos y detectar cambios, Cloud Storage te recomienda que uses sumas de verificación cuando transfieras datos a tus buckets y desde ellos. En esta página, se proporciona información sobre cómo se usan las sumas de verificación en Cloud Storage y cómo especificarlas cuando se envían solicitudes.
Evita que se dañen los datos con sumas de verificación
A veces, los datos pueden dañarse mientras se transfieren a la nube o desde ella debido a errores de software o hardware, errores de memoria o de router, perturbaciones eléctricas o cambios en los datos de origen durante las cargas de archivos de períodos prolongados.
Para protegerte contra la corrupción de datos, Cloud Storage admite el uso de sumas de verificación CRC32C y MD5 para verificar la integridad de tus datos y detectar cambios en ellos.
CRC32C es el método de validación recomendado para realizar verificaciones de integridad. La validación con hashes MD5 es compatible con las cargas de un solo archivo, pero no es compatible con los objetos que se suben en partes, como los objetos compuestos y los objetos que se suben con una carga multiparte de la API de XML.
Sumas de verificación para escrituras de datos
En el caso de las escrituras de objetos, el cliente calcula la suma de verificación del archivo local y la adjunta a los encabezados HTTP de la solicitud de carga del objeto. El servidor recibe la carga útil de datos, calcula su propia suma de comprobación y valida los datos comparando ambas sumas de comprobación después de que finaliza la carga.
Si las sumas de verificación coinciden, el objeto se almacena en Cloud Storage junto con sus sumas de verificación. Si las sumas de verificación no coinciden, la solicitud de escritura se rechaza con un error BadRequestException: 400.
Validación del servidor para escrituras de datos
Cloud Storage realiza una validación del lado del servidor en los siguientes casos:
Cuando proporcionas el hash MD5 o CRC32C de un objeto en una solicitud de carga de objetos Para obtener información sobre los tipos de cargas de objetos, consulta Cargas de objetos.
Cuando realizas una solicitud de copia o reescritura dentro de Cloud Storage. En el caso de las solicitudes de copia y reescritura de objetos, Cloud Storage realiza automáticamente la validación del servidor en función de una suma de verificación no editable almacenada con el objeto fuente.
Cargas de una sola solicitud (media) de la API de JSON
En el caso de las cargas de contenido multimedia de la API de JSON, puedes especificar sumas de verificación en el encabezado X-Goog-Hash de la solicitud. Por ejemplo:
curl -X POST --data-binary @Desktop/dog-pic.jpeg \
-H "Authorization: Bearer $(gcloud auth print-access-token)" \
-H "Content-Type: image/jpeg" \
-H "X-Goog-Hash: crc32c=n03x6A==" \
"https://storage./upload/storage/v1/b/my-bucket/o?uploadType=media&name=dog-pic.jpeg"Cargas multiparte de la API de JSON
En el caso de las cargas de varias partes de la API de JSON, puedes especificar sumas de comprobación como parte del contenedor de solicitudes, ya sea en la sección de metadatos del objeto o en una tercera cadena de límite. Para obtener detalles sobre la estructura JSON y las claves válidas de un objeto, consulta la representación del recurso Objects.
En el siguiente ejemplo, se especifica una suma de verificación CRC32C en la parte de metadatos del objeto de un contenedor de solicitud:
--separator_string
Content-Type: application/json; charset=UTF-8
{
"name":"my-document.txt",
"crc32c": "n03x6A=="
}
--separator_string
Content-Type: text/plain
This is a text file.
--separator_string--
En el siguiente ejemplo, se especifica una suma de verificación CRC32C en la tercera cadena de límite de un contenedor de solicitud:
--separator_string
Content-Type: application/json; charset=UTF-8
{
"name":"my-document.txt"
}
--separator_string
Content-Type: text/plain
This is a text file.
--separator_string
Content-Type: application/json; charset=UTF-8
{ "crc32c": "n03x6A==" }
--separator_string--
Cargas reanudables de la API de JSON
Para las cargas reanudables de la API de JSON, puedes especificar sumas de comprobación en el encabezado X-Goog-Hash de la solicitud final que completa la carga. Por ejemplo:
curl -i -X PUT --data-binary @Desktop/dog-pic.jpeg \
-H "Content-Length: 2000000" \
-H "X-Goog-Hash: crc32c=n03x6A==" \
"SESSION_URI"La suma de verificación especificada en la solicitud final se calcula a partir de todo el objeto, no solo de los datos del objeto en la solicitud final.
Cargas de solicitud única de la API de XML
En el caso de las cargas de solicitud única de la API de XML, puedes especificar sumas de comprobación en el encabezado x-goog-hash de la solicitud.
Por ejemplo:
curl -X PUT --data-binary @Desktop/dog-pic.jpeg \
-H "Authorization: Bearer $(gcloud auth print-access-token)" \
-H "Content-Type: image/jpeg" \
-H "x-goog-hash: crc32c=n03x6A==" \
"https://storage.googleapis.com/my-bucket/dog-pic.jpeg"Las cargas de solicitud única de la API de XML también aceptan el encabezado Content-MD5 HTTP estándar. Para obtener más información, consulta la especificación de Content-MD5.
Cargas multiparte de la API de XML
En el caso de las cargas multiparte de la API de XML, puedes especificar una suma de verificación para cada parte de la carga individual. Para especificar una suma de verificación individual para una parte de la carga, incluye el encabezado x-goog-hash en la solicitud de esa parte específica.
Por ejemplo:
PUT /dog-pic.jpeg?partNumber=1&uploadId=ABgVH8 HTTP/1.1 Host: my-bucket.storage.googleapis.com Content-Length: 1000000 x-goog-hash: crc32c=n03x6A==
Solo se pueden usar sumas de comprobación CRC32C para verificar la integridad de las cargas multiparte de la API de XML. No se admiten las sumas de verificación MD5.
Cargas de gRPC
Cuando subes objetos con gRPC, puedes especificar sumas de verificación a nivel del objeto en el primer o último mensaje WriteObject de cualquier solicitud de carga, ya sea una carga única o una carga reanudable.
Además, gRPC admite sumas de verificación por mensaje. Cada mensaje WriteObject contiene fragmentos de datos de hasta 2 MiB, y cada fragmento puede incluir su propia suma de verificación. Puedes especificar sumas de verificación por mensaje en lugar de una suma de verificación a nivel del objeto o junto con ella.
Cargas compuestas paralelas
En el caso de las cargas compuestas paralelas, debes realizar una verificación de integridad para cada carga de componente y, luego, usar las condiciones previas con la solicitud de composición de carga para protegerte de las condiciones de carrera. Las solicitudes de composición no reciben validación del servidor, por lo que debes realizar una validación del cliente en el objeto compuesto nuevo si deseas una verificación de integridad de extremo a extremo.
Copias y reescrituras de Google Cloud CLI
En la CLI de gcloud, los datos copiados desde y hacia un bucket de Cloud Storage se validan automáticamente. Para los comandos cp, mv y rsync, la gcloud CLI usa sumas de comprobación MD5 o CRC32C para determinar si hay una diferencia entre la versión de un objeto que se encuentra en la fuente y la versión que se encuentra en el destino. Si la suma de verificación de los datos de origen no coincide con la suma de verificación de los datos de destino, la gcloud CLI borra la copia no válida y, luego, muestra un mensaje de advertencia.
Eso no suele suceder. Si coincide, puedes intentar de nuevo la operación.
Esta validación automática se produce después de que se completa el objeto, por lo que los objetos no válidos son visibles durante 1 o 3 segundos antes de que se identifiquen y se borren. Además, es posible que la gcloud CLI se interrumpa después de que se complete la carga, pero antes de que realice la validación, lo que deja el objeto no válido en su lugar. Estos problemas se pueden evitar cuando se suben
archivos únicos a Cloud Storage con la validación del servidor, que ocurre cuando se usa la marca --content-md5 para especificar un hash MD5.
Google Cloud CLI ignora la marca --content-md5 para los objetos que no tienen un hash MD5.
Detección de cambios para rsync
El comando gcloud storage rsync compara las sumas de comprobación en las siguientes situaciones para determinar si se debe omitir una transferencia:
El origen y el destino son buckets de Cloud Storage, y el objeto tiene una suma de comprobación MD5 o CRC32C en ambos buckets.
El objeto no tiene una hora de modificación de archivo (
mtime) en el origen o el destino.
En los casos en los que un objeto tiene un valor mtime en el origen y el destino, como cuando el origen y el destino son sistemas de archivos, el comando rsync compara el tamaño de los objetos y el valor mtime en lugar de usar sumas de comprobación. Del mismo modo, si la fuente es un bucket y el destino es un sistema de archivos local, el comando rsync usa la hora creada para el objeto de origen como sustituto de mtime, y el comando no usa sumas de comprobación.
Si no hay mtime ni sumas de comprobación disponibles, rsync solo compara los tamaños de archivo
cuando se determina si hay un cambio entre la versión de origen de un objeto
y la versión de destino. Por ejemplo, ni mtime ni las sumas de comprobación están
disponibles cuando se comparan objetos compuestos con objetos en un proveedor de servicios en la nube
que no admite CRC32C, ya que los objetos compuestos no tienen suma de comprobación MD5.
Validación del cliente para escrituras de datos
Puedes realizar una validación del cliente de tus cargas a través de la emisión de una solicitud para los metadatos del objeto subido, la comparación del valor de hash del objeto subido con el valor esperado y la eliminación del objeto en caso de no coincidir. Este método es útil si no se conoce el hash MD5 o CRC32C del objeto al inicio de la carga.
En la siguiente tabla, se muestran los clientes de Cloud Storage que admiten el cálculo de sumas de verificación para las escrituras de objetos de forma predeterminada, incluidas las versiones de los clientes que admiten sumas de verificación.
| Cliente | Versiones que admiten sumas de verificación |
|---|---|
| Biblioteca cliente de C++ de Cloud Storage | 2.46 y versiones posteriores |
| Biblioteca cliente de Go para Cloud Storage | 1.60.0 y versiones posteriores |
| Biblioteca cliente de Java de Cloud Storage | 2.62 y versiones posteriores |
| Biblioteca cliente de Cloud Storage para Node.js | 7.19.0 y versiones posteriores |
| Biblioteca cliente de Cloud Storage para PHP | 1.51.0 y versiones posteriores |
| Biblioteca cliente de Python de Cloud Storage | 3.7.0 y versiones posteriores |
| Biblioteca cliente de Ruby para Cloud Storage | 1.60.0 |
| Biblioteca cliente de .NET de Cloud Storage | 2.3.0 y versiones posteriores. Recomendamos la versión 4.15.0, que proporciona validación de suma de verificación del servidor. |
| Conector de Cloud Storage |
|
| Cloud Storage FUSE | 3.8.0 y versiones posteriores |
| Google Cloud CLI |
Sumas de verificación para lecturas de datos
En el caso de las descargas de objetos, el servidor envía el objeto junto con su suma de verificación almacenada en la respuesta. El cliente calcula su propia suma de verificación del archivo descargado en función de los bytes que recibió y compara las dos sumas de verificación para verificar la integridad de los datos.
Algunas bibliotecas cliente no realizan automáticamente la validación de la suma de verificación en los objetos descargados. Es posible que tu aplicación deba calcular de forma independiente la suma de verificación del archivo descargado con los bytes recibidos y compararla con el hash proporcionado por el servidor para verificar la integridad de los datos.
Validación del cliente para lecturas
Para realizar una verificación de integridad de los datos descargados, calcula la suma de comprobación a medida que se reciben los datos y compara tus resultados con la suma de comprobación proporcionada por el servidor.
Las sumas de comprobación del servidor se basan en el objeto completo tal como se almacena en Cloud Storage, lo que significa que los siguientes tipos de descargas no se pueden validar con las sumas de comprobación proporcionadas por el servidor:
Descargas que se someten a una transcodificación descompresiva: La suma de comprobación proporcionada por el servidor representa el objeto en su estado comprimido, mientras que a los datos entregados se les quitó la compresión y, en consecuencia, tienen un valor de suma de comprobación diferente.
Una respuesta que contiene solo una parte de los datos del objeto: Este tipo de respuesta se produce para las solicitudes
Range.Las lecturas de rangos de gRPC son una excepción a este punto y admiten la validación de extremo a extremo. En las lecturas por rangos de gRPC, Cloud Storage valida los datos incluyendo una suma de verificación CRC32C única dentro de cada fragmento de respuesta individual de una transmisión, lo que permite que el cliente verifique de inmediato que el bloque específico de datos no se haya dañado durante la transmisión. Para una validación más amplia, la transmisión también proporciona la suma de verificación completa de todo el objeto, que los clientes avanzados pueden usar para calcular un total acumulado y verificar la integridad del archivo más grande.
Si tu aplicación necesita leer rangos de objetos en lugar de objetos completos de una sola vez, te recomendamos que uses gRPC. De lo contrario, recomendamos usar solicitudes de rango solo para reiniciar la descarga de un objeto completo después del último desplazamiento recibido, en el que puedes calcular y validar la suma de verificación después de que se complete la descarga.
Cuando valides tu descarga, si hay una discrepancia entre la suma de comprobación calculada y la proporcionada por el servidor, significa que los datos se dañaron durante el tránsito. En estos casos, debes descartar los datos dañados y usar la lógica de reintento recomendada para reintentar la solicitud.
¿Qué sigue?
- Obtén información sobre las cargas de objetos y las descargas de objetos en Cloud Storage.
- Obtén información sobre las estrategias de reintento para Cloud Storage.