Summary

  • RFC 1692 提议将发往同一主机的多个短小 Telnet、Rlogin 传输片段合进一个 IP 数据报，以减少包处理与中断负担。
  • 合并后的外层是 IP 协议号 18，按 TCP 端口过滤的普通路由器看不到内部端口。RFC 要求不懂 TMux 的过滤路由器阻断它，或由懂 TMux 的路由器逐段检查。RFC 4450 后来将其列为 Historic。

终端用户敲下一个字符，服务器可能发出一个只载一字节数据的包。几十个会话汇向一两台主机，链路的比特率看上去还宽裕，主机却忙着为每个包收发、检查、触发中断。1994 年的 RFC 1692 给出了刺眼的比较：主机处理一字节包的工作量，与处理 1500 字节包几乎相当。作者要盯的不是每秒多少比特，而是每秒多少包。

Peter Cameron、David Crocker、Danny Cohen 和 Jon Postel 提出的 TMux 把数个短传输片段放进同一个 IP 数据报。每个片段前加四字节小报头，记下长度、原本的传输协议号，以及小报头自身的校验值。外层 IP 头使用协议号 18。接收主机再把各片段拆开交还 TCP 或 UDP，上层会话照常处理。这种优化作用于打包方式，不要求 Telnet 会话改写对话内容。

打包需要等候同伴。第一个片段到来时启动计时器，期限内抵达的其他片段搭车；缓冲区满了就立即发。RFC 建议可配置的 20 至 30 毫秒，认为交互回显大致不能超过十分之一秒的等待。较大片段，例如超过 700 字节，宜单独发送。要是每次只有一个小包，TMux 反倒让它在出站口多等一会儿。

发送方还得确认对方会拆信封。收到对方有效的 TMux 包是一种证明；首次试探可以用一个空数据、协议号 18 的 ENQ 包。未获回应的试探逐步拉长间隔，普通数据报仍能继续发。能力记录也要过期：对方重启后，原来的支持状态未必还在。RFC 甚至安排了先尝试 TMux、超时后由 TCP 以普通数据报重传的路径。

真正的冲突写在 RFC 的安全章节。依据 TCP 端口号过滤的路由器只看见外层协议号 18，看不见里面各片段的端口。同一条 TCP 连接的大包可能不经 TMux，照普通 IP/TCP 路径被另一个规则处理。RFC 的处置很明确：懂端口过滤却不懂 TMux 的路由器应双向阻断 TMux；懂 TMux 的路由器则可拆包，逐段剔除不符合规则的内容。省掉重复报头，并没有省掉审查每段内容的责任。

TMux 起初是 Proposed Standard。2004 至 2005 年，一次对旧提案的社区清理审查其实现和维护前景；RFC 4450 将 TMux 列入转为 Historic 的名单，RFC Editor 状态页 如今也这样标注。故事里的账很简单：主机少处理几个包，路由器却少看见几条端口信息。优化与规则在同一只信封上相撞。

来源