Hashes e eTags: práticas recomendadas

O Cloud Storage incentiva os usuários a validar os dados transferidos de/para seus intervalos usando as somas de verificação CRC32c ou MD5. Nesta seção, você verá as práticas recomendadas para executar essas validações.

Como usar hashes para verificação de integridade

Há várias maneiras de corromper os dados durante o upload ou o download do Cloud:

  • Links de rede com ruído.
  • Erros de memória em computadores clientes ou servidores, ou roteadores ao longo do caminho.
  • Erros de software (por exemplo, em uma biblioteca que os clientes usam).

Para proteger contra esse problema, o Cloud Storage aceita dois tipos de hashes: CRC32C e MD5 (descritos abaixo). O Google recomenda que os clientes usem CRC32C para todos os casos, conforme descrito na seção Validação abaixo. Os clientes que preferirem MD5 podem usar essa hash, mas ela não é compatível com objetos compostos.

CRC32C

Todos os objetos do Cloud Storage têm uma hash CRC32c. A CRC32C é uma verificação de redundância cíclica (CRC, na sigla em inglês) de 32 bits com base no polinômio de Castagnoli. Esta CRC é descrita pela especificação IETF para SCTP. As bibliotecas para computação da CRC32c incluem CRC32C do Google e Boost para C++, crcmod para Python e digest-crc para Ruby. Os usuários de Java podem encontrar uma implementação do algoritmo no projeto Java do googleCloudPlatform crc32c.

A CRC32c codificada em Base64 está na ordem de bytes big-endian.

MD5

O Cloud Storage aceita uma hash MD5 para objetos não compostos. Essa hash só se aplica a um objeto completo, portanto, não pode ser usada para verificar parcialmente os downloads causados ​​pela execução de um intervalo GET.

ETags

Historicamente, o MD5 de um objeto era expressado por meio do cabeçalho ETag. Esse comportamento continuará para objetos não compostos na API XML, mas como objetos compostos não aceitam hashes MD5, os usuários não farão suposições sobre esses ETags, exceto que eles serão alterados sempre que os dados subjacentes forem alterados, conforme a especificação.

Validação

Uma verificação de integridade de download pode ser executada ao fazer a hash dos dados de download no período de veiculação e comparar seus resultados às hashes fornecidas pelo servidor. Descarte dados de download com valores de hash incorretos e use a lógica de repetição para evitar loops infinitos e potencialmente caros.

O Cloud Storage é compatível com a validação do lado do servidor para uploads, mas a validação do lado do cliente também é uma abordagem comum. Se seu aplicativo já tiver computado a MD5 ou a CRC32c do objeto antes de iniciar o upload, você poderá fornecê-la com a solicitação de upload, e o Cloud Storage só criará o objeto se a hash fornecida corresponder ao valor que calculamos.

Como alternativa, os usuários podem optar por realizar a validação no lado do cliente emitindo uma solicitação para os metadados do novo objeto, comparando o valor de hash informado e excluindo o objeto em caso de incompatibilidade. Para evitar condições de corrida em que processos independentes excluam ou substituam os dados uns dos outros, também recomendamos o uso de gerações de objetos e condições prévias.

No caso de uploads paralelos usando a composição de objetos, os usuários executam uma verificação de integridade para cada upload de componente e, em seguida, usam as condições prévias do componente com as solicitações de composição para proteção contra condições de corrida. A composição de objetos não oferece validação MD5 do lado do servidor, portanto, os usuários que queiram executar uma verificação de integridade de ponta a ponta precisam aplicar a validação do lado do cliente ao novo objeto composto.

No final de cada operação de cópia, os comandos gsutil cp e rsync validam que a soma de verificação do arquivo local corresponde à da soma de verificação do objeto armazenado no Cloud Storage. Se isso não ocorrer, o gsutil excluirá a cópia inválida e imprimirá uma mensagem de aviso. Isso raramente acontece. Em caso afirmativo, você poderá repetir a operação.

API XML

Na API XML, as hashes MD5 e CRC32c codificadas em base64 são expostas e aceitas por meio do cabeçalho x-goog-hash. Antigamente, as MD5 eram usadas ​​como ETags de objeto, mas recomendamos que os usuários evitem supor isso, já que os objetos compostos usarão valores de ETag opacos que não oferecem garantias além de serem alterados quando o objeto é alterado.

A validação de upload do lado do servidor pode ser realizada fornecendo hashes calculadas localmente por meio do cabeçalho de solicitação x-goog-hash. Além disso, a MD5 pode ser fornecida usando o cabeçalho Content-MD5 HTTP padrão. Consulte a especificação.

API JSON

Na API JSON, os recursos de objetos md5Hash e as propriedades crc32c contêm hashes MD5 e CRC32c codificadas em base64, respectivamente. Fornecer a propriedade de metadados é opcional. Se as propriedades não forem fornecidas em uma inserção de objeto, o Cloud Storage calculará os valores e os gravará nos metadados do objeto. Fornecer uma das propriedades com uma solicitação de inserção acionará a validação do lado do servidor para o novo objeto. Se o Cloud Storage calcular um valor para qualquer propriedade que não corresponda a um valor fornecido, o objeto não será criado. Para uploads recuperáveis e com várias partes, você trabalha com as propriedades md5Hash e crc32c da mesma forma que para uma única inserção de objeto.

Esta página foi útil? Conte sua opinião sobre:

Enviar comentários sobre…

Precisa de ajuda? Acesse nossa página de suporte.