4. 断点续传核心概念

在工业现场，网关往往需要把采集到的设备数据、报警记录、批次文件或日志上传到云端平台。网络并不会一直稳定：4G 信号会抖动，专线会维护，云端接口会限流，甚至网关自身也可能重启。如果每次中断都从第一个字节重新发送，不仅浪费流量，还会让大量历史数据永远追不上实时数据。断点续传正是为了解决这个问题而存在的一套传输机制。

一、断点续传的定义

断点续传（Resumable Transfer）是指：当一次数据传输因某种原因中断后，发送方能够记录已经成功传输到的位置，并在下一次传输时从该位置继续发送剩余部分，而不是从头开始。它的本质是把一次“大传输”拆解为可验证、可恢复的“分段传输”，并让传输进度成为可持久化的状态。

在工业网关场景中，断点续传通常包含三个关键要素：

• 传输单元标识：每个待上传对象都有唯一标识，例如 batch_id、文件名、消息序列号或时间窗口编号。
• 进度记录：网关本地持久化记录“已确认成功”的偏移量、分片序号或最后一条记录 ID。
• 续传协商：重新连接后，网关与云端确认从哪个位置继续，避免重复或遗漏。

二、传输中断的常见类型

不同中断类型对续传策略的影响不同。工业网关常见的中断可以归纳为以下几类：

可以看到，真正危险的并不是“断”，而是“断得不明不白”：发送方不知道接收方到底收到了多少。因此，断点续传的设计重点在于确认机制和进度持久化。

三、续传的基本条件

要让续传成立，至少需要满足以下条件：

1. 数据可分段：待传数据能够被切分为有明确边界的片段，例如按文件偏移量、按消息序号、按时间窗口。
2. 片段可标识：每个片段有唯一编号或偏移量，接收端能判断“这个片段我是否已经收过”。
3. 进度可持久化：网关必须把已确认的进度写入本地存储，如 SQLite、文件或 KV 存储，不能只放在内存。
4. 接收端可查询或可协商：云端能告诉网关“你已经传到第 N 片”，或者网关能根据本地记录直接请求第 N+1 片。
5. 幂等或去重能力：重复发送同一片段时，接收端不会产生重复数据或重复业务动作。

四、与重传的区别与联系

重传（Retransmission）通常指某个数据包、某个请求或某批数据发送失败后，重新发送同一内容。它关注的是“这一次发送是否成功”；而断点续传关注的是“整个传输任务在多次中断后如何继续”。两者不是对立关系，而是层次不同、互相配合。

• 重传是局部动作：例如 TCP 超时重传、HTTP 请求失败后重试、某个分片校验失败后重发该分片。
• 断点续传是任务级机制：它管理的是整个上传任务的进度、状态和恢复点。
• 联系：断点续传内部通常会使用重传机制来处理单个分片的失败；而重传如果没有进度记录，就退化成“从头再来”。

可以用一个简单的关系来理解：重传解决“这一片没发成功”，断点续传解决“整个文件发到一半断了，接下来从哪里发”。没有重传，续传无法处理分片级失败；没有续传，重传会在长任务中造成大量重复流量。

五、典型场景与误区复盘

假设某网关每 5 分钟生成一个数据文件，通过 HTTPS 上传到云端。某次上传到第 3 个分片时 4G 信号中断，网关本地 SQLite 中记录了“分片 1、2 已确认，分片 3 未确认”。网络恢复后，网关不需要重新上传整个文件，而是从分片 3 开始继续发送。云端根据分片编号去重，最终文件完整落库。这就是断点续传的典型价值。

常见误区有三个：

• 误区一：把“发送完成”当成“传输成功”。如果网关发完就推进进度，但云端没有收到，续传时就会跳过数据，造成丢数。必须等接收端确认后再推进。
• 误区二：进度只存在内存里。网关重启后内存清零，进度丢失，只能从头再来。工业现场必须把进度写入非易失存储。
• 误区三：没有幂等设计。续传时重复发送边界分片，云端如果直接插入，就会产生重复记录。接收端需要按唯一键去重或使用 upsert。

总结来说，断点续传是工业网关本地缓存体系中的关键一环：它把网络的不确定性转化为可管理的传输状态，让数据在弱网、重启和限流条件下依然能够最终一致地到达云端。理解它的定义、中断类型、成立条件和与重传的关系，是后续实现可靠上传策略的基础。