在协议设计中,为什么要使用2个端口？

当TCP服务器在端口上执行套接字接受时,它将获得一个与该客户端一起使用的新套接字.
接受套接字对该端口仍然有效,并且可以接受该端口上的其他客户端.

为什么原始FTP规范RFC 959决定同时创建控制端口和数据端口？

是否有任何理由在类似的自定义协议中执行此操作？

在我看来,这可以在一个端口上轻松指定.

考虑到防火墙和使用FTP的NATS的所有问题,似乎单个端口会好得多.

对于一般协议实现,我认为你想要这样做的唯一原因是你可以从不同于命令的主机提供文件.

这背后的最初理由是,您可以:

在传输数据时,继续在控制连接上发送和接收控制指令.

同时激活多个数据连接.

服务器决定何时准备好向您发送数据.

确实,他们可以通过指定集成到FTP协议的复杂多路复用协议来实现相同的结果,但由于当时NAT是非问题,他们选择使用已存在的TCP端口.

这是一个例子:

爱丽丝想要Bob的两个文件.Alice连接到Bob端口21并要求提供文件.当Bob准备就绪时,Bob打开与Alice端口20的连接并将文件发送到那里.同时,Charles需要Alice的服务器上的文件.Charles连接到Alice的21并要求提供该文件.当准备好时,Alice连接到Charles上的端口20,并发送文件.

如您所见,端口21用于连接到服务器的客户端,端口20用于连接到客户端的服务器,但这些客户端仍然可以在21上提供文件.

两个端口都用于完全不同的目的,并且为了简单起见,他们选择使用两个不同的端口而不是实现协商协议.

因为FTP允许单独的控制和数据.IIRC,最初设计,你可以有3个主机:主机A可以要求主机B向主机C发送数据.

FTP是在现代防火墙的愚蠢不可思议的时候设计的.TCP端口用于此功能; 在单个IP上复用多个连接.它们不能代替访问控制列表.他们不打算延长IPv4的48个地址,无论是.

任何新的非IPv6协议都必须处理当前的混乱,因此它应该坚持一小部分连续的端口.

FTP有着悠久的历史,是70年代早期的第一个ARPANET协议之一(例如,参见1971年的RFC114).现在看起来很奇怪的设计决策更有意义.连接速度要慢得多,并且使用可用的网络技术进行"带外"连接控制似乎是一个很好的举措.

目前的RFC959包含了一个关于历史的好部分,如果您喜欢做一些考古学,可以链接到早期的RFC.