摘要

  • 传统 23 端口通常把调用者交给远端主机的通用执行环境；RFC 818 的 107 端口则暴露一个会主动连接别处的 User Telnet 应用。
  • BBN 的 TC68K 让入站 Server Telnet 通过伪终端驱动本机 User Telnet。复用现成程序减少了新代码，但没有把两条 TCP 连接、两次 Telnet 协商与最终应用合成一件事。
  • 成功测试说明当时这条具体链路足以返回统计信息。注册端口、开始监听、识别调用者、允许目的地与证明最终动作，仍是五种不同事实。

PTY 为什么足以改变程序关系

软件并不需要知道字符来自人的手指、RS-232 电缆，还是另一个进程。只要接口呈现出它预期的终端形状，原有 User Telnet 就能继续工作。RFC 818 中最重要的新部件因此不是一种新网际协议，而是本地的 pseudo teletype 驱动。

PTY 对上层应用“装成”终端，内部却把字符流交给另一个进程。Server Telnet 可以终结一条入站网络连接，再把字符送入 PTY；User Telnet 从 PTY 读取，就像面对本地终端，然后发起第二条网络连接。

这不是欺骗协议，而是缩小共同层。网络只需共享 Telnet 语法。本机如何把进程拼起来，仍由本机实现决定。一个局部适配器避免了为全世界增添管理命令。

Telnet 从来不只是一扇远程 shell 门

1980 年的 RFC 764 把 Telnet 描述为连接终端与面向终端进程的双向字节设施。Network Virtual Terminal 提供一套想象中的键盘与打印机，使不同主机不用互相掌握本地终端细节。额外能力通过选项协商；拒绝选项后，双方仍能回到共同的 NVT。

User 与 Server 也是关系词。通常，物理终端所在主机是 User，提供服务的一方是 Server；但在终端对终端、进程对进程时，发起通信的一方也可以叫 User。它不是机器的永久身份。

远程登录的惯例把 Server 放在 23 端口。连接成功后，调用者通常面对 TOPS-20 EXEC、Unix shell 或别的通用执行环境。先进入主机，再选择程序。

这套惯例对通用计算机自然，对小型网络设备却可能是假设过度。设备若没有 executive，就不必为了符合 23 端口的想象而制造一个。

107 端口找到的是“会发起连接的程序”

1982 年 11 月的 RFC 818 直接处理小主机。某些机器功能有限，没有通用 executive，却有一个足够有用的专门应用，值得拥有 well-known port。

这个应用是 User Telnet。选择提供 Remote User Telnet 服务的主机在 107 端口接收入站连接，入站仍使用 Telnet。调用者抵达的能力，却是主机内部能作为 User 再向外建立 Telnet 连接的应用。

“客户端成为服务”并非把监听与发起混成一个角色。外侧仍有接收连接的 Server Telnet；内侧仍有发起下一条连接的 User Telnet。107 端口只为这套组合提供约定入口。

端口号回答“去哪里找”。它不回答“谁可以来”“内部程序可以去哪里”“目标执行了什么”。这些问题若被一个数字吞并，协调便会伪装成权力。

TC68K 是运行中的证据

RFC 818 给出的 BBN TC68K 不是抽象框图。它以 Motorola MC68000 为核心，拥有一条网络连接、十六条 RS-232 终端连接和一个可编程计时器。Micro-Operating System 上运行 IP、ICMP、TCP 与 Telnet。

设备已有 User TC-Telnet：本地终端用户可借它连接网络主机。它也有 Server Telnet，为本身不懂网络的打印机、绘图仪和计算机提供前端。

BBN 在多栋建筑中部署 TC68K，需要远程测试某一台。工程师把 Server Telnet 和 User Telnet 背靠背连接。操作员先连入远端 TC68K，经过 PTY 后，在 User TC-Telnet 看来就像坐在该设备旁的本地终端，于是可以使用它原本的外连能力并读取标准应用保存的统计信息。

文档说，唯一需要增加的软件是 PTY 驱动。这句话不能扩写为“系统没有风险”，但它准确展示了经济性：最小本地适配让现有运行代码产生新组合，不必把站点特有的运维逻辑塞进共同协议。

一个屏幕里其实有两条连接

从人眼看，字符输入与远端输出连续发生。从协议看，至少有四个步骤：操作员一侧 User Telnet 发起第一条 TCP；TC68K Server Telnet 终结它；PTY 把本地字符流交给 TC68K User Telnet；后者发起第二条 TCP。

两条连接分别拥有序号、重传、关闭与 Telnet 选项状态。第一条连接收到字符，不等于第二条目标应用完成动作。外侧接受某个选项，也不能自动代表内侧接受。

RFC 818 没有规定万能选项翻译器、端到端身份关联、加密保证或所有故障如何跨 PTY 传播。所谓 back to back 是本地进程拓扑，不是把中间节点从因果链里删除。

1983 年取代 RFC 764 的 RFC 854 保留了 Telnet 的对称观，同时明确说对称是运行原则，不是不可破的铁律。每条连接都有自己的 NVT 和协商。TC68K 对外来调用是 Server，对下一跳是 User，因为两种角色分别属于两条关系。

“路径可用”到底覆盖了什么

RFC 818 说，这套安排能测试两个 TC68K 之间的网络路径，并让操作员接触标准 User TC-Telnet 记录的统计信息。与只探测网络层相比，它确实经过了更多真实部件。

成功意味着：入站服务可达，Server Telnet 处理了足够的协议，PTY 传递了字符，User Telnet 创建了被测外连，目标又返回了足以展示的信息。这个结论有用，也有清晰边界。

它不能证明别的路径、别的时间或别的流量类别同样工作；不能证明所有 Telnet 选项跨桥保持一致；不能证明打印机真的出纸；也不能仅凭 socket 来源识别键盘前的人。若 User Telnet 有能力访问多个目标，路径成功更不等于调用者获得全部访问权。

运维界面倾向于把多层结果压缩成一个绿色状态。证据记录应做相反的事：保留准入、PTY、目的地选择、外连结果和最终应用回执，让结论只能覆盖它实际穿过的边界。

共同语法允许角色不同

1989 年的 RFC 1123 把 Telnet 作为标准远程登录协议来整理，同时分别规定 User Telnet 与 Server Telnet 的职责。所有实现要支持协商与子协商，不理解的选项要明确拒绝，丰富模式失败后必须回到 NVT。

这不是要求双方功能相同，而是要求拒绝后仍有共同底线。正因为共同层很薄，本地可以组合 Server 与 User，而不迫使另一条连接继承全部选择。扩展通过实现与采用成为现实，未部署 107 端口的主机也没有因此“不合规”。

IANA 服务名称与传输协议端口号注册表 目前仍保留 rtelnet、107 端口和 Remote Telnet Service 描述。注册表保存的是共同参照，不是使用率、安全性或产品支持证明。表中的 UDP 行也不能反过来改写 RFC 818；原文要求在连接上使用 Telnet。

串口控制迫使隐藏状态显形

1997 年的实验性 RFC 2217 后来讨论用 Telnet 连接 access server 上的串口。目标可以是调制解调器、打印机、绘图仪或监测设备。字符流这时暴露出不足。

波特率、数据位、奇偶校验、停止位、调制解调器信号和流控都不是普通字符。COM-PORT-OPTION 用标准 Telnet 协商开启一组显式命令。客户端提出设置，服务器处理后报告实际采用的值；这个值可能与请求不同。

TCP ACK 已经证明字节到达。COM-PORT 的回应证明另一件事：本地设备状态已按某个值执行。把两种回执分开，才能避免“运输成功”冒充“控制完成”。

会话结束也不只是 TCP 关闭。RFC 2217 要求 access server 断开远端服务，并把串口参数恢复到管理员规定的已知状态。否则，上一个会话的选择会越过权限寿命，成为下一个人的起点。

本文不把 RFC 2217 宣称为 RFC 818 的直接后继。它是后来的一面镜子：当字符桥开始控制本地硬件时，执行、回报与清理必须获得自己的语义。

入口可以共享，权力不能打包

107 端口的历史不是“注册者拥有服务”。IANA 协调名称；设备运营者决定是否监听；入站层决定是否接纳；User Telnet 在本地目的地政策内发起；目标服务决定响应；最终设备或应用给出完成证据。

RFC 818 的巧妙之处，在于共同层足够小，允许现成程序重新组合。它的风险也来自同一界面：若把看似本地的 PTY 当成身份，把连接当成授权，把端口当成所有权，就会把一条可审计的能力链压扁成未经证明的权力。