Chinaunix

标题: ftp协议为什么开两个端口呢？ [打印本页]

作者: gobbin 时间: 2009-03-30 14:19
标题: ftp协议为什么开两个端口呢？
我知道一般说法是一个用来传数据，一个用来传命令
但是实际上好像有别的原因啊
哪位给解释下

作者: ssffzz1 时间: 2009-03-30 14:28
不是技术问题了。

先前只有主动模式了。
后来因为防火墙之类的问题，又提出了被动模式。

其实就一个端口也未尝不可了。没技术方面的障碍了。

改了。

[ 本帖最后由 ssffzz1 于 2009-4-10 16:00 编辑 ]

作者: kentchoi 时间: 2009-03-30 15:05
这样开发显得很高深，，，

控制通道跟传输通道分开，

还带着 port 命令跟 passive 命令，，，那么宝贵的1024以下的端口，ftp自己就占据了2个。。。

作者: rainbow 时间: 2009-03-30 15:23
标题: 回复 #1 gobbin 的帖子
这个协议太老了，设计者的思想在当时是好的：命令通道仅仅处理命令，时间短；数据通道处理数据时间长。
可是在现在，尤其是有防火墙的时候，再加上客户端在局域网内时，这个设计很显然过时了，很麻烦的。

作者: gobbin 时间: 2009-03-31 13:41
这样开发显得很高深，，，
........................................
感觉ftp协议应该改进改进了

作者: benjiam 时间: 2009-04-01 15:06
ok 我在接受ftp数据的时候，我要停止接收数据，这时候我应该怎么做？

我发送一个命令表示我要paush, 然后接受到什么认为是对方停止了，我如何区别是网络延迟还是对方停止？

作者: ssffzz1 时间: 2009-04-01 15:10
确认对方停止是有信令的。
而网络延迟要么丢包，要么延后到达。如果在允许的超时范围内，则可以正常通讯，如果丢包超过允许范围，则中断。

作者: amxiaomao 时间: 2009-04-04 11:58

原帖由 ssffzz1 于 2009-3-30 14:28 发表
不是技术问题了。应该是设计者脑子进水吧。

先前只有主动模式了。
后来因为防火墙之类的问题，又提出了被动模式。

其实就一个端口也未尝不可了。没技术方面的障碍了。

他的脑子没有进水,历史遗留问题！

起先的网络，是半双工，所要用两二端口！

[ 本帖最后由 amxiaomao 于 2009-4-4 12:05 编辑 ]

作者: imhr 时间: 2009-04-04 15:51
控制通道跟传输通道分开?

作者: ssffzz1 时间: 2009-04-04 16:32
标题: 回复 #8 amxiaomao 的帖子
是否半双工和这个没关系的。

我就问你，那个时候为什么WEB服务器就一个80端口也能正常工作呢？

作者: amxiaomao 时间: 2009-04-06 18:59

原帖由 ssffzz1 于 2009-4-4 16:32 发表
是否半双工和这个没关系的。

我就问你，那个时候为什么WEB服务器就一个80端口也能正常工作呢？

因为这些端口号都是从NCP端口号派生出来的（NCP，即网络控制协议，是ARPANET的运输层协议，是TCP的前身）。

NCP是单工的，不是全双工的，因此每个应用程序需要两个连接，需预留一对奇数和偶数端口号。

当TCP和UDP成为标准的运输层协议时，每个应用程序只需要一个端口号，因此就使用了NCP中的奇数。（复制一段）

作者: ssffzz1 时间: 2009-04-06 19:25
但是FTP是一个数据一个控制啊。照你的说法，应该是4个端口了吧。

作者: shichunda 时间: 2009-04-06 19:31
关注中，有意思:wink:

作者: doexee 时间: 2009-04-06 20:03
曾看过某书说过这个情况，好像是Linux SA吧（不是很确定），提到过这个问题。
书中说双端口是历史遗留问题，当然在现在的情况下很Weak~

作者: llxxtnt 时间: 2009-04-06 21:06
最早描述ftp的rfc发布于1971年
最早描述http（也就是前面某楼提到的web）的rfc发布于1996年
二者不可相提并论

在70年代初期，那个时候的网络质量不好，我们对ftp的两种packet有不同的QoS需求
control packet要求高速（高速是相对的，不要跟现在的网络比），但是数据量很小
data packet数据量很大（大也是相对的，不要跟现在比），但对速度要求低
因此，将两种packet分在不同的session上，以实现不同的QoS需求

网络发展到现在，服务质量大大提高，一个session既可以满足数据量大，又可以满足速度快的需求，不再需要把QoS分开
从现在的观点来看，是可以将来两个session合并的
但是，老的方式已经沿用了近40年，如果新的方式没有特别突出的优点，我们为什要去改变已有的方式呢

这个跟双工还是单工没有联系
最早描述telnet的rfc也发布于1971年，跟ftp是同时代产物，那个时候tcp/ip还没有出现，他们都封装在ncp之上，直到80年代初期，tcp/ip出现之后，他们都porting到了tcp/ip上
从这个方面来讲，二者的发展过程非常类似
但是现在，telnet只需要使用1个port，而ftp是2个

--------------------------------------------------------------------------------------------------------------------------------------------------------------
哭死，写了没保存，一不小心没有，重写一遍
555555....

[ 本帖最后由 llxxtnt 于 2009-4-6 21:08 编辑 ]

作者: wy90 时间: 2009-04-06 22:22
标题: 协议没问题
我觉得协议应该没问题。设计时linux的控制端口和数据传输端口可能和windows的ftp端口差不多。而且也和半双工，全双工有关系。这样控制端口和数据传输端口分开更适合更多人传输数据。

作者: luotengfei520 时间: 2009-04-06 22:31

原帖由 amxiaomao 于 2009-4-6 18:59 发表

因为这些端口号都是从NCP端口号派生出来的（NCP，即网络控制协议，是ARPANET的运输层协议，是TCP的前身）。

NCP是单工的，不是全双工的，因此每个应用程序需要两个连接，需预留一对奇数和偶数端口号。 ...

我同意十一楼的看法，没必要四个端口。

作者: ssffzz1 时间: 2009-04-07 09:06
15楼的这个说法倒是比较靠谱了。

控制和数据分开，除了QOS的需要外估计也没别的了。不过遗憾的是，知道现在QOS这个东西都没有很好的实施。

也许是FTP的作者当时的前瞻考虑吧。

作者: Cyberman.Wu 时间: 2009-04-08 20:16
不要动不动就认为别人的脑子进水。FTP的控制通道和数据通道分开一个原因时可以实现一台终端控制两个服务器之间直接传文件而不用转一次；另外还有一点儿估计是原来设计的时候不想设计太复杂的传输控制，而一个独立的完全是流式的数据通道，以关闭为结束显然是最简单的。做过TCP的应该都知道有序无界的流要分隔出不同部分来挺复杂的，HTTP实际上原来也是以简单的关闭结束的，后来加了keep-alive之前在头部加了一个Content Length的东西，否则没办法知道一个页面是否结束了。

作者: ssffzz1 时间: 2009-04-09 09:10
终端控制两个服务器之间直接传文件而不用转一次

这个比较新鲜了。

作者: hansfly 时间: 2009-04-10 15:27
关注一下

作者: rainbow 时间: 2009-04-10 15:28
同意15楼的说法，ftp的确是一个十分老的协议，但是在当时是有其历史背景的。
现在p2p已经十分流行了，这个双端口的协议看起来还是有些怪异，不过感兴趣者可以查以下一些老的协议，还是有些这样的设计的（当然估计只能在一些文档上面看到了）。到我们接触网络开始，那些老的双端口的协议除了ftp外，基本都看不到了。

做人要厚道，还是要谦虚一些，如果真是“脑子进水”的设计，那么这个协议能够生存这么长的时间？

作者: kentchoi 时间: 2009-04-10 15:46
其实，tcp 协议就是有点进水的。。。。更别提 IPv4，，，更别提上面的应用协议。。。

好协议不见得统治市场，注水协议不见得不会统治市场。。。

作者: ssffzz1 时间: 2009-04-10 16:01
我改还不行啊。 2楼已经改过了。

设计者脑子没进水。不关心技术问题，倒是蛮关心进水的问题。

作者: iori201314163co 时间: 2009-04-10 21:55
呵呵，在tcp/ip详解卷一也提出了类似的问题，那是有历史原因的。在简单的标准服务和其他标准服务（TELNET/FTP等），都是奇数。这些端口号是从NCP （TCP前身）派生出来的。NCP是单工的，因此每个应用程序需要两个连接，需预留一对奇数和偶数端口号。
当TCP/udp成为标准传输层协议时，就用了一个。

作者: Cyberman.Wu 时间: 2009-04-21 12:58

原帖由 ssffzz1 于 2009-4-9 09:10 发表
终端控制两个服务器之间直接传文件而不用转一次

这个比较新鲜了。

这个不新鲜吧，是很古老的应用了，以前网络很慢，如果要控制从服务器A->B传文件，应该如何处理？两个在远程的时候只能通过终端C分别FTP上去，但如果只有一个通道的话，先不说处理上的复杂性，数据是要从A->C->B；而采用分享的控制通道，则可以在C上向B发一个命令通知要给它传文件，从而打开一个数据通道监听，然后向A发一个命令告诉它传文件到B，这样A就直接连接B来完成文件传输。

早期FTP采用20传数据，后来又改为用PORT命令定义端口以及PASV，目前多数是动态的，这种方式比较难用了。在99年时用过一个Absolute FTP支持这一功能，后来没再用过。

你想一想，如果要把文件从公网上一个服务器搬到另一个服务器，你是先下载再拷贝快呢，还是直接利用公网上的大带宽快？当然现在也可以直接远程登录之后发起传输，所以这种方式几乎没人再用了。

作者: Cyberman.Wu 时间: 2009-04-21 13:01

原帖由 kentchoi 于 2009-4-10 15:46 发表
其实，tcp 协议就是有点进水的。。。。更别提 IPv4，，，更别提上面的应用协议。。。

好协议不见得统治市场，注水协议不见得不会统治市场。。。

是的，TCP/IP的确不是一个有良好设计的协议，反正用TCP的流式编程很痛苦的，在上面设备应用层协议时要考虑许多种情况，如自己协议状况可能分两次甚至三次收上来，但这些情况在开发过程中又很难测试。

许多标准和产品并不见得有多好，有一个外延性的概念。操作系统和网络协议都是外延性很强的东西，很容易赢者通吃。

作者: Cyberman.Wu 时间: 2009-04-21 13:39
标题: 回复 #28 ssffzz1 的帖子
你没看明白我说的，给你举个例子，你现在有两个服务器AB放在电信机房里，在家里的客户端C通过ADSL上网，如果要把一个大文件从A拷贝到B，是直接走电信机房的公网出口快，还是先下载到C再上传快？我们的ADSL是3Mbps的，由于非对称性，实际上传速度最大也就50KB/s左右。

当然前面我说过，目前这种方式基本上用不到了，因为我完全可以远程连接到A控制它向B上传，或连接到B控制它从A下载。

作者: ssffzz1 时间: 2009-04-21 13:41
哦。是这样啊。

不过在FTP上没有见到此类似的命令了。

反正不常用了。讨论了也没多大意义。

作者: ssffzz1 时间: 2009-04-21 13:46
不过仔细想想这么做还是很有意义的东西。只是未见应用。

还是感谢了。

作者: ssffzz1 时间: 2009-04-21 14:13
其实2个端口也不是必须的东西。

现在有些黑客软件不也是用一个端口远程控制肉鸡的吗？？？

感觉N复杂了。不讨论这个问题了。

欢迎光临 Chinaunix (http://bbs.chinaunix.net/)