FDM 分段加速原理——为什么下载速度能快 10 倍
核心原理：HTTP Range 请求
FDM 加速的本质是 HTTP/HTTPS 的 Range 请求。这个机制允许客户端向服务器请求文件的某一个字节范围，而不是整个文件。
举个例子——一个 100 MB 的文件，默认被分成 8 段：
- 段 0：字节 0 ~ 12.5 MB
- 段 1：字节 12.5 MB ~ 25 MB
- ...
- 段 7：字节 87.5 MB ~ 100 MB
FDM 同时建立 8 条独立的 HTTP 连接，每条连接负责下载其中一段。8 段全部下载完成后，在本地按原始顺序拼接成完整文件。
服务器只要支持 Range 请求（绝大多数 CDN 和正经文件服务器都支持），这个流程就能跑通。
速度公式
单线程下载时，你的下载速度上限是：
min(你的带宽，服务器对单个连接的限速)
分段后变成：
min(你的带宽，8 × 服务器对单连接限速)
如果服务器单连接限速 1 MB/s，你的带宽是 50 MB/s（400 Mbps）：
- 单线程：1 MB/s
- 8 段：8 MB/s（吃到服务器单连接限速的 8 倍）
- 16 段：16 MB/s（继续叠加直到撞到你的带宽上限）
这就是 FDM 官方宣传的"最高 10 倍加速"——理论上把服务器单连接限速 N 倍叠加到你能承受的最大值。
哪些场景加速最明显
能感受到明显加速的场景：
- 服务器有单连接限速（大多数网盘、国内 CDN、游戏下载服务器都有）
- 你的下行带宽 > 服务器单连接限速（分段数 = 加速倍数）
- 文件足够大（分段数才有意义，小文件比如 1 MB 以下分 8 段反而 overhead）
- 服务器支持多连接并发（少数服务器会根据 IP 做并发连接数限制）
感受不到加速甚至变慢的场景：
- 服务器不限速（比如本地局域网或 P2P 源）——单连接已经跑满你的带宽了，分段只会增加 TCP 握手 overhead
- 使用 HTTPS 且服务器做了严格的 IP 级连接数限制
- 从网盘直链下载（很多网盘会监控每 IP 的连接数，多线程可能被临时封禁）
- 下载的文件只有几十 KB（overhead 占比太大）
默认分段数和手动调整
FDM 默认的分段数因文件大小自动调整：
- < 5 MB：不分段（1 段）
- 5 ~ 50 MB：4 段
- 50 ~ 500 MB：8 段
- > 500 MB：16 段
可以在偏好设置里改默认值：偏好设置 → 下载列表 → 默认分段数。也可以在添加下载任务对话框里临时指定——对话框里有个「分段数」下拉框，你可以把单个任务改成 32 段甚至 64 段。
改高了一定会更快吗？不一定。超过服务器能承受的并发数后，服务器会开始拒绝多余连接、或者主动给你的所有连接都降速。经验值：国内服务器建议 8-16 段，国外 CDN 可以试 16-32 段，P2P 源保持默认就行。
分段下载的容错优势
除了加速，分段还有一个隐藏好处：容错率更高。
如果用单线程下载到 50 MB 时断线了，需要从头开始（除非服务器支持 Range 且客户端会续传）。分段下载时，8 段同时进行，某一段的连接断了 FDM 会自动重连、只重下那一段，其他段不受影响。
这就是为什么 FDM 的断点续传比单线程浏览器下载更可靠——它是在段级别做的容错。
拼接文件的过程
所有段下载完后，FDM 在本地做一个简单的文件拼接操作：
- 创建一个空的目标文件（大小就是完整文件大小）
- 把每个段的字节写进对应的偏移位置
- 校验文件完整性（对比服务器返回的 Content-Length 或 MD5）
如果拼接后校验失败，FDM 会提示下载损坏并让你选择是否重下。这种情况比较少见，多半是某一段数据本身就有问题（服务器返回了错的数据）。
对 FTP 协议的支持
FDM 的分段加速不只适用于 HTTP/HTTPS。它对 FTP 协议也支持分段——但 FTP 的 Range 请求实现方式不太一样，需要 FTP 服务器支持 SIZE 和 REST 命令。大多数公共 FTP 服务器都支持，但少数老的或配置简陋的不支持。
实战建议
- 默认分段数就够用——8 段覆盖了绝大多数场景，盲目拉高到 64 段只会增加服务器压力和自己本机的 TCP 连接管理 overhead
- 从网盘下大文件时先试 16 段——如果发现被限速（每个连接只能到 100KB/s），分段能把带宽吃满。但如果网盘提示"检测到多线程访问"，立刻改回单段
- BT 下载不走分段引擎——BT 的"分段"是 BitTorrent 协议自带的分片机制，和 HTTP Range 是完全不同的东西。FDM 的 BT 客户端有自己的下载策略，详见 BT 客户端
分段加速只是 FDM 下载引擎的一半，另一半是断点续传——下一页讲。