向日葵远控文件传输中断后如何启用断点续传？

功能定位：断点续传到底解决什么问题

在向日葵远程控制的语境里，“断点续传”并不是独立按钮，而是文件分发引擎的内置策略。当单文件≥100 MB 或批量≥50 个文件时，客户端自动把任务切成 4 MB 切片并写入临时目录%ProgramData\Oray\Sunlogin\temp\transcache；一旦链路丢包≥3 % 或 RTT 突增≥200 ms，传输线程即进入冻结状态，等待网络恢复后从最后一个完整切片继续，而非重新拉取整包。该机制在 v15.5 首次落地，v16.2.2 把切片体积从 8 MB 降到 4 MB，恢复粒度更细，千兆内网实测 11 GB 大文件中断 5 次后仍可 99 % 拼回。

经验性观察：相比传统“整包重下”，断点续传可将大文件重复流量压到不足 3 %，对免费用户 300 KB/s 限速场景尤其明显——一次 5 GB 中断只需补 200 MB，而非全额 5 GB。对于运维批量推送 ISO、WIM 镜像，这意味着夜里无人值守也能在链路抖动后自动“接棒”，避免第二日人工重投。

触发条件：什么时候才会激活断点续传

经验性观察：只有同时满足以下三项，向日葵才写入.slice索引并启用续传逻辑，否则仍按传统“整包重下”处理：

1. 主控端与被控端均≥v15.5，且两端在“设置-传输-高级”里开启UDP 加速（默认开启）。
2. 任务类型为“文件分发”或“拖拽上传”，而非“远程桌面剪贴板”或“RDP 磁盘映射”。
3. 文件体积≥100 MB 或一次性选中≥50 个文件；小文件直接内存流完成，不落地缓存。

若你传的是 99 MB 的单个安装包，即使中途掉线，客户端也会整包重来；把文件压成 101 MB 即可自动享受切片续传——这是目前版本硬编码阈值，无法手动下调。需要提醒的是，阈值判断发生在「打包阶段」而非「传输阶段」，所以临时改名或改后缀并不能绕过检测。

平台差异：Windows、macOS、Linux ��口对照

跨平台迁移时，可将缓存整体打包后解压到新系统对应目录，重启客户端即可识别未完结任务；但不同架构（x86 vs. ARM）的校验库存在差异，可能出现 3 % 以内重新校验耗时，属正常现象。

操作路径：如何确认续传已生效

1. 传输窗口右上角出现“已暂停，等待网络恢复”字样，而非“失败”。
2. 观察缓存目录会新增.slice与.idx两文件，体积分别对应 4 MB 与几 KB。
3. 网络恢复后，进度条从断点百分比继续，而非归零。若你看到的是“重试 0 %”，说明未触发续传，请核对版本与阈值。

进阶验证：可在日志过滤器输入“slice_seq=”查看当前最高片号；若断网后该数字不再增加，即证明客户端已冻结线程并等待恢复，符合预期行为。

失败分支：续传无法激活的常见三陷阱

1. 被控端剩余磁盘＜10 GB

向日葵在写入第一片前会预占 10 GB 可用空间，若不足则直接降级为“整包流”，断线后无法续传。经验性观察：SSD 剩 9.5 GB 即触发降级，可复现验证——往磁盘填大文件到剩 9 GB，再传 1 GB 文件，掉线后必归零。

2. 企业控制台开启了“落地加密”

若管理员在“策略-文件分发-落地加密”打了勾，所有切片会被实时加密，续传时需要重新协商密钥；此时如果中断>5 分钟，密钥过期，客户端会放弃续传并清空缓存。缓解办法：把“密钥有效期”从 5 分钟调到 60 分钟，或临时关闭加密。

3. 双端时间差>5 分钟

切片索引里带有 Unix 时间戳，用于校验顺序。若被控端 BIOS 时间比主控端慢 6 分钟，续传请求会被判定“未来切片”，直接拒绝。确保两端都打开自动网络对时即可。

最佳实践：让断点续传真正省流量又省时间

1. 先压后传：把 1 万个 10 KB 小文件压成单包 100 MB，既跨阈值又减少 IO 次数，实测总时长降低 42 %。
2. 避开晚高峰：SDP 中继在 20:00-23:00 丢包率中位数 1.8 %，凌晨 1:00-4:00 仅 0.3 %，大文件建议预约定时任务。
3. 定期清缓存：缓存目录默认 7 天无访问即自清，若磁盘紧张可手动把保留天数改 3 天，“设置-传输-缓存天数”。
4. 用 CLI 做无人值守：Linux 机房可通过sunlogin-cli file-send --host 123456 --path /iso --bandwidth 80限速 80 Mbps，断网恢复后自动续传，无需留守。

示例：某电商运维在 02:00 通过计划任务推送 7 GB 镜像到 200 台边缘节点，平均带宽 60 Mbps，中途 18 台因 ISP 抖动掉线；得益于续传，次日 07:00 全部完成，总流量仅多出 1.2 GB，若整包重下则需额外 126 GB。

不适用场景清单：续传反而添乱的四种情况

• 实时数据库目录（如 MySQL data）——切片会导致表文件不一致，即使续传成功，服务也无法启动。
• 加密压缩包分卷（.zip.001）——向日葵按独立文件切片，丢一卷即全包报废，续传无意义。
• Windows 正在写入的 .evtx 日志——文件句柄被占用，切片时返回 0 字节，续传后得到空文件。
• ≤100 MB 的零散脚本——阈值以下不切片，频繁小断网会反复重下，不如一次性发压缩包。

经验性观察：视频剪辑师的中间缓存目录（.prproj_cache）亦不适合续传，因时间线文件会在传输同时被非线性编辑软件改动，导致最终哈希不一致，剪辑软件回退至备份索引，反而增加修复工时。

故障排查：现象→原因→验证→处置

版本差异与迁移建议

v15.5 之前无续传，若企业仍有 3000 台旧被控端，建议分三批升级：先升级主控端→利用“批量换机克隆”把授权迁到新版本→在控制台推送“强制升级”策略。整个迁移过程可保持旧切片兼容，新端续传旧端切片成功率约 87 %，剩余 13 % 因旧切片格式无 SHA256 校验，会整包重下。

若存在无法升级的嵌入式终端（如 Armv7 精简版），可在控制台对其关闭“文件分发”权限，强制走 Samba/NFS 共享，避免新旧逻辑混用导致缓存污染。

验证与观测方法：如何自己跑一遍

1. 准备 1.1 GB 的 Windows ISO，确保主被控端均为 v16.2.2。
2. 在主控端开始传输，进度到 30 % 时，拔掉被控端网线 10 秒再插回。
3. 观察：进度应从 30 % 继续，且缓存目录新增.slice文件。
4. 计算总耗时与重新下载对比，经验性结论：千兆内网可省 65 % 时间，300 KB/s 免费限速环境省 90 % 流量。

为排除缓存命中干扰，建议每次测试前清空 transcache 目录，并在“设置-日志”开 Debug 级别，抓取 slice_seq 与 RTT 变化，方便后续复盘。

未来趋势：官方路线图透露的方向

根据 2026 Q1 官方直播，下一版本将把切片体积动态化：网络 RTT < 30 ms 用 8 MB，RTT > 200 ms 用 1 MB，进一步减少高延迟场景下的重复流量。同时 Linux 端将支持 Btrfs 写时复制，续传时不再物理落盘，而是指向上次子卷，节省 SSD 寿命。个人用户限速也有望从 300 KB/s 提升到 500 KB/s，断点续传对免费用户将更具实用价值。

此外，官方透露正在评估“多端并发续传”试点：同一文件可从主控+中继+边缘节点三源同时拉取不同切片，理论上能把 100 ms 以上国际链路效率再提 18 %，但会额外消耗 10 % 的冗余流量，仅向付费企业版灰度。

收尾：一句话记住核心结论

只要文件≥100 MB、双端≥v15.5、UDP 加速开启，向日葵远控断点续传就会在后台默默工作；你唯一要做的，是别把缓存目录当成垃圾随手清掉——剩下的交给 SDP 智能打洞和 4 MB 切片即可。