You need to enable JavaScript to run this app.
导航
对象存储
  • 文档首页
    • /
  • 对象存储

概述

最近更新时间：2022.09.08 14:50:56

首次发布时间：2022.09.08 14:50:56

我的收藏

使用TOS进行数据上传或下载的过程中，可能会因为公网传输过程中在TOS外部的网络劫持、数据缓存等原因，导致数据不一致等问题。TOS提供了多种数据一致性相关的特性，您可以利用这些特性确保数据上传或下载的一致性。在TOS场景中，数据一致性校验分为上传对象一致性校验以及下载对象一致性校验，本文介绍这两种校验场景下的相关概念及校验方案。

相关概念

Content-MD5

HTTP协议定义的标准请求头域，代表请求消息体数据的指纹值，其计算方式是将数据经过MD5算法计算出哈希值后再经过Base64编码生成字符串。
在TOS场景中，PutObject和UploadPart接口支持在请求头域中携带该参数，PostObject支持在表单域中携带该参数。TOS会以同样的算法计算收到的数据并与该值做比较，如果不匹配则返回上传失败，对象不会在TOS侧生成。

Content-SHA256

TOS场景定义的请求头域，与Content-MD5类似，同样代表请求消息体数据的指纹值，只是其计算方式使用了更安全的SHA256算法，将数据经过SHA256算法计算出哈希值后再经过Hex编码生成字符串。
PutObject和UploadPart接口支持在请求头域中通过x-tos-content-sha256携带该参数。

CRC64

循环冗余校验算法，是业界常用于数据校验的标准算法，详细信息，请参见Cyclic redundancy check。
在TOS场景，PutObject、PostObject、UploadPart、GetObject、HeadObject、CompleteMutipartUpload均会在响应头域中通过x-tos-hash-crc64ecma字段返回该参数，代表本次读写数据的CRC64校验和。

注意

  • CRC64是新特性，部分该特性上线前上传的对象，GetObject和HeadObject的响应头域中可能不包含CRC64。
  • GetObject携带Range参数时，响应头域中返回的CRC64仍然是整个对象的CRC64。
  • ListObjects和ListObjectVersions获取到的对象列表中也新增了代表每个对象CRC64的字段。

校验上传对象的一致性

您可以通过Content-MD5、Content-SHA256或CRC64完成上传对象的一致性校验。不同校验方案的对比说明如下。

校验方式通过Content-MD5通过Content-SHA256通过CRC64

适用场景

  • 事先知道待上传数据的MD5 。
  • 待上传数据较小，例如数据大小在10 MB以内，否则事先计算的成本较高。
  • 数据校验不成功，不希望TOS侧生成对象的场景。
  • 事先知道待上传数据的SHA256。
  • 待上传数据较小，例如数据大小在10 MB以内，否则事先计算的成本较高。
  • 数据校验不成功，不希望TOS侧生成对象的场景。
  • 希望使用更安全的哈希算法用于数据校验。
  • CRC64可以在上传数据的过程中同步计算，没有额外计算一次的开销。
  • 对于分片上传的场景，可以对比计算合并后最终对象的CRC64，校验结果更可靠。

缺点

  • 需要事先计算出待上传数据的MD5，有一定的成本。
  • MD5算法的安全性低于SHA256算法。
  • 需要事先计算出待上传数据的SHA256，有一定的成本。
  • SHA256算法的效率低于MD5算法。

校验过程在客户端完成，此时TOS侧已生成实际上传的对象，需要额外的做覆盖或删除等清理工作。

支持的API

  • PutObject
  • PostObject
  • UploadPart
  • PutObject
  • UploadPart
  • PutObject
  • PostObject
  • UploadPart
  • CompleteMultipartUpload
参考文档通过Content-MD5通过Content-SHA256通过CRC64

推荐说明

  • 如果不希望有额外的计算开销，优先选择CRC64校验的方案。
  • 如果希望数据不一致时不在TOS侧生成对象，且希望使用更安全的哈希算法时，推荐使用Content-SHA256校验的方案；否则可以使用Content-MD5校验的方案。

校验下载对象的一致性

您可以利用CRC64实现下载对象的一致性校验，详细说明，请参见校验下载对象的一致性。