使用AWS JavaScript SDK上传至AWS S3超50GB后部分文件大小异常问题

问题边界确认 #

使用AWS JavaScript SDK实现Web端所选目录的全量文件上传，经测试场景验证：

• 当目录总文件大小低于50GB时，所有文件上传至S3后的大小、内容均与本地源文件完全一致
• 当目录总文件大小超过50GB时，会随机出现部分已上传文件的大小小于本地源文件实际大小的截断问题

核心常见根因 #

• SDK高级上传组件的边界逻辑缺陷
  日常开发中常用SDK封装的Upload高级上传类，在总传输量较低、单文件较小的场景下表现稳定，但当总传输量突破50GB量级时，高并发场景下容易出现分片完成校验逻辑失效的问题：部分分片的网络连接被静默切断时，SDK没有触发完整的重试流程，就直接将不完整的分片标记为已完成，最终合并生成的S3对象就会出现大小小于源文件的问题。
• 浏览器网络层的连接限制
  主流浏览器对单域名的并发TCP连接数有硬限制（通常为6个），当总上传量变大时，很多开发者会放开SDK的并发上限试图提升传输速度，此时一旦并发任务数超过浏览器的连接阈值，部分分片请求会被浏览器直接丢弃，且不会返回明确的错误信息，最终导致分片丢失、对象截断。
• 网络链路的隐性传输阈值限制
  企业网络、本地代理、运营商网络通常会对单长连接的累计传输数据量做隐形限制，常见的阈值区间就在40GB-60GB之间，一旦累计传输量触达阈值，连接会被静默切断，如果没有针对每个分片的强校验，就会出现不完整的上传结果。
• 浏览器端的文件读取截断
  当选择的目录总大小超过50GB时，浏览器会占用大量内存与文件句柄，部分场景下对大文件的流式读取会因为内存压力提前结束流，没有读完整个文件就触发了上传流程的完成事件，直接把截断的内容传到了S3。

可落地的优化方案 #

• 增加全链路强校验逻辑
  • 每个分片上传完成后，主动拉取分片的ETag、大小信息，和本地计算的分片哈希、分片大小做比对，不匹配的分片强制重试，不使用SDK默认的静默成功判断逻辑
  • 单文件全部分片上传完成后，主动调用HeadObject接口查询S3侧存储的对象实际大小，和本地源文件的大小做强制比对，大小不一致的直接触发全量重新上传，不做隐式的成功判定
• 调整传输参数适配大流量场景
  • 主动调大上传分片大小：将默认的5MB分片调整为16MB-25MB的固定大小，减少总分片数量，降低高并发下的连接压力
  • 严格控制并发任务数：将总上传并发数限制在3-4个，不超过浏览器的域名并发连接阈值，避免连接被浏览器主动丢弃
• 保障本地文件读取的完整性
  • 对大于100MB的文件，逐分片读取时同步计算每片的CRC32校验值，确认读取的内容完整后再发起上传请求，避免因为内存压力导致的流提前终止
  • 关闭SDK重试逻辑中的静默吞错配置，将所有网络层面的非成功响应全部捕获并触发重试，不把网络中断的场景判定为上传成功

内容的提问来源于stack exchange，提问作者Pradeepta Kumar Khatoi