摘要

  • RFC 1078 提议 TCPMUX：客户端连接 TCP 端口 1，发送不区分大小写的服务名及 CRLF；服务器回一个 + 或 ，可附解释。+ 后在原连接上开始所选服务的协议， 后关闭连接。
  • HELP 会列出该主机提供的服务名。已有专属端口的服务继续开放原端口，也可选择进驻端口 1；私有协议则能用名字联系服务，免去另领一个正式端口。1987 年号码分配表 当时仍把端口 1–4 列为未分配。

早期互联网用端口号给服务编门牌。来客想找熟悉的 TCP 服务，就敲它的知名端口。1987 年 5 月的官方号码分配表把已分配的联系端口放在最低八位范围，1–4 号当时尚空。TCP 的数字空间远比这大；紧俏的是低位、有人管理、大家都认得的那一组门牌。一个私有服务也许有本事干活，却未必值得为它挂一块正式铜牌。

Mark Lottor 在 1988 年 11 月的 RFC 1078 提出了另一种接待方式：TCP Port Service Multiplexer，简称 TCPMUX。主机在 TCP 端口 1 开一个入口。客户端先建立连接，再发服务名，后面接回车和换行。名字不区分大小写。第一句话短得像前台登记簿上的一行，后面却决定这条连接究竟归谁。

回答也很节制：+ 表示找到服务，可以附一句解释并以 CRLF 结束，随后所选服务的协议就在这条连接上开场； 表示没能接待，也可附解释，然后关门。客户端已经连到了主机。端口 1 要解决的是下一层问题：这条已建立的对话应该交给哪项服务？它在数据流开头完成分流，之后让真正的服务说话。

RFC 的实现说明又把“谁答应接客”分得更细。找不到服务时，拒绝通常由多路复用器发出；肯定答复通常由被调用的服务发出。前台有权说“查无此人”，办公室里的人才说“我来谈”。这避免把前台名单和后面的实际接待混为一谈。一个 + 很小，它最好靠近真正要接手连接的程序。

大厅还有一份目录。HELP 是保留名字；客户端报它，服务器就逐行列出支持的服务名，再结束连接。这是一场问路对话，跟进入某项服务之后的长谈分开。目录列的是这台主机在这个入口提供的名字。RFC 同时要求：官方号码表中已有的服务名继续保持原来的定义，接待台无权把熟悉的名字借给别的生意。

老服务的正门也得留着。RFC 1078 明确说，已有独立分配端口的服务必须继续在原端口提供服务，也可以自愿在端口 1 接客。知道旧号码的客户端照旧直达。共用大厅主要给未来服务和私有协议一条新路，它给既有地图加入口，而不是一夜之间改掉整条街的门牌。

私人起名也要讲规矩。Lottor 建议挑选很可能独一无二的名字，比如在协议名之前加组织名；不同版本可在名字末尾加版本号。若两家办公室都叫“档案室”，前台只能按本地主机的名单猜。组织前缀听起来不够潇洒，却能少走许多错走廊。官方名字由登记表守住含义，私有名字则靠起名者避让冲突。

这项提案的赌注装在一条连接里：来客只知道一个数字门口，报一个服务名，收到极短的答复，然后进入具体协议或转身离开。HELP 介绍大厅，+ 完成交接， 结束尝试。端口 1 像一名老练前台，用一个受管理的入口接待多种本地服务，同时把老服务的正门原封不动地留在街上。