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。
  • ListObjectsListObjectVersions获取到的对象列表中也新增了代表每个对象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实现下载对象的一致性校验,详细说明,请参见校验下载对象的一致性