当 TCP 服务器在端口上接受套接字时，它会获得一个新的套接字来与该客户端一起工作。
接受套接字对该端口仍然有效，并且可以接受该端口上的更多客户端。
为什么最初的 FTP 规范RFC 959 决定同时创建控制端口和数据端口？
是否有任何理由在类似的自定义协议中这样做？
在我看来，这可以很容易地在单个端口上指定。
考虑到防火墙和 NATS 与 FTP 的所有问题，似乎单个端口会好得多。
对于一般协议实现，我认为您想要这样做的唯一原因是您可以从不同于命令的主机提供文件。
【问题讨论】：
标签： ftp protocols network-protocols
在 FTP 的情况下，它不仅是一个不同的端口，还可能是一个不同的主机，这可能是因为 RFC 959：
In another situation a user might wish to transfer files between
two hosts, neither of which is a local host. The user sets up
control connections to the two servers and then arranges for a
data connection between them. In this manner, control information
is passed to the user-PI but data is transferred between the
server data transfer processes. Following is a model of this
server-server interaction.
Control ------------ Control
---------->| User-FTP |<-----------
| | User-PI | |
| | "C" | |
V ------------ V
-------------- --------------
| Server-FTP | Data Connection | Server-FTP |
| "A" |<---------------------->| "B" |
-------------- Port (A) Port (B) --------------
Figure 2
The protocol requires that the control connections be open while
data transfer is in progress. It is the responsibility of the
user to request the closing of the control connections when
finished using the FTP service, while it is the server who takes
the action. The server may abort data transfer if the control
connections are closed without command.
【讨论】：
当用户启动与远程主机的 FTP 会话时，FTP 首先在服务器端口号 21 上建立控制 TCP 连接。FTP 的客户端通过此控制连接发送用户标识和密码。 FTP 的客户端还通过控制连接发送更改远程目录的命令。
当用户请求文件传输（到远程主机或从远程主机传输）时，FTP 在服务器端口号 20 上打开一个 TCP 数据连接。FTP 通过数据连接仅发送一个文件，然后关闭数据连接。如果在同一会话期间，用户想要传输另一个文件，则 FTP 会打开另一个数据 TCP 连接。因此，使用 FTP，控制连接在整个用户会话期间保持打开状态，但会为会话内传输的每个文件创建一个新的数据连接（即，数据连接是非持久的）。
【讨论】：
这样做的最初理由是，您可以：
的确，他们可以通过指定集成到 FTP 协议的复杂多路复用协议来达到相同的结果，但由于当时 NAT 不是问题，他们选择使用已经存在的 TCP 端口。
这是一个例子：
Alice 想要 Bob 的两个文件。 Alice 连接到 Bob 端口 21 并请求文件。 Bob 准备好后打开与 Alice 端口 20 的连接并将文件发送到那里。同时，Charles 需要 Alice 服务器上的文件。 Charles 连接到 Alice 上的 21 并请求文件。 Alice 准备好后连接到 Charles 的 20 端口，并发送文件。
如您所见，端口 21 用于客户端连接到服务器，端口 20 用于服务器连接到客户端，但这些客户端仍然可以在 21 上提供文件。
两个端口的用途完全不同，为了简单起见，他们选择使用两个不同的端口，而不是实现协商协议。
【讨论】：
IIRC，问题不在于 FTP 使用两个（即多个）端口。问题是控制连接是由客户端发起的，而数据通道是由服务器发起的。 FTP 和 HTTP 之间最大的区别在于，在 HTTP 中，客户端拉取数据，而在 FTP 中，服务器推送数据。 NAT 问题与通过不知道预期连接的防火墙推送数据的服务器有关。
FTP 为控制和数据使用单独的端口是相当优雅的恕我直言。想想 HTTP 中围绕控制和数据多路复用的所有令人头疼的问题——想想尾随标头、围绕流水线请求的规则、连接保持活动等等。通过明确分离控制和数据可以避免大部分情况，更不用说可以做一些有趣的事情，例如加密一个而不是另一个，或者使控制通道具有比数据更高的 QoS。
【讨论】：
IETF 已禁止为新协议分配多个端口的做法，因此我们将来可能不会看到这种情况。
较新的 IP 协议（例如 SCTP）旨在解决 TCP 可能导致使用多个端口的一些缺点。 TCPs 'head-of-line' 阻塞可以防止你有多个单独的请求/流在运行，这对于某些实时应用程序来说可能是一个问题。
【讨论】：
您应该看看 RTSP + RTP 协议。这是一个类似的设计：每个流都可以在不同的端口上发送，关于抖动、重新排序等的统计信息在另一个端口上发送。
另外没有连接，因为它是 UDP。然而，它是在防火墙已经有些陈旧的时候开发的（对不起我的英语），所以开发了一种模式，所有这些连接都可以嵌入到一个带有 HTTP 语法的 TCP 连接中。
你猜怎么着？多端口协议比 http 多路复用协议更简单 (IMO) 实现，并且它具有更多功能。如果你不关心防火墙问题，既然已经存在一个（TCP端口），为什么还要选择复杂的复用方案呢？
【讨论】：
FTP 的历史非常悠久，早在 70 年代初期，它就是最早的 ARPANET 协议之一（例如，请参阅 RFC114 from 1971）。现在可能看起来很奇怪的设计决策在那时变得更有意义。连接速度要慢得多，使用可用的网络技术执行“带外”连接控制似乎是一个不错的举措。
当前的RFC959 包含一个很好的历史部分，链接到早期的 RFC，如果你想做一点考古的话...
【讨论】：
FTP 是在现代防火墙的愚蠢程度难以想象的时候设计的。 TCP 端口用于此功能；在单个 IP 上多路复用多个连接。它们不是访问控制列表的替代品。它们也不打算将 IPv4 扩展到 48 位地址。
任何新的非 IPv6 协议都必须处理当前的混乱，因此它应该坚持使用一个小的连续端口范围。
【讨论】：
与许多较旧的有线协议一样，FTP 适合人类使用。也就是说，从终端会话中使用 FTP 非常容易。 FTP 的设计者预计用户可能希望在数据传输时继续使用远程主机。如果命令和数据通过同一个通道，这将很困难。
【讨论】：
因为 FTP 允许单独的控制和数据。 IIRC，按照最初的设计，您可以有 3 个主机：主机 A 可以要求主机 B 向主机 C 发送数据。
【讨论】：
我认为他们这样做是为了在传输发生时您可以继续使用服务器并轻松启动新传输（如果您的客户端可以支持的话）。
请注意，被动模式几乎可以解决所有防火墙/NAT 问题。
【讨论】：
在我看来，这只是一个糟糕的设计选择。在发明它的旧时代，防火墙和 NAT 不存在……如今，真正的问题更多是“为什么人们还想使用 FTP”？ FTP 所做的一切都可以使用 HTTP 以更好的方式完成。
【讨论】：
FTP 是一个旧协议。这真的是唯一的原因。设计者认为数据端口上流过的数据量会使其无法及时发送控制命令，因此将其作为两个端口进行。防火墙，尤其是 NAT，出现的时间要晚得多。
【讨论】：