Summary

  • FTP 在控制连接上协商命令，再用另一条数据连接传输文件。
  • RFC 1579 借用已有的 PASV 命令改变第二条连接的发起方向：客户端侧过滤更容易通过，但服务器必须接受数据端口上的入站连接。

FTP 可以在一条连接上说“把这个文件发给我”，而文件却不在这条连接上传输。这种分离原本就是协议设计的一部分。它带来一个实际结果：登录成功并收到 RETR 的肯定答复，也不表示文件字节一定能到达；FTP 还需要按约定方向建立第二条 TCP 连接。

1985 年的规范 RFC 959 将命令与答复交给控制进程，将文件传输交给数据进程。常见方式是客户端先连接服务器的控制端口，通常是 21 端口。传输前，客户端可以用 PORT 告知自己的地址和监听端口；随后服务器向客户端发起数据连接。数据连接与控制连接分开，因此防火墙允许前一条，并不会自动允许后一条。

FTP 早已定义另一种方式。客户端发送 PASV 后，服务器的数据进程会在一个非默认端口监听，返回地址和端口，再由客户端连接过去。数据仍通过第二条连接传输，变化的是谁拨出连接。被动模式早于它作为防火墙解决办法受到推荐多年。

到 1994 年，实际客户端的行为并不总是遵循最初的默认安排。Steven Bellovin 在 RFC 1579 中记载，客户端通常为每次传输开启新的数据连接，为避开 TCP TIME-WAIT 等待而挑选新端口，再用 PORT 告知服务器。数据通道于是看起来像是对一个随机端口的入站呼叫。即便用户已在控制通道完成认证，防火墙也可能只放行少数入站服务，而拒绝这次回连。

RFC 1579 建议厂商修改 FTP 客户端，包括 Gopher 代理，让它们用 PASV 而不是 PORT。这样数据通道就由客户端向外发起。对客户端一侧的防火墙而言，放行已发起的出站连接，通常比接受发往随机客户端端口的未请求连接容易。备忘录不要求修改线上的协议：命令早已存在，两种方式在传输前都要进行类似的协商。

这只是移动了难处理的边界，并未消除它。被动模式要求服务器在传输用端口接受入站连接。RFC 1579 承认服务器侧防火墙也可能因此遇到问题。作者的理由偏向运维可行性：服务器数量少于客户端，管理员可以限制数据端口范围。这是关于把暴露面放在哪里管理的建议，不是所有服务器和防火墙都已采用的证据。

标准文件能帮助区分“必须支持的能力”与“实际普及的行为”。1989 年发布的 RFC 1123 要求 FTP 服务器实现 PASV，并解释其回复应如何解析；它也提醒，回复格式并未充分标准化。RFC 1579 后来表示，当时至少有两个相互独立的客户端实现已作修改。这两条记录都没有衡量改变模式的用户或站点有多少。1994 年的材料证明有一项建议和少量实现，不能证明全网完成了迁移。

FTP 有两条不同的运行路径。控制连接承载凭证、命令和结果回复；数据连接承载目录列表或文件。“正在打开数据连接”不是文件本身，登录成功也不是传输完成的证据。排障时必须同时跟踪两个 socket，并确认哪一端应该发起各自连接。

因此，RFC 1579 的历史意义不只是“防火墙破坏了 FTP”。协议原先就允许选择数据连接的发起方向，防火墙让这种选择变得关键。PASV 把发起动作放到客户端防火墙更可能允许的一侧，同时要求服务器运营者管理一组受限的入站端口。协议没有改变，运维负担换了位置。

Sources