REST API大文件上传下载实现及流媒体传输原理解析

没有任何主流云存储、视频平台会用单次multipart form请求处理GB级以上的大文件上传。单次请求的容错成本极高，网络闪断、客户端进程被回收、页面意外关闭都会导致整个文件重传——试想10G的视频传了99%断网要从头开始，用户体验完全无法落地。

S3、YouTube这类服务通用的分片上传流程是固定的：

• 初始化上传阶段：客户端先向服务端提交文件基础元信息，包括文件名、总大小、全文件哈希值、MIME类型，服务端校验后生成全局唯一的upload_id返回，同时告知客户端当前场景适配的分片大小规则：S3默认分片大小为16MB，YouTube会根据用户当前上传带宽动态调整，弱网环境下自动把分片切到2MB~8MB降低单次请求失败概率。
• 分片并发上传阶段：客户端本地按约定大小切分文件，为每个分片计算独立哈希，携带upload_id和分片序号发起独立请求上传，一般会控制3~5个上传并发避免占满用户上行带宽。单个分片传输失败仅重传当前分片，不影响其他已完成上传的分片。注意这个阶段根本不会用multipart格式包裹整个大文件，每个分片本身就是独立的PUT请求，服务端收到分片后先存入临时存储区，记录分片序号和对应哈希值，不会提前做合并。
• 完成合并校验阶段：客户端确认所有分片上传完成后，向服务端发送完成请求，携带全部分片的序号、哈希列表。服务端按序号拼接所有分片，计算全文件哈希和客户端提交的值做比对，校验通过就把文件从临时存储迁移到正式对象存储集群，返回最终的文件访问标识；如果发现分片缺失、损坏，直接返回对应分片的序号，让客户端定向补传即可。

生产环境还会基于这套流程做两个体验优化：

• 断点续传：客户端本地会持久化已上传成功的分片记录，用户下次重新进入上传页面时，只要携带upload_id向服务端查询已收到的分片列表，就能跳过已完成部分直接传剩余分片，哪怕间隔数天再续传也不需要从头开始。
• 秒传：初始化上传阶段，服务端收到全文件哈希后会先在存储池检索，如果已经存在相同哈希的文件，直接返回上传成功，客户端不需要传输任何分片内容。

S3这类对象存储服务的大文件下载，核心依赖HTTP协议的Range能力实现，和流媒体逻辑有明显区别：

• 客户端发起请求时携带Range: bytes=start-end请求头，告知服务端只需要返回指定区间的字节内容，服务端收到后返回206 Partial Content状态码，仅返回对应区间的数据，不需要加载整个文件。
• 多线程下载工具就是基于这个能力实现：把整个文件按大小拆成多个连续区间，开多个并发线程同时请求不同Range段，所有段下载完成后在本地拼接为完整文件，单个段下载失败仅重传对应区间即可。
• 服务端处理这类请求时不会把整个文件读入内存，而是直接从存储层读取指定字节范围的数据流，边读边写入响应缓冲区，全程内存占用仅维持在KB级别，不会出现大文件下载打满服务端内存的问题。

流媒体和普通大文件下载的核心差异是：不需要等整个文件下载完成就能开始播放，且能根据用户实时网速动态调整播放清晰度，核心实现逻辑如下：

• 预处理阶段：平台会在视频上传完成后做转码切片，首先输出从360P到4K不等的多档清晰度版本，再把每个清晰度的视频切为2~10秒长度的独立小分片，分片一般采用fMP4或者MPEG-TS格式，单个分片可以独立解码播放，不依赖其他分片的内容。
• 索引拉取阶段：播放器启动后首先拉取视频的索引清单文件，清单里记录了每一档清晰度对应的分片地址、每个分片的时长、字节范围、编码参数信息。
• 缓冲播放阶段：播放器本身只维持一个很小的播放缓冲区，一般提前缓冲接下来20~30秒的内容，按播放顺序依次请求对应的小分片，分片下载完成后直接送入解码器播放，不会把完整的视频文件全部下载到本地。如果播放过程中检测到用户网速下降，就自动切换到更低清晰度的后续分片，网速恢复后再切回高码率分片，整个切换过程用户几乎无感知。
• 进度拖动和缓存：用户拖动进度条时，播放器会直接计算进度位置对应的分片序号，请求对应分片即可，不需要下载整个视频。已经缓冲过的分片会存在本地缓存里，用户往回拖动进度时直接读缓存，不需要重复发起请求。
• 所有流媒体分片都会提前缓存到离用户物理距离最近的CDN节点，用户请求时会被调度到延迟最低的节点取数据，正常网络环境下分片请求延迟可以控制在几十毫秒以内，避免播放卡顿。

内容的提问来源于stack exchange，提问作者Aditya Gupta