使用AWS S3预签名URL下载数据时的数据完整性校验咨询

校验执行的合理时机 #

别等客户端反馈文件损坏才排查问题，卡好三个节点基本能覆盖绝大多数风险：

• 迁移文件上传S3落盘后第一时间做源端校验：文件全部写入S3完成后，立刻拉取S3侧文件内容计算校验值，和本地迁移源的文件校验值比对，确认上传过程没有出现分片丢包、比特翻转问题，这步校验不通过的文件绝对不要生成预签名URL对外提供，从源头把坏文件挡在存储层
• 客户端下载完成落地后做端侧校验：客户端通过预签名URL完成全量文件下载、写入本地磁盘后，立刻计算本地文件的校验值比对，覆盖传输链路异常、本地磁盘写入错误的问题
• 存量文件做定期抽样校验：全量迁移完成后，按固定周期抽取1%-5%的存量文件重算校验值，防范S3底层存储静默比特翻转的小概率问题，不需要全量扫描，抽样比例足够覆盖风险

仅依赖TLS传输能否满足校验要求 #

完全不够，别省端到端校验的功夫。
TLS属于传输层校验机制，只能保证网络传输过程中的数据包不被中途篡改、不丢包，下面几类高频问题它根本覆盖不到：

• S3底层存储的静默损坏：比如磁盘坏道、多副本同步出错导致S3上存储的文件本身就损坏，这种情况下TLS只会正常把坏文件从S3传输到客户端，完全感知不到内容错误
• 客户端本地写入错误：比如用户本地磁盘存在坏道、下载过程中内存异常，导致网络传输过来的内容是正确的，但写到磁盘上的文件损坏，TLS在数据包被客户端网卡收到时就完成了校验，不会检查本地落盘的文件是否正确
• 中间缓存层异常：如果预签名URL前挂载了CDN或者正向代理，节点上缓存的文件本身就是损坏的，TLS只会校验客户端到缓存节点这段的传输正确性，不会核查缓存内存储的源文件是否完好
  你观察到的AWS CLI自动完成完整性校验，本质是CLI在应用层单独实现了端到端的校验值比对逻辑，不是靠TLS实现的。

现有MD5校验方案的落地建议 #

你构思的手动生成MD5SUMS、供客户端下载后本地比对的思路完全可行，比硬凑ETAG靠谱得多——分片上传生成的ETAG是「各分片MD5值拼接后再计算MD5-分片总数」的格式，只要分片大小存在差异，ETAG结果就无法匹配，大文件基本都采用分片上传模式，拿ETAG当通用校验值后续维护会踩非常多坑。
落地时注意几个细节即可：

• 校验文件和大文件放同路径同权限：把每个文件对应的MD5/SHA256校验值存在和大文件同目录的校验文件里，比如大文件叫data_2024.tar，校验文件就叫data_2024.tar.md5，同样存储在S3上，和大文件走相同的预签名授权逻辑，不需要单独搭建权限体系，也能避免校验文件被篡改
• 按需选择校验算法：如果只是防范传输错误、存储静默损坏这类非恶意问题，MD5计算速度快、性能足够；如果还要覆盖恶意篡改文件的场景，建议更换为SHA256算法，MD5目前已存在碰撞风险，无法防范人为构造的坏文件
• 自研客户端尽量内置校验逻辑：如果下载端是团队可控的客户端/SDK，把校验逻辑直接内置到下载流程中，下载完成自动计算校验值比对，校验失败自动重试，不要让用户手动执行命令计算校验值，能减少大量客诉问题
• 不要把校验值仅存在S3自定义元数据中：读取元数据需要单独调用HeadObject接口，预签名场景下还要单独给该接口做授权，不如直接放在同路径的校验文件中，逻辑更简单

内容的提问来源于stack exchange，提问作者Fidi Naj