Recomendaciones para ETags y Hash

Cloud Storage anima a los usuarios a que validen los datos que transfieren hacia sus depósitos y desde ellos con sumas de verificación CRC32c o MD5. En esta sección, se describen las recomendaciones para realizar estas validaciones.

Usa hash para verificar la integridad

Existen varias maneras en las que los datos se pueden corromper cuando los subes o los descargas de la nube:

  • Vínculos de red contaminados
  • Errores de memoria en computadoras del cliente o del servidor, o routers a lo largo de la ruta
  • Errores de software (p. ej., en una biblioteca que usen los clientes)

Para protegerse de la corrupción de datos, Cloud Storage es compatible con dos tipos de hash: CRC32C y MD5 (como se describe a continuación). Google recomienda que los clientes usen CRC32C en todos los casos, como se describe en la sección Validación a continuación. Los clientes que prefieren MD5 pueden usar ese hash, pero no es compatible con los objetos compuestos.

CRC32C

Todos los objetos de Cloud Storage tienen un hash CRC32c. CRC32C es una verificación de redundancia cíclica de 32 bits (CRC) según el polinomio Castagnoli. A esta CRC la describe la especificación IETF de SCTP. Las bibliotecas que se usan a fin de calcular CRC32c incluyen CRC32C de Google y Boost para C++, crcmod para Python y digest-crc para Ruby. Los usuarios de Java pueden encontrar una implementación del algoritmo en el proyecto de GoogleCloudPlatform crc32c para Java.

El CRC32c codificado en Base64 está en orden de bytes big-endian.

MD5

Cloud Storage es compatible con un hash MD5 para objetos no compuestos. Este hash solo se aplica en un objeto completo, por lo que no se puede usar para verificar la integridad de descargas parciales generadas por la realización de un rango GET.

ETag

El MD5 de un objeto siempre se expresó a través del encabezado ETag. Este comportamiento continuará para los objetos no compuestos en la API de XML, pero como los objetos compuestos no son compatibles con los hash MD5, los usuarios no deben hacer suposiciones sobre esas ETag excepto que cambiarán cuando los datos subyacentes cambien, por la especificación.

Validación

Se puede realizar una verificación de integridad mediante la generación de un hash de datos descargados en el momento y comparar tus resultados con los hash proporcionados por el servidor. Debes descartar datos descargados con valores de hash incorrectos y usar la lógica de reintento para evitar potenciales repeticiones infinitas y costosas.

Cloud Storage es compatible con la validación del lado del servidor para cargas, pero la validación del lado del cliente también es un enfoque común. Si tu aplicación ya calculó el MD5 o CRC32c del objeto antes de comenzar la carga, lo puedes proporcionar con la solicitud de carga y Cloud Storage solo creará el objeto si el hash que proporcionaste coincide con el valor que calculamos.

De forma alternativa, los usuarios pueden optar por realizar una validación del lado del cliente a través de la emisión de una solicitud para los metadatos del objeto nuevo cuando comparan el valor del hash informado, y borrar el objeto en caso de no coincidir. Para evitar las condiciones de carrera en las que los procesos independientes borran o reemplazan los datos de cada uno, recomendamos que uses generaciones de objetos y condiciones previas.

En el caso de cargas paralelas con la composición de objetos, los usuarios deben realizar una verificación de integridad para cada carga de componente y, luego, usar las condiciones previas del componente con sus solicitudes de composición a fin de protegerse de las condiciones de carrera. La composición de objeto ofrece una validación MD5 del lado del servidor para que los usuarios que deseen realizar una verificación de integridad de extremo a extremo deben aplicar una validación del lado del cliente al objeto de composición nuevo.

Al final de cada operación de copia, los comandos de gsutil cp y rsync validan que la suma de verificación del archivo local coincida con la del objeto almacenado en Cloud Storage. Si no coincide, gsutil borrará la copia no válida y, luego, imprimirá un mensaje de advertencia. Eso no suele suceder. Si coincide, puedes intentar de nuevo la operación.

API de XML

En la API de XML, los hash MD5 y CRC32c codificados en base64 se exponen y se aceptan a través del encabezado x-goog-hash. Antes, los MD5 se usaban como objetos de ETag, pero recomendamos que los usuarios eviten eso, ya que los objetos compuestos usarán valores de ETag opacos que no tienen garantía fuera del cambio cuando este ocurre.

La validación de carga del lado del servidor se puede realizar cuando se proporcionan hash calculados de manera local a través del encabezado de solicitud x-goog-hash. Además, el MD5 se puede proporcionar mediante el HTTP estándar encabezado Content-MD5 (consulta a la especificación).

API de JSON

En la API de JSON, las propiedades md5Hash y crc32c del recurso de objetos contienen los hash MD5 y CRC32c codificados en base64, respectivamente. Proporcionar cualquiera de las propiedades de metadatos es opcional. Si las propiedades no se proporcionan en una inserción de objeto, Cloud Storage calcula los valores y los escribe en los metadatos del objeto. Proporcionar cualquier propiedad con una solicitud de inserción activa la validación del lado del servidor para un objeto nuevo. Si Cloud Storage calcula un valor para cada propiedad que no coincide con el valor proporcionado, el objeto no se crea. Para cargas reanudables y multiparte, trabajas con las propiedades md5Hash y crc32c de la misma manera que con una inserción de objeto único.

¿Te ha resultado útil esta página? Enviar comentarios:

Enviar comentarios sobre...

Si necesitas ayuda, visita nuestra página de asistencia.