Cloudreve 秒传功能实现大致想法

若文件体积大于多少MB，在上传过程中，先检查站内有无字节数与新增文件完全相同的文件，若字节数相同，再对比MD5，相同则秒传，反之继续上传

May 28 '25 01:05 123456p2625

第三方存储直传时，如何获取可信的文件哈希？

May 28 '25 01:05 HFO4

我想的是可以保留上传线程的同时，另开一个线程，调用crypto库使用本地资源计算文件md5，然后跟数据库的进行比对，若相同则终止上传线程

May 28 '25 02:05 123456p2625

数据库中已有的哈希是从哪来的？如果是Web端计算的话，那 WebDAV 上传的文件怎么办？如果是服务端计算的话，违背了存储策略都要支持客户端直传的理念。

May 28 '25 02:05 HFO4

综合来说，实现秒传代价较大，收益比较小。

May 28 '25 02:05 HFO4

数据库中已有的哈希是从哪来的？如果是Web端计算的话，那 WebDAV 上传的文件怎么办？如果是服务端计算的话，违背了存储策略都要支持客户端直传的理念。

只支持Web/App 是一个很合理的限制/需求。对于数据库中已有的文件可以在版本升级时服务端创建后台任务计算，此后都由客户端计算。

Jun 11 '25 09:06 yixinin

数据库中已有的哈希是从哪来的？如果是Web端计算的话，那 WebDAV 上传的文件怎么办？如果是服务端计算的话，违背了存储策略都要支持客户端直传的理念。

只支持Web/App 是一个很合理的限制/需求。对于数据库中已有的文件可以在版本升级时服务端创建后台任务计算，此后都由客户端计算。

要做这个功能势必做取舍，以现有的资源\架构来看，要做到以下约定：

第一份哈希计算安全
- 所有文件的首次哈希值必须由服务端计算，计算途径包括：
  - 文件上传至本机/从机存储时实时计算
  - 离线下载任务完成后的异步计算
- 禁止直接信任客户端提交的哈希值（防恶意伪造）
秒传功能启用范围
- 仅限本机存储和从机存储策略支持秒传
- 排除对象存储/三方网盘（因无法控制哈希计算）
触发入口限制
- 允许触发秒传的入口：
  - Web端文件上传接口
  - 开放API的上传请求
- 禁止触发的入口：
  - WebDAV协议上传中转
  - 第三方客户端直连存储的上传

4.唯一文件备份责任（商讨采用哪种方案，或多方案并行）

备份类型	执行方	责任范围	恢复机制
程序自动备份	系统自动执行	跨存储策略多副本备份分发	自动检测损坏并从副本恢复
跨存储备份	运营人员	定期将唯一文件复制至冷备存储	人工校验后从冷备存储恢复

对于存在唯一一份文件的，要考虑文件损坏或遗失的情况，该文件的备份是由cr进行多存储的分发备份还是由运营人员备份，需要划清明确的界限避免纠纷 5.上传如触发了秒传功能，如果跨存储，是直接引用存储的文件唯一id，还是对文件进行跨存储物理复制后，再进行标记（明确全局唯一文件，还是以存储策略为单位的唯一文件，需要考虑现有的多个从机存储策略可绑定同一从机） 6.如果文件的索引标记为0时是否物理删除该文件，如果删除则需考虑唯一文件的宽限期是多久

Jun 11 '25 10:06 omiku

也不一定只支持有本机存储策略，第三方存储策略开启了中转上传的理论上也可以计算Hash。

Jun 11 '25 13:06 HFO4

可以用文件头信息+hash来确认是否为同一文件，代价和安全性有较好的平衡

Jun 12 '25 03:06 yixinin

MD5不推荐，碰撞概率太高。

推荐如下，验证客户端文件是否为同一文件： 0. 文件大于100MB时，开启秒传校验。再小的文件，没意义。

文件头5bytes
文件字节数
文件sha256
文件crc32
文件内随机段(可以取其中的16K字节)校验md5

5.1 随机段开始字节位
5.2 随机段结束字节位
5.3 随机段内容md5

服务端侧，可利用空余时间，慢慢计算、慢慢整合相同文件。

Oct 17 '25 06:10 fawn319

MD5不推荐，碰撞概率太高。

推荐如下，验证客户端文件是否为同一文件： 0. 文件大于100MB时，开启秒传校验。再小的文件，没意义。

文件头5bytes

文件字节数

文件sha256

文件crc32

文件内随机段(可以取其中的16K字节)校验md5

5.1 随机段开始字节位

5.2 随机段结束字节位

5.3 随机段内容md5

服务端侧，可利用空余时间，慢慢计算、慢慢整合相同文件。

感觉文件量不够大的话能碰上秒传的概率太小了，实现不了类似大厂网盘的体验。

Oct 17 '25 07:10 YUDONGLING