一般考量 (General Considerations)

TELNET 连接是一种传输控制协议 (Transmission Control Protocol, TCP) 连接, 用于传输数据并夹杂 TELNET 控制信息。

TELNET 协议建立在三个主要思想之上: 第一, "网络虚拟终端 (Network Virtual Terminal)"的概念; 第二, 协商选项的原则; 第三, 对终端和进程的对称视图。

当 TELNET 连接首次建立时, 假定每一端都在"网络虚拟终端 (Network Virtual Terminal, NVT)"处发起和终止。NVT 是一种虚构的设备, 提供标准的、全网范围的规范终端中间表示。这消除了"服务器"和"用户"主机需要保存彼此终端特性和终端处理约定信息的需要。所有主机 (用户主机和服务器主机) 都将其本地设备特性和约定映射为在网络上与 NVT 交互的样子, 并且每一方都可以假设对方进行了类似的映射。NVT 旨在在过于受限 (没有为主机提供足够丰富的词汇来映射到其本地字符集) 和过于包容 (惩罚使用简陋终端的用户) 之间取得平衡。

注意: "用户"主机是物理终端通常连接的主机, "服务器"主机是通常提供某种服务的主机。作为另一种观点, 即使在终端到终端或进程到进程的通信中, "用户"主机也是发起通信的主机。
协商选项的原则考虑到了这样一个事实: 许多主机希望提供超出 NVT 可用范围的附加服务, 许多用户拥有复杂的终端并希望获得优雅而非最简的服务。独立于但结构化于 TELNET 协议内的各种"选项"将被批准, 并可与"DO、DON'T、WILL、WON'T"结构 (下文讨论) 一起使用, 以允许用户和服务器就其 TELNET 连接使用更精细 (或许只是不同) 的约定集达成一致。此类选项可以包括更改字符集、回显模式等。

建立选项使用的基本策略是让任一方 (或双方) 发起某个选项生效的请求。另一方可以接受或拒绝该请求。如果请求被接受, 选项立即生效; 如果被拒绝, 连接的相关方面保持 NVT 规定的状态。显然, 一方总是可以拒绝启用某个选项的请求, 但绝不能拒绝禁用某个选项的请求, 因为所有各方都必须准备好支持 NVT。

选项协商的语法设置为: 如果双方同时请求某个选项, 每一方都会将对方的请求视为对自己请求的肯定确认。
协商语法的对称性可能导致不终止的确认循环 —— 每一方将收到的命令不视为确认而视为必须确认的新请求。为防止此类循环, 以下规则适用:

a. 各方只能请求更改选项状态; 即, 一方不得仅仅为了宣布自己处于某种模式而发送"请求"。

b. 如果一方收到看似要求进入其已处于的某种模式的请求, 则不应确认该请求。这种不响应对于防止协商中的无限循环至关重要。对于更改模式的请求必须发送响应 —— 即使模式没有改变。

c. 每当一方向另一方发送选项命令时, 无论是作为请求还是确认, 如果使用该选项将对从第一方发送到第二方的数据处理产生任何影响, 则该命令必须在数据流中希望其生效的位置插入。(应注意, 从发送请求到收到确认 (可能是否定的) 之间会经过一段时间。因此, 主机在请求选项后可能希望缓冲数据, 直到了解请求是否被接受或拒绝, 以便向用户隐藏"不确定期"。)

当 TELNET 连接首次建立时, 选项请求可能会来回涌现, 因为每一方都试图从另一方获得尽可能好的服务。但除此之外, 选项可用于动态修改连接特性以适应不断变化的本地条件。例如, NVT (如后文所述) 使用一种非常适合许多"逐行"应用程序 (如 BASIC) 但不适合许多"逐字符"应用程序 (如 NLS) 的传输规程。服务器可能会在适合本地进程时选择承担"逐字符"规程所需的额外处理器开销并协商适当的选项。但是, 当不再需要详细控制时, 它可以切换 (即协商) 回 NVT, 而不是永久承担额外的处理开销。

如果进程对拒绝的响应是简单地重新请求该选项, 则进程发起的请求可能会刺激不终止的请求循环。为防止此类循环发生, 被拒绝的请求不应重复, 直到某些事情发生变化。在操作上, 这可能意味着进程正在运行不同的程序, 或者用户给出了另一个命令, 或者在给定进程和给定选项的上下文中有意义的任何事情。一个好的经验法则是, 重新请求只应作为来自连接另一端的后续信息的结果或在本地人工干预要求时发生。

选项设计者不应感到受限于选项协商可用的有限语法。简单语法的意图是使选项易于拥有 —— 因为相应地也很容易对其表示无知。如果某个特定选项需要比"DO、DON'T、WILL、WON'T"所能实现的更丰富的协商结构, 正确的做法是使用"DO、DON'T、WILL、WON'T"来确认双方都理解该选项, 一旦完成, 就可以自由使用更复杂的语法。例如, 一方可能发送请求以更改 (建立) 行长度。如果被接受, 则可以使用不同的语法来实际协商行长度 —— 此类"子协商"可能包括最小允许、最大允许和期望行长度的字段。重要的概念是, 此类扩展协商绝不应在某些先前的 (标准) 协商确认双方都能解析扩展语法之前开始。

总之, WILL XXX 由任一方发送, 表示该方希望 (提议) 开始执行选项 XXX, DO XXX 和 DON'T XXX 是其肯定和否定确认; 类似地, DO XXX 发送以表示希望 (请求) 另一方 (即 DO 的接收方) 开始执行选项 XXX, WILL XXX 和 WON'T XXX 是肯定和否定确认。由于 NVT 是没有启用任何选项时的状态, DON'T 和 WON'T 响应保证将连接保持在双方都能处理的状态。因此, 所有主机都可以将其 TELNET 进程实现为完全不知道不支持的选项, 只需对任何无法理解的选项请求返回拒绝 (即拒绝)。

尽可能地, TELNET 协议已被设计为服务器-用户对称的, 以便它能轻松自然地涵盖用户-用户 (链接) 和服务器-服务器 (协作进程) 的情况。希望但不绝对要求选项进一步推进这一意图。无论如何, 明确承认对称性是一个操作原则而非铁板钉钉的规则。

应参阅配套文档"TELNET 选项规范"以获取有关建立新选项程序的信息。