文件传输协议(FTP)
本备忘录状态
本备忘录是文件传输协议(FTP)的正式标准。发布本备忘录不受限
制。
以下新的可选指令包含在本版规范中:
CDUP (回到上一级目录)
SMNT (结构加载)
STOU (唯一保存)
RMD (删除目录)
MKD (创建目录)
PWD (打印目录)和
SYST (系统)
注意:本规范兼容以前的版本。
1.介绍
FTP 的目标是:(1)提高文件的共享性(计算机程序和/或数据),(2)
鼓励间接地(通过程序)使用远程计算机,(3)保护用户因主机之间的文
件存储系统导致的变化,(4)为了可靠和高效地传输,虽然用户可以在终
端上直接地使用它,但是它的主要作用是供程序使用的。
本规范尝试满足大型主机、微型主机、个人工作站、和 TACs 的不同
需求。例如,容易实现协议的设计。
本文假定读者已具备传输控制协议(TCP)[2]和 Telnet 协议的知识。
这些文档包含在 ARPA-Internet 协议手册中。
2.概览
在本节中,我们将讨论 FTP 的历史、术语和模型。本节定义的术语对
FTP 来说非常重要。一些术语对 FTP 模型来说很特殊,有些读者可能在需
要术语时再次阅读本节。
2..1 历史
FTP 这些年有了很大的发展。附录 III 是一个按年代排序的与 FTP 有
关的 RFC 文档列表。包含最初被提议的 1971 年在 M.I.T.的主机上执行发展
起来的文件传输机制(RFC 114),对该文做注解和讨论的 RFC 141。
RFC 172 提供了一个用户级的在两台主机之间(包括 IMPs 终端)的定
向协议。RFC 265 做了修订,重申了 FTP 的附加功能。RFC 281 提出了更
进一步的改进建议。“设置数据类型”处理的应用在 1982 年的 RFC 294 中
被提议。
RFC 354 废除了 RFC 264 和 265。文件传输协议此时被定义为一个用
于两台 ARPANET 上的主机之间文件传输的协议,FTP 主要的功能被定义
为在主机间可靠高效地传输文件并允许方便地使用远程文件存储能力。
1
RFC 385 进一步为错误、重点和协议增加的部分做了注释。RFC414 提供了
服务器和用户在使用 FTP 工作时的一个状态报告。1973 年发布的 RFC 430
对 FTP(在其他很多的 RFC 文档中被援引)做了更进一步的介绍。最后,
RFC 454 作为一个“正式的”FTP 文档出版了。
1973 年 7 月,最后版本的 FTP 发布后又有相当多的变化,但是一般的
结构仍然没变。RFC 542 作为一个新的“正式”规范反映了这些变化。不
过,许多基于旧规范的执行没有更新。
1974 年,RFC 607 和 614 对 FTP 继续进行注释。RFC 624 被提议改进
设计和修正。1975 年,RFC 686 论述了早期的和后来的 FTP 版本之间的不
同。RFC 691 对 RFC 686 关于打印文件的主题提出了一个较小的修订。
随着 NCP 到 TCP 的转变,出现了 RFC 765,它是使用 TCP 的 FTP 规
范。
现在的这个版本的 FTP 规范,修正了一些较小的文档错误,改进了一
些协议特征的说明,增加了一些新的可选指令。
特别是这些包含在本规范中的新的可选指令:
CDUP —— 回到上一级目录
SMNT —— 结构加载
STOU —— 唯一保存
RMD —— 删除目录
MKD —— 创建目录
PWD —— 打印目录
SYST —— 系统
本规范兼容以前的版本。
2.2 术语
ASCII
ASCII 字符集是在 ARPA-Internet 协议手册中定义的。在 FTP 里,ASCII
字符被定义为 8 位的编码集。
权限控制
权限控制定义了用户在一个系统中可使用的权限和对系统中文件操作
的 权 限 。 权 限 控 制 在 防 止 未 被 授 权 或 意 外 地 使 用 文 件 时 是 必 需 的 。
server-FTP 过程有调用权限控制的特权。
字节大小
FTP 中有两种类型的字节大小:文件的逻辑字节大小,和用于数据传
输的传输字节大小。传输字节大小通常是 8 位。传输字节不必等于系统中
存储数据的字节大小,也不必对数据结构进行解释。
控制连接
控制连接是建立在 USER-PIT 和 SERVER-PI 之间用于交换命令与应答
的通信链路。该连接遵从 Telnet 协议。
数据连接
数据连接是在特定的模式和类型下,传输数据的全双工连接。传输数
据可以是文件的一部分、整个文件或数个文件。链路可以建立在服务器 DTP
2
和用户 DTP 之间也可以建立在两个服务器 DTP 之间。
数据端口
为了建立数据连接,被动数据传输过程需要在一个端口“监听”主动
传输过程的消息。
DTP
数据传输过程,建立和管理数据连接,DTP 可以是主动的也可以是被
动的。
End-of-Line
End-of-Line定义了打印行时的分隔符。它是“回车符”。
EOF
EOR
end-of-file 是传输的文件的结尾标志。
end-of -record 是传输的记录的结尾标志。
错误恢复
一个允许用户在主机系统或文件传输失败时可以从特定的错误恢复的
程序。在 FTP 中,错误恢复也包括在给定一个检查点时重新开始文件传输。
FTP 指令
包含从 user-FTP 到 server-FTP 的过程的控制信息的指令集。
文件
一个计算机数据的有序集合(包括程序),可以是任意长度的,由唯一
的路径名来标识。
模式
数据的模式通过数据连接传输。模式定义了传输期间包含 EOR 和 EOF
的格式。
NVT
在 Telnet 协议中定义的网络虚拟终端。
NVFS
网络虚拟文件系统。是一个定义了拥有标准指令和路径名约定的标准
的网络文件系统。
页
一个文件独立的部分的集合称为页。FTP 支持由独立的索引页组成的
不连续文件的传送。
路径名
路径名是用户为了识别文件输入到文件系统的字符串。路径名通常包
含设备和/或目录的名字,和指定的文件名。FTP 还没有指定一个标准的路
径名约定。每个用户必须遵从文件系统有关文件传输的文件命名约定。
PI
协议解释器。用户和服务器各拥有明确的任务user-PI和server-PI。
记录
一个顺序文件可以由数个称为记录的连续部分组成。FTP支持记录结
构,除非文件不需要文件结构。
回应
回应是对FTP指令作出的应答(肯定的或否定的),经由控制连接从服
务器发送到客户端。通常回应的形式是一个完成码(包括错误码)再跟随
3
一个文本字符串。代码是供程序使用的,文本则通常提供给人类用户。
server-DTP
数据传输过程,一般是“主动的”状态,建立一个含有“监听”端口
的数据连接。为传输和存储设置参数,从它的PI通过指令传输数据。DTP
被设置为“被动的”状态收听消息,比开按就连接到数据端口的效果要好。
server-FTP过程
在和user-FTP过程,或者可能是其他服务器合作,完成文件传输过程
功能的过程,由多个处理组成的集合,该功能由一个协议解释器(PI)和
一个数据传输过程(DTP)组成。
server-PI
服务器协议解释器在端口L“监听”,以期来自user-PI的连接连接,建
立一个控制通信连接。它从user-PI收到标准的FTP指令,然后发出回应,
接着管理server-DTP。
类型
数据表示类型用来进行数据传输和存储。类型意味着在数据存储和数
据传输的时间内特定的转换。
用户
一个期望获得文件传输服务的人或过程。人类用户可以直接影响
server-FTP过程,但是,应首选user-FTP过程,因为它有利于协议设计朝自
动控制方向发展。
user-DTP
为了来自server-FTP过程的数据连接,数据传输过程“监听”数据端口。
如果两个服务器之间传输数据,user-DTP就停止了。
user-DTP过程
与一个或多个server-FTP过程合作,为了完成文件传输功能的功能集
合。包括一个协议解释器,一个数据传输过程和一个用户界面。用户界面
允许使用本地语言显示指令回应的对话。
user-PI
用户协议解释器开始控制连接从它的U端口到server-FTP过程,如果这
个过程是文件传输的一部分,接着初始化FTP指令,然后管理user-FTP。
2.3FTP模型
根据上面的定义,下面的模型(见图1)是FTP服务示意图:
-------------
|/---------\|
|| 用户 || --------
|| 接口 |<--->| 用户 |
|\----^----/| --------
---------- | | |
|/------\| FTP 指令 |/----V----\|
||Server|<---------------->| user ||
|| PI || FTP 回应 || PI ||
|\--^---/| |\----^----/|
4
| | | | | |
-------- |/--V---\| 数据 |/----V----\| --------
| 文件 |<--->|Server|<---------------->| user |<--->| 文件 |
| 系统 | || DTP || 连接 || DTP || | 系统 |
-------- |\------/| |\---------/| --------
---------- -------------
Server-FTP USER-FTP
注意:1.数据连接是双向的。
2.数据连接无需在整个时间存在。
图1 FTP用户模型
图1描述的模型中,user-PI开始控制连接。控制连接遵从Telnet协议。
在用户初始化时,user-PI产生标准的FTP指令,并经由控制连接传送到服务
器过程。(用户可以建立一个直接的控制连接到server-FTP,比如从TAC终
端,并且发出独立的标准FTP指令,这样就绕过了user-FTP过程。)标准的
回应通过控制连接从server-PI发送到user-PI。
FTP指令可以为数据连接和文件系统操作的状态(存储,下载,设置
数据文件的搜索路径,删除等)指定参数(数据端口,传输模式,表现类
型和结构)。
user-DTP应该在指定的数据端口“监听”,服务器初始数据连接,数据
用特定的参数保证一致地传输。注意,数据端口不必和初始化FTP指令的主
机是同一台主机,但是用户或user-FTP过程必须保证在指定的数据端口“监
听”。还要注意,数据连接可能同时也在发送和接收。
另一种情况是,用户希望在两台主机间传送文件,没有一台是本地主
机。用户在两台主机间建立控制连接,并准备在它们之间进行数据连接。
在这种方式下,控制信息经过user-PI,但数据在服务器数据传输过程间传
输。下图是这种服务器-服务器交互方式的模型:
控制 ------------ 控制
---------->| user-FTP |<-----------
| | user-PI | |
| | "C" | |
V ------------ V
-------------- --------------
| Server-FTP | 数据连接 | Server-FTP |
| "A" |<---------------------->| "B" |
-------------- 端口 (A) 端口 (B) --------------
图2
协议要求数据传输在处理时打开控制连接。在完成FTP服务后,用户
的责任是请求关闭控制连接,而服务器具体操作。如果在未接收命令时关
5
闭了控制连接,服务器也会关闭数据传输。
FTP和Telnet的关系:
FTP在控制连接中使用Telnet协议。可以通过两种方式达到目的:第一
种,user-PI或server-PI按Telnet的规则直接在它们的过程中实现;第二种,
user-PI或server-PI可以利用系统中已存在的模块实现。
实现很容易,共享代码,第二种方式有利于程序模块化,第一种方式
有利于传输效率和独立性。实际上,FTP对Telnet的依赖非常小,用第二种
方式实现的代码量也不大。
3.数据传输功能
文件通过数据连接传输。控制连接用来传输指令,它描述了执行的功
能和指令的回应(参看 FTP 回应一节)。有几个指令和主机间数据传输有关。
这些指令包括:传输时指定数据位数的 MODE 指令,用来定义数据表现的
STRU 指令和 TYPE 指令。数据传输和表现基本上是独立的,但是,“流”
模式依赖于文件结构属性,如果使用“压缩”传输模式,填充字节的状态
依赖于表示类型。
3.1数据表示和存储
数据从发送主机的一个存储设备传输到接收主机的一个存储设备。因
为通常两个系统的数据表示是不同的,所以需要对数据进行特定的转换。
比如NVT-ASCII在不同的系统中有不同的数据表示。例如,DEC TOPS-20中
一般以5个7位的ASCII字符存储NVT-ASCII,IBM的大型机使用8位的EBCDIC
码存储NVT-ASCII,而Multics用4个9位字符存储Multics。在不同的系统间
传输文本时,要想令人满意,就要把这些字符都转换成标准的NVT-ASCII表
示。发送和接收的站点完成在标准表示和内部表示之间的必要的转换。
另一个问题是,在不同的字长的主机间传送二进制数据(不是字符编
码)时如何表示。通常不清楚发送方如何发送数据,也不清楚接收方如何
存储。例如,当从32位字长的系统传送32位的字节到36位字长的系统时,
需要(为了高效和易用)将32位的字节存储成36位的字。有时,用户要有
可选的特定数据表示与传输功能。注意,FTP提供非常有限的数据类型表示。
超过FTP提供功能的那一部分要用户自己实现。
3.1.1数据类型
数据表示是由用户指定的表示类型,类型可以隐含地(比如ASCII或
EBCDIC)或明确地(比如本地字节)定义一个字节的长度,提供像“逻辑
字节长度”这样的表示。注意,在数据连接上传输时使用的字节长度称为
“传输字节长度”,和上面说的“逻辑字节长度”不要弄混。例如,NVT-ASCII
的逻辑字节长度是8位。如果该类型是本地类型,那么TYPE指令必须在第二
个参数中指定逻辑字节长度。传输字节长度通常是8位的。
3.1.1.1ASCII类型
这是所有FTP执行必须承认的默认类型。它主要用于传输文本文件,除
非两台主机用EBCDIC类型更方便。
发送方把内部字符表示的数据转换成标准的8位NVT-ASCII表示(参看
6
Telnet规范)。接收方把数据从标准的格式转换成自己内部的表示形式。
与NVT标准保持一致,要在行结束处使用序列。(参看数据表示
和存储一节末尾有关文件结构的讨论。)
使用标准的NVT-ASCII表示的意思是数据必须转换为8位的字节。
ASCII和EBCDIC的格式参数在下面讨论。
3.1.1.2 EBCDIC类型
这种类型在使用EBCDIC作为内部字符的主机间能提供高效的传输。
为了传输,数据被表示为8位的EBCDIC字符。仅在类型的功能描述上有
一些差别。
行结束符(对应的记录结束符请参看结构的讨论)在EBCDIC类型中很
少用来做结构表示,但是它需要使用字符。
3.1.1.3 IMAGE类型
数据以连续的位传输,并打包成8位的传输字节。接收站点必须以连续
的位存储数据。存储系统的文件结构(或者对于记录结构文件的每个记录)
必须填充适当的分隔符,分隔符必须全部为零,填充在文件末尾(或每个
记录的末尾),而且必须有识别出填充位的办法,以便接收方把它们分离出
去。填充的传输方法应该充分地宣传,使得用户可以在存储站点处理文件。
IMAGE 格式用于有效地传送和存储文件和传送二进制数据。推荐所有
的FTP在执行时支持此类型。
3.1.1.4 本地类型
以逻辑字节传输的数据必须在第二个参数中指定字节的大小。字节大
小的值必须是十进制整数,它没有缺省值。逻辑字节大小不必和传输字节
大小一样。如果使用不同的字节大小,那么逻辑字节应使用连续的方式打
包,忽略传输字节的分隔符,并且无须在末尾进行任何填充。
当数据到达接收方主机,它的转换方式依赖于逻辑字节大小和主机的
特性。该转换必须是可逆的(就是说,使用同样的参数可以重新得到这个
文件),并且应对FTP的执行者进行充分的宣传。
例如,用户发送36位浮点数到一个用32位的字表示的主机,数据可以
用逻辑字节大小为36的逻辑字节发送。接收方主机为了存储这个逻辑字节,
需要做简单的操作:在本例中,把36位的逻辑字节转换成64位的双字就足
够了。
另一个例子,2台用36位的字表示的主机,可以使用36位的逻辑字发送
数据到对方。被发送的数据以8位的字节打包,所以9个传输字节传送了2个
主机字。
3.1.1.5 格式控制
ASCII和EBCDIC类型也使用了第二个(可选的)参数:它用于指出纵向
格式控制的类型,或者是任何与文件关联的类型。下面的数据表示类型已
在FTP中定义:
一个字符文件是为了下列三种目的之一传送到远程主机的:为了打印,
为了存储和以后信息的检索,或为了处理。如果一个文件为了打印而发送,
7
接收方主机必须知道纵向格式控制是如何表示的。为了第二种目的,必须
可以在主机存储文件并且以后检索时要格式正确。最后一种目的,应该可
以移动这个文件到其他主机并且可以在第二台主机上处理而没有以外的麻
烦。单独的ASCII或EBCDIC格式不能满足所有这些条件。所以,这些类型需
要第二个参数指定下列三种格式之一:
3.1.1.5.1 非打印
如果省略掉第二个(格式)参数的话,这是缺省的格式。非打印格式
必须被所有的FTP执行者承认。
文件不需要包含纵向格式信息。如果它经过一个打印过程,那么该过
程将以假定的标准间隔和边距值来处理。
通常,该格式用来处理文件或仅仅用来存储。
3.1.1.5.2 TELNET格式控制
文件包含打印过程可以正确解释的ASCII/EBCDIC纵向格式控制(比
如,,,,,)。,在这个序列里也表示行结
束符。
3.1.1.5.2 托架(走纸)控制(ASA)
文件包含ASA (FORTRAN)的纵向控制字符。(参看RFC 740 附录 C,和
ACM通信,606页,Vol. 7, No. 10,1964年10月。)在有格式的行或记录中,
遵照ASA的标准,第一个字符不能打印。它用来限定被打印的记录静止时的
走纸量。
ASA标准指定了下列字符:
字符 垂直间距
---- -----------------
空格 纸张上移一行
0 纸张上移二行
1 纸张移到下页顶端
+ 不移动,比如套印
很明显,打印过程必须有识别结构实体末尾的方式。如果文件采用了
记录结构(见下文)不会有问题,记录可以在传输和存储期间明确地标出。
如果文件不是采用记录结构,行结束符用来分隔打印行,但是这些
格式控制符超出了ASA的控制。
3.1.2 数据结构
除了不同的数据表示类型,FTP还允许指定文件的结构。FTP中定义了
三种文件结构:
文件结构,它没有内部结构,文件由连续的数据字节组成。
记录结构,文件由连续的记录组成。
页结构,文件由独立的索引页组成。
8