摘要

  • FTP 最初只在块模式或压缩模式的帧中插入续传标记，110 MARK 把发送端位置与接收端持久化后的本地状态组成一对。
  • 标记可以携带字符转换的中间状态，而不只是磁盘位置。RFC 1123 的例子甚至要记住 CR 已读、LF 尚未完成转换。
  • RFC 3659 后来为 STREAM 定义八位组计数，并严格限定它只作用于紧随其后的传输；偏移量没有证明文件版本、局部副本或最终结果相同。

等号保存的是对应关系

FTP 把控制和数据分在两条连接上。命令与三位数答复走控制连接，文件内容走临时数据连接。这种结构让接收端能够一边继续收文件，一边把一个可恢复边界报告给控制端。

RFC 1123 纠正了早先对 110 答复的描述。ssss 是曾出现在数据流里的字符串，编码发送端文件系统中的一个位置；rrrr 编码接收端文件系统中与之对应的位置。每个值都由同一系统生成并在将来由同一系统解释。

因此，等号不是要求两个值相等，也没有规定双方换算格式。协调者只需保存这对关系。恢复时，发送端拿回自己的标记，接收端拿回自己的标记，谁也不需要看懂对方的存储模型。

发送方还不得停下来等 110。标准明确说，不能假定标记答复与数据同步。文件继续前进，答复稍后抵达。界面上的最大进度可以领先于最后一个可靠检查点：前者说明“曾经走到哪里”，后者说明“失败后双方能共同回到哪里”。

标记属于应用层的传输框架

RFC 959 区分表示类型、文件结构和传输模式。STREAM 把数据当连续序列，通常通过关闭数据连接表示 EOF。文档指出，这种结束方式本身无法区分正常结束与连接提前断裂。

块模式有自己的边界。每块之前是三个八位组的头部：八位描述符和十六位长度。描述符值 16 表示该块装载续传标记，随后是无空格的可打印字符。它不是文件正文，也不是从 TCP 序列号推导出来的进度，而是 FTP 数据表示内部的专用地标。

块模式和压缩模式还可以在不关闭连接的情况下明确表示文件结束，因此能够承载原始续传机制。RFC 1123 随后把这层依赖说清楚：要在数据流中放标记，就必须使用能表达标记的模式。

这也限定了网络抓包的证明力。TCP 可以说明某条连接的字节交付，却不知道发送程序如何重建输出，也不知道接收程序怎样把网络表示落到本地文件。恢复所需的状态存在于 FTP 端点，而不是仅存在于线上。

接收端先落稳，再铸造自己的标记

收到标记后，RFC 1123 要求接收端先把此前数据强制写入稳定存储，再编码 rrrr。顺序决定了答复的含义：它不是“套接字已经读到这里”，而是“我能按照自己的规则回到这里，并保住此前部分”。

稳定存储不是无限期保留、跨站复制或灾备承诺。标准只要求本地标记与本地可恢复性相符。接收端既然生成这个不透明值，就必须能够在后来重新解释它。

User-FTP 也要持久保存成对标记。RFC 1123 建议在传输开始时创建空的续传控制文件，每收到一对就追加，成功完成后删除。进程崩溃以后，最后一个完整记录成为候选边界。

删除并非清洁习惯，而是语义的一部分。已经完成的文件若仍留下旧检查点，下一次同名传输可能误认它仍有效。检查点必须和原始文件、方向、参数及生命周期绑定。

半个换行揭示了“位置”的真正含义

RFC 1123 用 CRLF 转换说明为什么不能只保存一个数字。ASCII 传输在网络上使用 CRLF，接收系统可能只保存 LF。若标记恰好落在 CR 与 LF 之间，接收端已经看见并丢弃 CR，却还没有完成换行输出。

此时 rrrr 必须同时携带磁盘位置和“CR 已经处理”的转换状态。单纯回到某个文件偏移，会重复、遗漏或破坏换行。可恢复位置是位置加状态，而不是一个裸地址。

RFC 959 面对的主机可能使用不同字符编码、字长、逻辑字节和存储习惯。网络表示提供共同传送格式，却没有让内部文件系统变成同一种东西。不透明标记正好把解释权留给知道本地语义的一方。

这种不透明性并不含糊。相反，它非常精确地限制了权限：发送端只解释发送端的值，接收端只解释接收端的值，协议只保证两者曾在同一边界对应。

方向决定谁保存哪一半

用户向服务器上传时，用户端在流中放置 ssss。服务器提交此前数据，生成 rrrr 并报告这一对。重启时，用户端用 ssss 恢复自己的文件和转换状态，把 REST rrrr 交还服务器。

下载时顺序相反。服务器在流中插入自己的标记，客户端提交局部副本并记录本地位置。恢复时，客户端先恢复本地状态，再把服务器原先生成的标记发回服务器。

FTP 还允许一个用户进程协调两台服务器之间的第三方传输。协调者并不理解任一远端文件系统，只保存两个远端状态的配对，并将各自的值归还各自的系统。

因此协调者拥有的是对应关系的保管责任，不是解释权。若把不同文件、不同会话或不同方向的标记混在一起，字符串本身不会阻止误用。

350 只表示下一步可以继续谈

REST 不传文件。服务器返回 350，只说明它保存了一个参数，等待随后的服务命令。没有新数据因此完成，也没有局部文件因此被验证。

RFC 959 的状态模型让 REST 后接 RETR、STOR 或某些情况下的 APPE。RFC 1123 又区分两类失败：554 可以表示目标系统无法按所给 REST 参数重新定位；555 表示当前 TYPE 或 STRU 与已有文件不匹配。位置正确不代表表示方式正确。

两步操作还会留下残余状态。如果 REST 成功、预定的传输命令却没有发出，下一条不相关操作可能继承旧意图。后来 STREAM 规范把两者必须相邻写成明确约束。

REST STREAM 把常见情况化为算术

RFC 3659 为 STREAM 模式定义了不在数据流里插标记的续传。REST 参数成为十进制整数：紧接着的那次传输有多少八位组不再发送。REST 0 清除续传效果，回到完整文件。

文档示例先设 TYPE I，确认服务器文件未变化，再发送 REST 802816、收到 350，并立即发出 RETR。对二进制八位组流来说，这正是现代用户熟悉的“从偏移处继续”。

可它并未继承成对标记的全部能力。数字没有字符转换状态，没有文件版本身份，也不证明客户端仍保存着完全相同的前缀。它只规定本次传输省略多少八位组。

因此 REST 必须是受影响传输前的最后一条命令。若客户端没能成功发送随后命令，应再次发送 REST；若下一次不续传，应明确发送 REST 0。一个数在语法上有效，也可能等到 RETR 或 STOR 指明具体对象后才发现越界。

上传续传扩大了错误偏移的权力

RETR 时，客户端掌握组装权：它可以重新取重叠部分、丢弃局部文件或另行验证。STOR 时，服务器要把新数据写进已有局部对象，错误偏移可能影响远端内容。

RFC 3659 把 STOR 的 REST 用途限定为完成此前失败的传输。如果偏移不在服务器当前已有数据的末端，结果未定义；如果随后提供的数据甚至不能把目标扩展回原有长度，结果也未定义。服务器若允许 APPE，也必须像 STOR 一样在指定位置写入，而不是盲目追加。

这些限制拒绝把续传变成通用远程编辑接口，却没有提供事务性。再次中断仍会留下新的局部状态。服务器必须自行决定临时对象怎样命名、谁能看见、何时替换、何时清理。

能够定位写入，不等于获得修改某个对象的授权。协议能力和对象控制必须分开。

偏移仍要依赖文件未变的证据

一个完全正确的偏移也可能落在错误版本里。RFC 3659 建议首次 RETR 前记录服务器文件的修改时间，续传前再次比较；STOR 时也可比较局部目标与将要继续发送的源。MLST 能提供更丰富的变化信号。

文档并未把时间戳夸成哈希。客户端与服务器时钟不必同步，要考虑偏差；时间改变可能不意味着最终内容不同，内容也可能改变后又恢复。它是让检查点失效的线索，不是身份凭证。

SIZE 同样只说明当前 TYPE 下的传输长度。两个文件可以长度相同而内容不同。前缀和后缀拼到预期大小，并不能证明它们属于同一版本。

若完整性重要，续传完成后仍需验证整个对象。REST 证明的是协调意图，不是成品真实性。

能力公告只回答“会不会说这种语法”

支持 RFC 3659 STREAM 行为的服务器会通过 FEAT 宣告精确字符串 REST STREAM。这样客户端不会把数字偏移与仅支持块/压缩模式的旧式标记混为一谈。

IANA FTP 命令与扩展登记表 分别保留基础 REST 与 STREAM 的 REST+ 条目。登记说明命令语义和合规分类，不是现实部署统计，也不是具体服务器质量认证。

FEAT 能回答服务器声称支持哪一种形式。它不能回答局部文件是否属于同一版本、用户是否有权覆盖、偏移是否可用、最终内容是否正确。

恢复的价值来自可撤销的中间状态

旧机制保存更多本地语义，代价是更复杂的帧、标记与控制文件。STREAM 机制选取更普遍的八位组坐标，降低协议负担，却把版本判断和最终验证留给客户端。

两者共同承认：检查点的权力小于完整文件。它可以指出从哪里尝试继续，却不能说明文件是什么、谁提供了它、是否值得执行，也不能替代组装后的检查。

续传节省重复工作，但会制造需要治理的中间状态。只有当检查点能够随对象、表示和权限变化而失效时，这份节省才不会变成跨版本拼接。

来源与证据边界

封闭来源证明协议规定、主机要求、STREAM 扩展及登记状态；它们不衡量当今产品支持率、部署率或一次真实传输的完整性。本文不会从 IANA 条目或 FEAT 字符串推断某次续传安全。