摘要

  • 1993 年 11 月的 RFC 1545 提出 LPRT 与 LPSV：在 FTP 数据连接地址里先写地址家族，再写主机地址与端口地址各占多长。旧 PORT 只有六个十进制字节位，前四个给主机，后两个给端口。
  • 新方案用回复码 228 表示长地址被动模式，用 521 说明服务器懂这套命令却不支持请求的地址家族。RFC 1639 在 1994 年 6 月修订并取代首版，把可用的网络家族和传输接口范围写得更清楚。

文件要走，地址表先堵车

FTP 搬运文件时有两条线。一条控制连接负责发命令、收答复；另一条数据连接才搬文件或目录列表。RFC 959 里的 PORT 命令告诉另一端数据线应接到哪里。它使用的地址十分整齐：h1,h2,h3,h4,p1,p2。四段十进制数字合成 32 位互联网主机地址，两段合成 16 位 TCP 端口。每段是一个字节，逗号当隔板。对于当时的 IPv4 与 TCP 组合，六格填得满满当当。

格子一旦印进应用协议，就不会因为底层网络换了新图纸而自动变大。1990 年代初，“下一代 IP”还在几条方案之间争论。有的地址可能更长，有的长度可变；传输层的选择也可能不止 TCP。新地址即便在自己的网络里完全有效，FTP 仍得先把数据连接的目标告诉对方。旧 PORT 只认四格主机、两格端口。瓶颈出现在发文件之前的控制对话里。

David Piscitello 在 1993 年 11 月发表实验性的 RFC 1545，标题叫 FTP Operation Over Big Address Records，缩写 FOOBAR。名字像程序员在白板上随手写的占位词，办法却很具体。LPRT 命令先放地址家族编号，再放主机地址长度、主机地址、端口地址长度、端口地址。各个值仍写成无符号的十进制字节，仍用逗号分隔。变化在于表格开始自报家门：先说自己是哪一族，再说后面两段各有多长。读取一方可以按长度拆开，而不用猜它一定是四加二。

服务器给出的被动模式地址也要跟上。LPSV 请求服务器在一个数据端口监听；服务器以 228 Entering Long Passive Mode 回答，列出地址家族、主机长度、主机地址、端口长度和端口地址。只把客户端的 PORT 替换成大号命令，服务器的回复还挤在旧信封里，协议依旧瘸一条腿。FOOBAR 同时扩展了两端用来约定数据线的语言。

另一个新增号码是 521。服务器可能认识 LPRT 或 LPSV，却没有实现请求中的地址家族。此时它可以回复支持哪些家族。旧的 500、501 留给语法错误。区分很有用：一边是句子写错了，另一边是句子读懂了，但接线柜里没有这种插口。客户端据此可以考虑别的家族；真正的数据连接仍要另外建立。

RFC 1545 列出的当代候选者包括 IP、ST Datagram Mode、SIP、TP/IX、PIP、TUBA。它记录的是 1993 年桌上的选项，不是赛后领奖名单。特别值得看的是端口长度也被单独写进命令。主机地址可能变长，TP/IX 所考虑的传输选择符也可能超过 TCP 的 16 位端口。只放大地址而保留两格端口，下一处卡口便在隔壁。原稿还允许控制连接和数据连接使用不同地址家族；迁移中的两条线可以各走自己的路。

方案很快修订。RFC 1639 于 1994 年 6 月明确取代 RFC 1545。它沿用长地址结构，把家族值 0 到 15 留给 IP 版本相关编号，16 到 255 留给 IANA 分配给其他网络层协议的值；Novell IPX 列在 16。修订版也明确把 FTP 扩展到 TCP 以外的传输接口。FOOBAR 从“IPv4 地址不够长”的补丁，长成了一张给不同网络和传输方式用的地址表。

回头看最初的 PORT h1,h2,h3,h4,p1,p2，问题就在这几个朴素的数字里。应用协议把 32 位主机地址和 16 位端口的假设，藏进了每次开数据连接前必须说的一句话。未来的互联网可以在路由层设计得再宏大，也要让老应用知道新地址该怎么拼写。FOOBAR 拆开六格，给每段标上长度，让对方有机会读懂它。