Chinaunix

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

作者: gobbin    时间: 2009-03-30 14:19
标题: ftp协议为什么开两个端口呢?
我知道一般说法是一个用来传数据,一个用来传命令\r\n但是实际上好像有别的原因啊\r\n哪位给解释下
作者: ssffzz1    时间: 2009-03-30 14:28
不是技术问题了。\r\n\r\n先前只有主动模式了。\r\n后来因为防火墙之类的问题,又提出了被动模式。\r\n\r\n其实就一个端口也未尝不可了。没技术方面的障碍了。\r\n\r\n\r\n改了。\n\n[ 本帖最后由 ssffzz1 于 2009-4-10 16:00 编辑 ]
作者: kentchoi    时间: 2009-03-30 15:05
这样开发显得很高深,,,\r\n\r\n控制通道跟传输通道分开,\r\n\r\n还带着 port 命令跟 passive 命令,,,那么宝贵的1024以下的端口,ftp自己就占据了2个。。。
作者: rainbow    时间: 2009-03-30 15:23
标题: 回复 #1 gobbin 的帖子
这个协议太老了,设计者的思想在当时是好的: 命令通道仅仅处理命令,时间短; 数据通道处理数据时间长。 \r\n可是在现在,尤其是有防火墙的时候,再加上客户端在局域网内时,这个设计很显然过时了,很麻烦的。
作者: gobbin    时间: 2009-03-31 13:41
这样开发显得很高深,,,\r\n........................................\r\n感觉ftp协议应该改进改进了
作者: benjiam    时间: 2009-04-01 15:06
ok  我在接受ftp数据的时候,我要停止接收数据, 这时候我应该怎么做?\r\n\r\n我发送一个命令表示 我要paush,  然后 接受到什么认为是对方停止了, 我如何区别是网络延迟还是  对方停止?
作者: ssffzz1    时间: 2009-04-01 15:10
确认对方停止是有信令的。\r\n而网络延迟要么丢包,要么延后到达。如果在允许的超时范围内,则可以正常通讯,如果丢包超过允许范围,则中断。
作者: imhr    时间: 2009-04-04 15:51
控制通道跟传输通道分开?
作者: ssffzz1    时间: 2009-04-04 16:32
标题: 回复 #8 amxiaomao 的帖子
是否半双工和这个没关系的。\r\n\r\n我就问你,那个时候为什么WEB服务器就一个80端口也能正常工作呢?
作者: ssffzz1    时间: 2009-04-06 19:25
但是FTP是一个数据一个控制啊。照你的说法,应该是4个端口了吧。
作者: shichunda    时间: 2009-04-06 19:31
关注中,有意思:wink:
作者: doexee    时间: 2009-04-06 20:03
曾看过某书说过这个情况,好像是Linux SA吧(不是很确定),提到过这个问题。\r\n书中说双端口是历史遗留问题,当然在现在的情况下很Weak~
作者: llxxtnt    时间: 2009-04-06 21:06
最早描述ftp的rfc发布于1971年\r\n最早描述http(也就是前面某楼提到的web)的rfc发布于1996年\r\n二者不可相提并论\r\n\r\n在70年代初期,那个时候的网络质量不好,我们对ftp的两种packet有不同的QoS需求\r\ncontrol packet要求高速(高速是相对的,不要跟现在的网络比),但是数据量很小\r\ndata packet数据量很大(大也是相对的,不要跟现在比),但对速度要求低\r\n因此,将两种packet分在不同的session上,以实现不同的QoS需求\r\n\r\n网络发展到现在,服务质量大大提高,一个session既可以满足数据量大,又可以满足速度快的需求,不再需要把QoS分开\r\n从现在的观点来看,是可以将来两个session合并的\r\n但是,老的方式已经沿用了近40年,如果新的方式没有特别突出的优点,我们为什要去改变已有的方式呢\r\n\r\n这个跟双工还是单工没有联系\r\n最早描述telnet的rfc也发布于1971年,跟ftp是同时代产物,那个时候tcp/ip还没有出现,他们都封装在ncp之上,直到80年代初期,tcp/ip出现之后,他们都porting到了tcp/ip上\r\n从这个方面来讲,二者的发展过程非常类似\r\n但是现在,telnet只需要使用1个port,而ftp是2个\r\n\r\n--------------------------------------------------------------------------------------------------------------------------------------------------------------\r\n哭死,写了没保存,一不小心没有,重写一遍\r\n555555....\n\n[ 本帖最后由 llxxtnt 于 2009-4-6 21:08 编辑 ]
作者: wy90    时间: 2009-04-06 22:22
标题: 协议没问题
我觉得协议应该没问题。设计时linux的控制端口和数据传输端口可能和windows的ftp端口差不多。而且也和半双工,全双工有关系。这样控制端口和数据传输端口分开更适合更多人传输数据。
作者: ssffzz1    时间: 2009-04-07 09:06
15楼的这个说法倒是比较靠谱了。\r\n\r\n控制和数据分开,除了QOS的需要外估计也没别的了。不过遗憾的是,知道现在QOS这个东西都没有很好的实施。  \r\n\r\n也许是FTP的作者当时的前瞻考虑吧。
作者: Cyberman.Wu    时间: 2009-04-08 20:16
不要动不动就认为别人的脑子进水。FTP的控制通道和数据通道分开一个原因时可以实现一台终端控制两个服务器之间直接传文件而不用转一次;另外还有一点儿估计是原来设计的时候不想设计太复杂的传输控制,而一个独立的完全是流式的数据通道,以关闭为结束显然是最简单的。做过TCP的应该都知道有序无界的流要分隔出不同部分来挺复杂的,HTTP实际上原来也是以简单的关闭结束的,后来加了keep-alive之前在头部加了一个Content Length的东西,否则没办法知道一个页面是否结束了。
作者: ssffzz1    时间: 2009-04-09 09:10
终端控制两个服务器之间直接传文件而不用转一次\r\n\r\n这个比较新鲜了。
作者: rainbow    时间: 2009-04-10 15:28
同意15楼的说法,ftp的确是一个十分老的协议,但是在当时是有其历史背景的。 \r\n现在p2p已经十分流行了,这个双端口的协议看起来还是有些怪异,不过感兴趣者可以查以下一些老的协议,还是有些这样的设计的(当然估计只能在一些文档上面看到了)。 到我们接触网络开始,那些老的双端口的协议除了ftp外,基本都看不到了。\r\n\r\n做人要厚道,还是要谦虚一些,如果真是“脑子进水”的设计,那么这个协议能够生存这么长的时间?
作者: kentchoi    时间: 2009-04-10 15:46
其实,tcp 协议就是有点进水的。。。。更别提 IPv4,,,更别提上面的应用协议。。。\r\n\r\n好协议不见得统治市场,注水协议不见得不会统治市场。。。
作者: ssffzz1    时间: 2009-04-10 16:01
我改还不行啊。 2楼已经改过了。\r\n\r\n设计者脑子没进水。   不关心技术问题,倒是蛮关心进水的问题。
作者: iori201314163co    时间: 2009-04-10 21:55
呵呵,在tcp/ip详解 卷一 也提出了类似的问题,那是有历史原因的。在简单的标准服务和其他标准服务(TELNET/FTP等),都是奇数。这些端口号是从NCP (TCP前身)派生出来的。NCP是单工的,因此每个应用程序需要两个连接,需预留一对奇数和偶数端口号。\r\n当TCP/udp成为标准传输层协议时,就用了一个。\r\n
作者: Cyberman.Wu    时间: 2009-04-21 13:39
标题: 回复 #28 ssffzz1 的帖子
你没看明白我说的,给你举个例子,你现在有两个服务器AB放在电信机房里,在家里的客户端C通过ADSL上网,如果要把一个大文件从A拷贝到B,是直接走电信机房的公网出口快,还是先下载到C再上传快?我们的ADSL是3Mbps的,由于非对称性,实际上传速度最大也就50KB/s左右。\r\n\r\n当然前面我说过,目前这种方式基本上用不到了,因为我完全可以远程连接到A控制它向B上传,或连接到B控制它从A下载。
作者: ssffzz1    时间: 2009-04-21 13:41
哦。是这样啊。\r\n\r\n不过在FTP上没有见到此类似的命令了。\r\n\r\n反正不常用了。讨论了也没多大意义。
作者: ssffzz1    时间: 2009-04-21 13:46
不过仔细想想这么做还是很有意义的东西。只是未见应用。\r\n\r\n还是感谢了。
作者: ssffzz1    时间: 2009-04-21 14:13
其实2个端口也不是必须的东西。\r\n\r\n现在有些黑客软件不也是用一个端口远程控制肉鸡的吗???\r\n\r\n感觉N复杂了。不讨论这个问题了。




欢迎光临 Chinaunix (http://bbs.chinaunix.net/) Powered by Discuz! X3.2