摘要

  • 早期 Telnet 把字节空间的上半区交给控制信号。后来的协议把命令权力收束到数值 255 的 IAC 前缀，其余 255 个数值便不再因为自身数值而撞上裸露的命令码。
  • 字面数据 255 在线路上写作 IAC IAC。协商 Binary Transmission 可以开放完整八位数据，却不会关闭 Telnet 控制：接收方仍须扫描 IAC 并执行嵌入的命令。

一块红色字节会发号施令，两块才还原成一份数据

设想一段二进制内容经过终端协议，其中恰好含有十进制 255。若接收器把这个数解释成“把下一个字节当作命令”，文件的一部分就会被协议语法吞掉；若它永远把 255 当数据，真正的选项指令又会被漏过。相同的线上数值可能属于两种权力，歧义并不会由 TCP 替双方解决。

Telnet 为此规定了一套很小的语法。单独一个 IAC——Interpret As Command，即“解释为命令”——打开控制状态；IAC 后跟已定义的命令码，就组成命令，有时还需更多字节补全。唯独 IAC IAC 表示一份数值为 255 的普通数据。发送端多写一份，接收端识别成对形式后去掉承担框架作用的那一份。

它并不是通用的“引用下一个字符”。第二个 IAC 在这个位置拥有严格而唯一的含义；IAC 后的其他值仍可能是命令、选项协商或其他控制语法。两个端点共享同一个解析状态，两个线上字节才会还原成一个应用字节。

这条规则解决的也不只是一个罕见数值。它让数据和控制沿同一连接保持先后次序，同时避免永久牺牲大片八位数值空间。

最初的 Telnet 曾把半个字节表交给控制

1972 年 4 月的 RFC 318 围绕网络虚拟终端描述当时正式的 ARPANET Telnet：0 至 127 用于 USASCII，128 至 255 则分配给特殊控制信号。

在主要任务还是连接不同文字终端的时代，这个分界很直观。高位值天然可以表示协议动作，七位 ASCII 足以构成共同显示语言。然而，一旦需要更丰富的字符集或任意二进制内容，问题立刻显现：256 个可能值中，整整一半不能直接交给应用。

RFC 318 提到切换其他码集的办法，也谈到 Transparent 模式，但它同时承认，逃离 ASCII 之后 Telnet 信号怎样解释、怎样返回原状态，并没有完全清楚的定义。数据字母表一扩大，协议识别自身控制的能力就可能随之动摇。

真正的矛盾不在某个终端型号，而在权力分配：若许多裸字节各自携带控制权，数据想使用同样的数值，就必然与这些权力发生冲突。

QUOTE 构想先把问题的轮廓照亮

1973 年 1 月讨论 Telnet 问题的 RFC 435 曾考虑让直接二进制成为默认，并建议增加 QUOTE 字符：它后面的字节一律按数据解释。高位字节仍可以保留为命令，而需要按字面传送的高位值则先加引用。

这项讨论不能倒写成后来已经部署的 IAC 规则。它的重要性在于准确暴露了设计压力：Telnet 需要一条即使数据解释发生改变也仍然可靠的转义边界。

可选方向大致有两个。一个是让大量值继续担任控制，遇到数据碰撞时逐一引用；另一个是只保留一个特殊值作为控制入口，仅当该值作为数据出现时才支付额外成本。后来的 Internet Telnet 选择了第二条路。

IAC 把命令权力压缩进一个前缀

1980 年 6 月发布的 RFC 764 把 Telnet 描述为面向八位字节、运行在单一 TCP 连接上的设施，控制信息穿插在普通数据之间。1983 年 5 月的基础标准 RFC 854 保留了这套结构。

每条 Telnet 命令都从数值 255 的 IAC 开始，随后是命令码。WILL、WON'T、DO、DON'T 之类协商命令还带第三个字节，说明所谈的选项；其他代码可表示子协商结束、空操作、Data Mark、中断、停止输出、擦除字符等基础动作。

这个设计的交换条件写得很清楚：既然协商机制要让数据空间得到更完整的利用，就必须把命令冲突压到最低。IAC 架构下，只有 IAC 本身作为数据时需要重复；其余 255 个字节值就基础命令框架而言都可直接通过。

这里的“透明”必须窄读。它不表示网络虚拟终端会在语义上原样保留所有数值，NVT 仍有字符和行结束约定；它只表示其他值不会仅凭数值就被错认成一条独立 Telnet 命令。协议把原本散落在高位半区的控制权，搬到了一个共同入口之后。

命令正好坐在解释改变的边界上

数据与控制共用字节流也带来一个重要收益：顺序本身可以确定生效时点。RFC 854 要求，当某项选项会影响命令发送方后续数据的处理方式时，协商命令应插在发送方希望新解释开始生效的位置。

接收方收到的不是另一条连接上传来的含糊通知，也不必猜“未来某个时候”从哪里算起。它先读旧解释下的字节，在流中遇到命令，再按新状态读取后面的内容。一条有序会话由此拥有可见的语义分界线。

但这种边界也把责任交给解析器。TCP 可能这次只交付 IAC，下次读取才给出其后的字节；TCP 分段不是 Telnet 记录。实现必须保留“已经看到前缀、尚待后续”的状态，还必须恰好解码一次重复形式：保留两份会破坏数据，把真正的 IAC 命令也压成数据则会抹掉控制。

TCP 维护顺序，Telnet 提供语法；两者都不会自动把连续字节变成完整消息。

子协商仍服从同一条转义纪律

有些选项不能只用同意或拒绝表达。RFC 855 把子协商写成 IAC SB、选项码、参数，最后用 IAC SE 结束。即使接收方不懂参数内容，它仍能借助框架找到这一段的终点。

若参数自身包含 255 怎么办？RFC 855 仍应用通用规则：把它重复。否则参数可能伪造出 Telnet 语法的开头，或与相邻值拼成假的结束标记。

这是一种精炼的分层纪律。选项可以规定参数是什么意思，基础 Telnet 层却始终保有 IAC 的解释权。扩展得到新的语义空间，并不意味着它可以重新定义保护共享字节流的那一个值。

正因为这条边界稳定，无知才不至于致命。只要发送方正确转义字面 255，基础解析器即便看不懂某个选项的载荷，也能跳到真正的 IAC SE。

二进制模式开放八位数据，却没有关闭控制

任意二进制数据是这套前缀设计最直接的考验。RFC 856 定义选项 0，即 Binary Transmission。它按方向分别协商：一方可以同意接收八位二进制，而反方向仍维持原先解释。

选项生效后，未由 IAC 引出的字节按八位二进制数据处理。然而，IAC IAC 仍表示数据值 255，IAC 后跟有效 Telnet 命令也仍是命令。Binary 改变的是数据怎样被理解，不会把整条 TCP 流变成对 Telnet 不透明的管道。

前缀设计的价值在此最为明显。假如 128 至 255 仍各自保留控制意义，二进制模式要么引用半个字母表，要么放弃命令。把控制集中到一个值后，几乎所有二进制数值都能直接通过，选项变化也仍可沿同一连接插入。

所以 Binary 不是“协商完成后就是裸 TCP”，而是 Telnet 框架不变量之下的一种数据约定。

主机要求把这个例外写成不可遗忘的义务

到 1989 年 10 月，RFC 1123 已把相关行为整理为明确的主机要求。Telnet 选项可以出现在数据流任何位置，因此作为数据发送的 IAC 必须重复。成功协商 Binary 之后，接收方仍须扫描 IAC、执行嵌入命令，并要求数据值 255 使用重复形式。

与此同时，别的转换会停止。Binary 模式不应继续普通回车替换或行结束约定。这个对比排除了常见捷径：“二进制”可以关闭文本规范化，却不能关闭 Telnet 解析器。

如今的 IANA Telnet Options 登记表 保存选项命名空间与相应文献，其中 Binary Transmission 是选项 0。登记表不是现实部署率调查。它也提醒我们区分作用域：编号为 255 的选项，与数据流中数值同为 255 的 IAC 字节不是同一个协议对象；数字相同不等于角色相同。

一个重复字节保住了一场有序对话

IAC 重复看似只是线缆上的小细节，实际却分开了三种权力。应用决定数据内容，包括是否含有 255；Telnet 发送层负责把这个值编码成不会误获命令意义的形式；Telnet 接收层拥有解析器，区分重复的数据表示和真实指令。

它不需要中心服务审查会话，也不需要第二条连接传命令。共同层只规定一个很小的不变量，所有选项和数据模式都必须尊重。扩展可以改变回显、终端类型、字符解释或记录边界，却不能悄悄占用 IAC。

成本是永久的：每个实现都要扫描；每份字面 255 都多占一个线上字节；不完整前缀需要保存状态；转义错误可能让之后所有解释失步。收益同样持久：数据和控制可以一起演进，而一个普通数据值不会在没有边界的情况下获得协议权力。

这个字节必须重复自己，不是因为两份让它更有力量，而是因为第一份承担了命令边界，第二份才得以仍然作为数据。

来源与限度

早期半空间方案见 RFC 318，QUOTE 讨论见 RFC 435。RFC 764 与 RFC 854 说明控制穿插的字节流和 IAC 语法；RFC 855 给出子协商转义，RFC 856 说明 Binary 行为，RFC 1123 规定主机义务，IANA 登记表 则维护选项命名空间。这些材料不能证明当前部署份额、具体产品合规性、解析器安全性、加密或认证能力，也不能给出所有主机采用某项行为的同一日期。