摘要

  • RFC 854 把终端行为变成双方的协商：任一端都能请求某个选项，另一端可以接受或拒绝。
  • 网络虚拟终端仍是共同回退，因此两端能力不同，也不会失去共享的基础模式。

分析

远程终端会话把按不同键盘、屏幕和交互习惯设计的机器连在一起。网络能够传送字节，却不能让这些本地设备变得相同。TELNET 的办法是先定义共同起点，再让双方协商如何偏离它。

这一办法在 1983 年 5 月形成了持久规范。Jon Postel 和 Joyce Reynolds 发布 RFC 854，取代 RFC 764。文档把 TELNET 描述为双向、面向八位字节的通信设施，用来连接用户侧终端系统和远端服务器。它的核心抽象是网络虚拟终端（NVT）：不同主机可以先按一组共同约定建立基本会话，再讨论更具体的行为。

NVT 是底线，不是所有终端相同的宣言。RFC 854 允许任一方发起选项请求。四个命令把责任方向说清：DO 要求对端执行某选项；WILL 表示本端将执行它；DONT 和 WONT 则撤回这些状态。若请求遭拒，连接相应部分继续采用 NVT 约定。主机可以说“不”，而不必断开会话。

这一点重要，因为选项不是一个全局开关。通信的两个方向可以处在不同状态：一端可以愿意回显字符，另一端拒绝；一端可以请求二进制传输，对端仍保留默认模式。RFC 856 的二进制传输、RFC 857 的回显和 RFC 858 的 Suppress Go Ahead，展示了如何围绕共同数据流协商小幅改变。RFC 855 要求为选项记录命令、默认值和动机，也明确允许主机自行提出、测试或弃用选项。RFC 880 随后把 TELNET 选项列为可选功能。

对称机制带来灵活性，也藏着循环风险：如果双方都把对方的确认当作新请求，协商就可能无限往返。RFC 854 在协议层设下限制：请求必须表示状态变化，不能只宣告当前模式；若对端请求进入已经启用的模式，就无需再次确认。双方同时提出的请求可以互相构成肯定确认。关闭选项则不能被拒绝，因为双方始终要能回到 NVT。

这套设计把控制权分配得很明确。标准规定共同的字节命令和回退方式；每个端点决定自己是否具备可选能力。互操作性来自双方协商出的共同子集，而不是假设任意两台机器都能用上每种功能。

后来的记录也限制了成功叙事。1989 年的 RFC 1123 要求实现具备协商机制、拒绝不支持的选项、在连接期间继续处理协商，并在协商失败时支持 NVT。它同时记录了持续存在的歧义，包括行结束约定。1990 年 RFC 1143 又提出更系统的协商状态实现方法。可见，共同回退和防循环规则有帮助，却没有消除实现差异，也没有让每种终端组合都无缝工作。

RFC 854 的历史成果比“一个协议让所有终端兼容”更具体：它给异构系统一种有纪律的办法，判断彼此能共同完成什么。基础模式让拒绝变得可承受，协商让扩展成为可能，而二者的边界保留在数据线上。

来源