断点续传实现？

核心技术原理与工程实践完整指南

目录导读

1. 断点续传的核心概念与价值
2. HTTP协议层面的断点续传机制（Range & If-Range）
3. 客户端实现断点续传的完整流程
4. 服务端实现断点续传的关键技术（Node.js + Java示例）
5. 大文件分片上传与断点续传的进阶实践
6. 常见问题与面试问答（FAQ）

---

断点续传的核心概念与价值

断点续传（Resumable Upload/Download）指的是在文件传输过程中，由于网络中断、程序崩溃或用户暂停等异常情况中断后，后续可以从上次中断的位置继续传输剩余数据,而不是重新开始整个传输过程。

为什么需要断点续传？

• 节省带宽与时间：大文件（如高清视频、数据库备份）传输中断后，如果重新下载，浪费了大量已传输的流量。
• 提升用户体验：用户无需因一次网络抖动就从头等待。
• 降低服务端负载：避免重复读取已发送的文件块。

适用场景：

• 文件下载（视频、软件安装包）
• 文件上传（云存储、资源管理后台）
• 音视频流媒体（支持拖动播放）

---

HTTP协议层面的断点续传机制

所有基于HTTP的断点续传实现，核心依赖 HTTP/1.1 的 Range 协议头。

1 Range 与 Content-Range

• 客户端请求：在请求头中加入 Range: bytes=<start>-<end>，告知服务器仅返回指定字节范围的数据。
• 服务器响应：
  • 状态码 206 Partial Content：表示返回的是部分内容。
  • 响应头 Content-Range: bytes <start>-<end>/<total> 指明本次返回的字节范围及总大小。
  • 如果不支持 Range，服务器返回 200 OK 和完整文件。

2 If-Range 条件请求

用于验证资源是否在断点期间发生变更：

• 如果资源未修改，服务器返回 206。
• 如果资源已变更，服务器返回 200 并传输完整文件,避免客户端用旧断点继续下载新版本时出现数据错乱。

3 多线程断点下载

客户端可以同时发起多个 Range 请求，将文件分片后并行下载，最后在本地合并，主流下载工具（如 IDM、迅雷）均采用此策略,显著提升下载速度。

关键点：

• 服务端必须支持 Accept-Ranges: bytes（默认支持）。
• 每个分片对应的 Range 不能重叠，且最终需按顺序合并。

---

客户端实现断点续传的完整流程

以下以浏览器端下载大文件为例，展示如何用 JavaScript 实现断点续传。

1 记录下载进度

客户端需将已下载的字节数持久化存储（如 localStorage、IndexedDB、文件系统 API），当下载中断后,重新启动时从存储中读取已下载大小。

// 模拟：将已下载字节存入 localStorage
localStorage.setItem('file_download_progress', downloadedBytes);

2 构造 Range 请求

const startByte = parseInt(localStorage.getItem('file_download_progress')) || 0;
fetch('https://example.com/large-file.zip', {
  headers: {
    'Range': `bytes=${startByte}-`
  }
})
.then(response => {
  if (response.status === 206) {
    const reader = response.body.getReader();
    // 循环读取流并累加到本地文件
  }
});

3 处理流数据并合并

使用 ReadableStream 将数据逐渐写入本地文件（通过 File System Access API 或 Blob），若使用传统 XMLHttpRequest，可通过 responseType: 'blob' 拼接。

注意事项：

• 如果文件已被删除或修改，服务端返回 404 或 200，客户端需重新获取完整文件。
• 多线程下载需要在本地记录每个分片的进度和偏移量。

---

服务端实现断点续传的关键技术

服务端需要正确处理 Range 请求,并提供静态文件服务或自定义上传逻辑。

1 Node.js 实现文件下载断点续传

const http = require('http');
const fs = require('fs');
const path = require('path');
http.createServer((req, res) => {
  const filePath = path.join(__dirname, 'bigfile.mp4');
  const stat = fs.statSync(filePath);
  const fileSize = stat.size;
  const range = req.headers.range;
  if (range) {
    // 解析 Range 头: "bytes=0-1000" 或 "bytes=500-"
    const parts = range.replace(/bytes=/, "").split("-");
    const start = parseInt(parts[0], 10);
    const end = parts[1] ? parseInt(parts[1], 10) : fileSize - 1;
    const chunkSize = end - start + 1;
    res.writeHead(206, {
      'Content-Range': `bytes ${start}-${end}/${fileSize}`,
      'Accept-Ranges': 'bytes',
      'Content-Length': chunkSize,
      'Content-Type': 'video/mp4'
    });
    const stream = fs.createReadStream(filePath, { start, end });
    stream.pipe(res);
  } else {
    // 不支持 Range 时返回完整文件
    res.writeHead(200, {
      'Content-Length': fileSize,
      'Content-Type': 'video/mp4'
    });
    fs.createReadStream(filePath).pipe(res);
  }
}).listen(3000);

2 Java Spring Boot 实现文件上传断点续传

上传断点续传通常结合分片上传使用，服务端需要：

• 每个分片拥有唯一标识（如 FileId + chunkIndex）。
• 保存每个分片的上传状态（已上传、未上传、暂存位置）。
• 所有分片上传完成后,服务端合并文件。

核心接口设计：

1. POST /upload/init — 初始化上传，返回文件唯一 ID。
2. POST /upload/chunk — 上传单个分片，携带 fileId、chunkIndex、totalChunks。
3. GET /upload/progress?fileId=xxx — 查询已上传的分片索引列表（支持断点查询）。
4. POST /upload/complete — 通知服务端合并所有分片。

保证数据一致性的技巧：

• 使用 MD5 校验每个分片，服务端保存分片的 MD5，合并时校验。
• 合并操作加锁，避免并发合并导致文件损坏。

---

大文件分片上传与断点续传的进阶实践

1 断点续传的核心挑战

• 并发控制：多分片同时上传时，合并顺序必须正确。
• 临时文件管理：未完成的分片需要临时存储，需设计清理策略。
• 网络恢复后的验证：客户端需向服务端确认哪些分片已成功上传，避免重复上传。

2 常见实现方案

方案	优点	缺点	适合场景
服务端存储分片状态	可靠，不依赖客户端	增加服务端存储成本	云端网盘
客户端记录偏移量+服务端Range	无需复杂状态管理	仅适用于下载	文件下载
分布式文件系统（MinIO、OSS）	自带断点续传 SDK	依赖外部系统	企业级存储

3 实战建议

• 分段大小选择：推荐 1MB~10MB，太大会导致重试成本高，太小增加请求次数。
• 重试机制：上传失败的分片应自动重试 3~5 次，间隔指数退避。
• 进度展示：通过分片上传进度计算整体百分比。

---

常见问题与面试问答

Q1：断点续传和分片上传是一回事吗？
A：分片上传是断点续传的一种实现方式，分片上传将大文件切分成多个小块分别上传，其中任意一个分片上传失败后，可以仅重传该分片，这是断点续传的核心，但断点续传也可以基于流的 Range 实现（如下载场景）,不一定需要分片。

Q2：如何保证下载断点续传的文件完整性？
A：下载完成后，客户端可与服务端提供的文件 MD5/SHA256 校验码比对，如果下载期间文件在服务端被修改，则通过 If-Range 或 ETag 检测到变更,客户端会重新下载。

Q3：浏览器中如何实现文件上传的断点续传？
A：浏览器无法直接操作本地文件系统，目前有两种路径：

1. 使用 File System Access API（Chrome 支持）将分片写入本地临时文件夹。
2. 将分片缓存在 IndexedDB 或 内存 Blob 中，但缺点是大文件可能导致内存溢出，最主流的方式是每次上传时不保留本地分片，只记录“已上传成功的分片索引”,失败后从服务端查询缺失的分片并重新上传。

Q4：服务端如何验证分片上传时客户端发起的 Range 请求是否合法？
A：服务端应检查：

• Range 的 start 不能大于文件总大小。
• 分片的 end 不能超过文件末尾。
• 如果文件是动态生成的（如视频转码），需确保 Range 对应的字节数据与文件当前状态一致。

Q5：断点续传时，服务端需要保存哪些信息？
A：至少需要保存：

• 文件唯一 ID（可用 MD5 或 UUID）
• 文件总大小、分片数量、每个分片的索引和大小
• 每个分片的上传状态（未上传/已上传/上传中）
• 已完成分片的 MD5 值（用于合并校验）

---

断点续传是提升大文件传输可靠性的核心手段，其底层技术依赖于 HTTP Range 协议 或 分片上传 思想，无论下载还是上传，核心都是通过记录进度、分块传输、失败重试三大步骤实现“从哪里断，就从哪里续”，在实际企业级开发中，建议结合云存储 SDK（如阿里云 OSS、AWS S3）或成熟的开源方案（如 Tus 协议）快速落地，同时注意并发安全、临时文件清理与校验机制。

建议进一步阅读：

• RFC 7233（HTTP Range Requests）
• Tus 协议（开源可恢复上传协议）
• 腾讯云 COS 分片上传 API 文档

标签： 分片上传