摘要

  • RFC 1116 让客户端处理行编辑和一部分信号字符，把每个按键若干数据包的交互，收束为每行若干数据包；高时延链路上的键入因此有了本地响应。
  • DO/WILL 同意的是进入子协商，MODE_ACK 确认的是编辑／信号模式，SLC_ACK 确认的是特殊字符映射。三者都不是远端应用的命令回执。
  • 行结束符或 FORWARDMASK 可以释放本地缓冲区；已经发出的前缀无法再本地修改，但是否到达、被解释、获准执行以及是否完成，仍要逐层取证。

速度来自“不再逐键过网”

RFC 1116 对 Linemode 的价值算得很直接。传统的逐字符 Telnet，可能为每个按键付出一对数据包；启用本地编辑后，一整条命令行只需少量数据包。长时延设备不再让使用者等几秒才看见自己的输入，按包收费的网络也少了一笔笔细碎成本。

另一个受益者是远端计算机。某些超级计算机不擅长处理单字符中断，前端机可以承担退格、删行和信号翻译，把远端周期留给向量计算。Linemode 不是简单地少发几个包，而是重新决定哪一侧先处理人机交互。

这份分工使界面变顺，也改变了证据。屏幕上的字符可以完全在客户端回转；远端进程此时甚至还没见到这行字。

当前 RFC Editor 记录保存了 1989 年 8 月的提案及其被替代关系，IETF Datatracker保留文档元数据。1990 年 10 月的 RFC 1184 取代 RFC 1116，新增模式位与可视编辑字符，但仍把行编辑放在客户端。

先同意谈判，才能谈模式

RFC 855 把 Telnet 选项拆成两步。DO 与 WILL 表示双方愿意讨论某个选项，随后 SB／SE 承载参数。任何一方都能以 DONT 或 WONT 结束这项许可。

Linemode 的默认值正是 WONT 与 DONT。存在 TCP 连接、进入 Telnet，乃至知道 34 号选项叫什么，都不能证明本地编辑已启用。成功的 DO/WILL 也只打开子协商入口。

MODE 才指定 EDIT 与 TRAPSIG。正常情况下，服务器提出模式，客户端确认。EDIT 决定谁处理输入行；TRAPSIG 决定客户端是否把某些本地字符翻译成 Telnet 的中断、终止、文件结束或挂起命令。MODE_ACK 的作用是让两端收敛到同一位图。

因此，“接受 Linemode”“启用 EDIT”“命令执行完毕”不是同一事实从粗到细的三种说法。前两项属于协议配置，后一项属于应用结果。

“完成”只修饰本地缓冲区

EDIT 开启时，客户端暂存输入，执行删字、删行等操作，然后只发送已经完成的行。RFC 1184 规定，本地的正常行结束键在传输时形成 CR LF。按下它之前，使用者仍能修改缓冲区，而不必让服务器撤销旧字符。

但结束键不是唯一出口。FORWARDMASK 可由服务器指出哪些 ASCII 字符一出现就应发送现有缓冲；SLC_FORW1 与 SLC_FORW2 再提供两个转发字符。如果本地终端驱动无法精确表达服务器要求的集合，客户端可以接受请求，却在更宽的一组控制字符上转发。

这意味着要记录“实际采用的转发集合”，不能只保存服务器请求。更重要的是时间边界：RFC 1184 明确提醒，某个前缀一旦发出，就不能继续本地编辑。

不可逆发生在客户端，不等于结果已经发生在服务器。字节还要经过 TCP、Telnet 控制解析、远端进程输入、语法判断、权限或策略判断，再可能启动操作、产生输出。编辑器没有观察这些阶段。

SLC_ACK 只确认键位规则

SLC（Set Local Characters）用三元组表达功能、修饰位与 ASCII 字符。级别可以表示不支持、支持但不可改、显式取值或采用默认值。对方同意设置时，返回带 SLC_ACK 的同一映射。

这个 ACK 结束的是配置争议，不是对未来动作的预先签收。它不能证明使用者按过该键；即使按过，也不能证明相应 Telnet 命令抵达；即使抵达，也不能证明远端系统实现了该功能。

RFC 1184 允许不支持 ABORT、EOF 或 SUSP 的系统忽略它们。SLC_FLUSHIN 与 SLC_FLUSHOUT 只是建议，用户界面还可以覆盖建议。一个控制名称被映射、被发送，都不等于进程已停止、文件输入已结束或某段输出确实被清空。

看见回显，仍可能没有一次往返

RFC 857 区分“替对端回显”与系统自行作出的本地回显决定。Linemode 正是利用了后者。CRT 立即出现字符，只证明客户端能显示它。

输出流控也没有被塞入 MODE 位图。RFC 1116 与 RFC 1184 把 FLOW 留给 RFC 1080 定义的独立 Telnet Remote Flow Control 选项。它经另一次同意，决定本地 Telnet 进程是否把 XON/XOFF 当作终端输出门。它不是键盘编辑、应用挂起、TCP 流控或拥塞。

把这些状态机分开，避免了一个“终端正常”标签替回显、编辑、信号、输出和远端进程同时作证。

远端结果需要从接收端重新举证

IANA Telnet Options 登记表至今把 34 号登记为 Linemode，并指向 RFC 1184。登记解决编号协调，不说明某次会话协商过它，也不证明任何实现符合规范。

RFC 854 提供 NVT 与 Telnet 控制命令框架，让数据和信号有共同传输语法。它没有替远端应用定义命令授权与业务结果。RFC 1184 还直言没有讨论安全问题。

可靠记录应保留整条阶梯：本地缓冲完成、前缀发出、服务端收字节、Telnet 解码、进程收输入、策略准入、开始执行、完成执行、输出返回、使用者正确关联响应。Linemode 优化了前半段；它从未让前半段成为后半段的证明。

来源