分类: 系统运维
2008-07-30 17:11:36
Network Working Group | J. Postel |
RFC编号: 959 | J. Reynolds |
|
ISI |
过时的RFC: 765 (IEN 149) | October 1985 |
备忘录状态
本备忘录描述了文件传输协议(FTP)的官方规范。对本备忘录的发布没有限制。
本规范新包括了如下可选命令:
CDUP (返回父目录), SMNT (结构装备), STOU(唯一保存),
RMD (删除目录), MKD (新建目录), PWD(打印目录), and SYST (系统)。
本规范与前一个版本兼容
================================================================================
FTP的目标是:1)促进程序/数据文件的共享;2)鼓励(通过程序)使用远程计算机;3)使用户不必面对不同主机上不同文件系统的差异;4)对数据进行高效可靠的传输。FTP尽管可以直接在终端上应用,但它主要被设计通过程序来使用。
本规范通过设计简单易实现的协议来试图满足大型机、小型机、个人工作站、TAC等用户的需要。
本文需要文件传输协议(TCP)[2]以及Telnet协议[3]的知识。关于它们的文档可以在ARPA-互联网协议手册[1]中找到。
本章讨论内容包括历史、术语、FTP模型。本章所描述的都是关于FTP的重要内容。一些术语专用于FTP模型;一些读者可能有必要在回顾这些术语时参考关于FTP模型的章节。
FTP的发展经历了很多年。附录III是按年代编辑的关于FTP的RFC文档。其中包括最早在1971年提出用在M.I.T.主机上的文件传输机制(RFC 114),以及在RFC 141中的注释和讨论。
RFC 172提供了一个在主机(包括终端IMP)间基于用户层协议的文件传输方法。RFC 265做为其修订,通过附加评论重定义了FTP,RFC 281建议进一步改进。“Set Data Type”在传输中应用在1982年1月的RFC 294中提出。
RFC 354废弃了RFC 264和265。文件传输协议被定义为ARPANET上主机间的文件传输协议,FTP的主要作用则被定义为用来在主机间高效可靠地传输文件以及对远程存储 的方便使用。RFC 385进一步讨论了协议的错误,重点和一些附加内容,RFC 414提供了使用中的FTP状态报告。1973年的RFC 430(被其它RFC多次引用),提供了对FTP的进一步讨论。最后,一个“官方的”FTP文件在RFC 454中发布。
至1973年1月,FTP协议又有了大量的变化,但总体的结构仍保持一致。为了应对这些变化,RFC 542中发布了新的“官方”规范。但很多基于老规范的应用并没有被更新。
1974年,RFC 607和614继续讨论FTP。RFC 624提出进一步改变设计和一些小的修补。1975年,RFC 686用题为“Leaving Well Enough Alone”讨论早期以及近期FTP版本的差别。RFC 691对RFC 686中关于打印文件部分做了小的修订。
在之前所有努力的基础上,通过将底层的传输协议由NCP改为TCP,应用TCP的FTP协议在RFC 765中诞生了。
本文描述的FTP规范目的在于纠正之前文档中的某些小错误,进一步解释一些协议特性,以及引入一些可选的命令。
特别地,本版本规范新包含了以下可选命令:
CDUP - 返回父目录
SMNT - 结构装备
STOU - 唯一保存
RMD - 删除目录
MKD - 新建目录
SYST - 系统
本规范兼容之前版本。应用在前一版本的程序应该可以自动应用于本规范。
ASCII
ASCII字符集定义于ARPA-互联网协议手册。FTP中ASCII字符指8位编码集的低半部(也就是最高位为0)。
访问控制(access controls)
访问控制定义了用户使用系统、系统文件的访问权力。访问控制必要性在于防止未被授权的或意外的对文件的访问。在服务器端使用访问控制正是FTP的优势所在。
字节长度(byte size)
有两种字节长度与FTP有关:文件的逻辑字节长度和用来传输数据的字节长度。传输字节长度总是8位。传输字节长度不必要和系统存储数据的字节长度或用来描述数据结构的逻辑字节长度相同。
控制连接(control connection)
用户PI与服务器PI用来交换命令和响应的信息路径。这个连接遵守Telnet协议。
数据连接(data connection)
用规定的模式和类型进行数据传输的全双向连接。传输的数据可能是文件的一部分、整个文件或一些文件。传输路径可能是服务器DTP与用户DTP之间或两个服务器DTP之间。
数据端口(data port)
数据接收者在数据端口监听,等待数据传输者从此端口建立数据连接。
DTP(data transfer process)
数据传输过程,用以建立并管理数据连接。DTP可以是被动或主动。
行结束符(End-of-Line)
行结束符序列定义了印刷行间的分隔。行结束符序列为回车符加换行符。
文件结束符(End-of-File)
文件结束符标志定义了传输中一个文件的结束。
记录结束符(End-of-Record)
记录结束符标志定义了传输中一个记录的结束。
错误恢复(error recovery)
允许用户从一些诸如主机系统或传输过程失败中恢复。FTP中,错误恢复可以是在给定点上重新开始文件传输。
FTP命令(FTP commands)
用户FTP到服务器FTP的控制信息流由一些命令集合组成。
文件(file)
计算机数据的有序集合(包括程序),有任意的大小,由路径名唯一指定。
模式(mode)
通过数据连接传输数据的方式。模式定义了包括EOR和EOF的数据传输格式。FTP的传输模式在传输模式一章中介绍。
NVT(Network Virtual Terminal)
网络虚拟终端在Telnet协议中定义。
NVFS(Network Virtual File System)
网络虚拟文件系统用标准命令和路径规定定义了标准网络文件系统概念。
页(page)
一个文件可能被分为彼此独立部分的结构集合,称为页。FTP支持将不连续的文件作为独立的页来传输。
路径名(pathname)
路径名定义为用户为了指定文件系统中某个特定文件而输入的字符串。路径一般包括驱动器名,目录名,以及文件名。FTP尚未规定标准的路径名规则。用户必须传输方文件系统的命名规则。
PI(protocol interpreter)
协议解析器。用户和服务器用其来解析协议,它们的具体实现分别称为用户PI和服务器PI。
记录(record)
顺序文件可能被由很多连续的部分组成称为记录。FTP支持记录结构,但文件不是必须具备记录结构。
响应(reply)
响应是由服务器发给用户的对FTP命令的回应(肯定或否定)。一般的响应格式是完成码(包括错误码)跟上一个文本字符串。完成码用于程序,文本用于用户。
服务器DTP(server-DTP)
数据传输过程,在通常的“主动”状态下是用“监听”的数据端口建立数据连接。它建立传输和存储参数,并在服务器端PI的命令下传输数据。服务器端DTP也可以用于“被动”模式,而不是主动在数据端口建立连接。
服务器FTP过程(server-FTP process)
与用户FTP过程或另一个服务器FTP过程配合实现文件传输功能。由协议解析器(PI)和数据传输过程(DTP)组成。
服务器PI(server-PI)
服务器PI在L端口“监听”用户协议解析器的连接请求并建立控制连接。它从用户PI接收标准的FTP命令,发送响应,并管理服务器DTP
类型(type)
用于数据传输和存储的数据表示类型。类型暗示了在数据存储和数据传输之间的时间变化。FTP中定义的表示类型在建立数据连接一章中描述。
用户(user)
希望得到文件传输服务的人或程序。用户可能直接与服务器FTP过程互相作用,但推荐使用用户FTP过程,协议的设计有利于自动化操作。
用户DTP(user-DTP)
数据传输过程在数据端口“监听”服务器FTP过程的连接。如果两个服务器通过它来传输数据,用户DTP就为非活跃的。
用户FTP过程(user-FTP process)
一系列功能集合,包括协议解析器、数据传输过程和用户界面,它们共同与服务器FTP过程配合完成文件传输功能。用户界面允许使用本地语言对用户发送命令响应。
用户PI(user-PI)
用户协议解析器用U端口建立到服务器FTP过程的控制连接,并在文件传输时管理用户DTP。
了解了上面的定义,下面的模型(图一所示)用来描述一个FTP服务。
-------------
|/---------\|
|| 用户 || --------
|| 界面 |<--->| 用户 |
|\----^----/| --------
---------- | | |
|/------\| FTP 命令 |/----V----\|
||服务器|<---------------->| 用户 ||
|| PI || FTP 响应 || PI ||
|\--^---/| |\----^----/|
| | | | | |
-------- |/--V---\| 数据 |/----V----\| --------
| 文件 |<--->|服务器|<---------------->| 用户 |<--->| 文件 |
| 系统 | || DTP || 连接 || DTP || | 系统 |
-------- |\------/| |\---------/| --------
---------- -------------
服务器-FTP 用户-FTP
注意:1. 数据连接可能是任一方向。
2. 数据连接不必须一直存在。
图 1 FTP使用模型
图1中描述的模型中,控制连接由用户PI发起。控制连接遵守Telnet协议。首先用户由用户PI产生标准FTP命令通过控制连接传输到服务器过 程。(用户可能建立一个到服务器FTP的直接连接,例如从TAC终端不经过用户FTP过程直接产生标准的FTP命令。)标准响应由服务器端PI通过数据连 接发送到用户PI作为命令的回应。
FTP命令指定数据连接参数(端口,传输模式,表示类型,以及结构)和文件系统操作种类
(store,retrieve,append,delete等)。用户DTP则应在指定的数据端口“监听”,服务器用相应的参数发起数据连接并传送数
据。而数据端口主机不一定必须与发送FTP命令的主机一至,但用户或用户FTP过程要保证指定的端口处在“监听”下。
另需指出的是数据连接可能同时用于发送和接收数据。
另一种情形是用户可能要在两台远程主机间传送文件。用户分别与两台服务器建立控制连接,并安排两服务器间的数据连接。这种情况下,控制信息传送到用户PI,但数据在两服务器间传送。以下是服务器-服务器交互模型:
控制 ------------ 控制
---------->| User-FTP |<-----------
| | User-PI | |
| | "C" | |
V ------------ V
-------------- --------------
| 服务器-FTP | 数据连接 | 服务器-FTP |
| "A" |<---------------------->| "B" |
-------------- 端口 (A) 端口 (B) --------------
图 2
协议规定在数据传输过程中控制连接必须一直打开。当FTP服务使用完以后,用户应该要求服务器关闭控制连接。当没有发送关闭命令但控制连接事实已经关闭的情况下,服务器可能终止数据传送。
FTP与Telnet的关系:
FTP在数据连接中使用Telnet协议。这可能以两种方法实现:第一,用户PI或服务器PI在它们的实现过程中应用Telnet协议。第二,用户PI或服务器PI可能用系统中已经存在的Telnet模块。
第二种方法使用更简单,达到了代码共享,模块化编程的目的。比第一种方法更独立和高效。实际上FTP对Telnet协议的依赖非常小,因此第一种方法也不一定会引入大量的代码。