FTP协议(RFC959_Chinese)

发布时间：2024-11-18

FTP协议的RFC文档规范,中文版。

文件传输协议（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主要的功能被定义为在主机间可靠高效地传输文件并允许方便地使用远程文件存储能力。

FTP协议的RFC文档规范,中文版。

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

FTP协议的RFC文档规范,中文版。

和用户DTP之间也可以建立在两个服务器DTP之间。

数据端口

为了建立数据连接，被动数据传输过程需要在一个端口“监听”主动传输过程的消息。

DTP 数据传输过程，建立和管理数据连接，DTP可以是主动的也可以是被动的。

End-of-Line End-of-Line定义了打印行时的分隔符。它是“回车符”。

EOF end-of-file是传输的文件的结尾标志。 EOR

end-of -record是传输的记录的结尾标志。

错误恢复

一个允许用户在主机系统或文件传输失败时可以从特定的错误恢复的程序。在FTP中，错误恢复也包括在给定一个检查点时重新开始文件传输。 FTP指令

包含从user-FTP到server-FTP的过程的控制信息的指令集。

文件

一个计算机数据的有序集合（包括程序），可以是任意长度的，由唯一的路径名来标识。

模式

数据的模式通过数据连接传输。模式定义了传输期间包含EOR和EOF的格式。

NVT

在Telnet协议中定义的网络虚拟终端。

NVFS

网络虚拟文件系统。是一个定义了拥有标准指令和路径名约定的标准

的网络文件系统。

页

一个文件独立的部分的集合称为页。FTP支持由独立的索引页组成的不连续文件的传送。

路径名

路径名是用户为了识别文件输入到文件系统的字符串。路径名通常包

含设备和/或目录的名字，和指定的文件名。FTP还没有指定一个标准的路径名约定。每个用户必须遵从文件系统有关文件传输的文件命名约定。 PI 协议解释器。用户和服务器各拥有明确的任务user-PI和server-PI。记录

一个顺序文件可以由数个称为记录的连续部分组成。FTP支持记录结

构，除非文件不需要文件结构。

回应

回应是对FTP指令作出的应答（肯定的或否定的），经由控制连接从服

务器发送到客户端。通常回应的形式是一个完成码（包括错误码）再跟随

FTP协议的RFC文档规范,中文版。

一个文本字符串。代码是供程序使用的，文本则通常提供给人类用户。 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 ||

|\--^---/| |\----^----/|

FTP协议的RFC文档规范,中文版。

| | | | | |

-------- |/--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服务后，用户

的责任是请求关闭控制连接，而服务器具体操作。如果在未接收命令时关

FTP协议的RFC文档规范,中文版。

闭了控制连接，服务器也会关闭数据传输。

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表示（参看

FTP协议的RFC文档规范,中文版。

Telnet规范）。接收方把数据从标准的格式转换成自己内部的表示形式。

与NVT标准保持一致，要在行结束处使用<CRLF>序列。（参看数据表示和存储一节末尾有关文件结构的讨论。）使用标准的NVT-ASCII表示的意思是数据必须转换为8位的字节。

ASCII和EBCDIC的格式参数在下面讨论。

3.1.1.2 EBCDIC类型

这种类型在使用EBCDIC作为内部字符的主机间能提供高效的传输。为了传输，数据被表示为8位的EBCDIC字符。仅在类型的功能描述上有

一些差别。行结束符（对应的记录结束符请参看结构的讨论）在EBCDIC类型中很少用来做结构表示，但是它需要使用<NL>字符。

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中定义：

一个字符文件是为了下列三种目的之一传送到远程主机的：为了打印，为了存储和以后信息的检索，或为了处理。如果一个文件为了打印而发送，

FTP协议的RFC文档规范,中文版。

接收方主机必须知道纵向格式控制是如何表示的。为了第二种目的，必须可以在主机存储文件并且以后检索时要格式正确。最后一种目的，应该可以移动这个文件到其他主机并且可以在第二台主机上处理而没有以外的麻烦。单独的ASCII或EBCDIC格式不能满足所有这些条件。所以，这些类型需要第二个参数指定下列三种格式之一：

3.1.1.5.1 非打印

如果省略掉第二个（格式）参数的话，这是缺省的格式。非打印格式必须被所有的FTP执行者承认。

文件不需要包含纵向格式信息。如果它经过一个打印过程，那么该过程将以假定的标准间隔和边距值来处理。通常，该格式用来处理文件或仅仅用来存储。

3.1.1.5.2 TELNET格式控制

文件包含打印过程可以正确解释的ASCII/EBCDIC纵向格式控制（比如，<CR>，<LF>，<NL>，<VT>，<FF>）。<CRLF>，在这个序列里也表示行结束符。

3.1.1.5.2 托架(走纸)控制（ASA）

文件包含ASA (FORTRAN)的纵向控制字符。（参看RFC 740 附录 C，和

ACM通信，606页，Vol. 7, No. 10,1964年10月。）在有格式的行或记录中，遵照ASA的标准，第一个字符不能打印。它用来限定被打印的记录静止时的走纸量。

ASA标准指定了下列字符：

字符垂直间距

---- -----------------

空格纸张上移一行

0 纸张上移二行

1 纸张移到下页顶端

+ 不移动，比如套印

很明显，打印过程必须有识别结构实体末尾的方式。如果文件采用了

记录结构（见下文）不会有问题，记录可以在传输和存储期间明确地标出。如果文件不是采用记录结构，<CRLF>行结束符用来分隔打印行，但是这些格式控制符超出了ASA的控制。

3.1.2 数据结构

除了不同的数据表示类型，FTP还允许指定文件的结构。FTP中定义了

三种文件结构：

文件结构，它没有内部结构，文件由连续的数据字节组成。

记录结构，文件由连续的记录组成。

页结构，文件由独立的索引页组成。

FTP协议的RFC文档规范,中文版。

如果没有使用STRUcture指令，文件结构就被假定是缺省的。文件和记录结构必须被所有的FTP实现以“文本”文件（比如，ASCII或EBCDIC类型的文件）的方式承认。文件的格式影响它的传输模式（参看传输模式一节）和它的解释和存储。

文件的“自然的”格式依赖于主机的存储。一个源代码文件通常在IBM

的大型机中是以固定长度的记录存储的，而在DEC TOPS-20机上它是以分隔（比如用<CRLF>来分隔）成行的字符流存储的。如果想让文件在完全不同的站点传输，就必须有办法让一个站点承认另一个站点关于该文件的结构表示。有些站点是面向文件的，还有些站点是面向记录的，如果从一个主机到另一个文件结构不同的主机传送文件时就会出问题。如果一个文本文件以记录结构传送，而接收方的主机却是面向文件的，那么这个主机就必须对该文件进行基于记录结构的转换。显然，这样的转换很有效，但是这个转换的过程必须也是可逆的。在一个文件以文件结构传送到面向记录的主机时，存在一个问题，该主机要用什么标准把文件划分成记录以便于本地处理。如果需要这样的划分，那么FTP在执行时使用的行结束符，对ASCII文件用<CRLF>，对EBCDIC文件用<NL>作为分隔符。如果FTP的实现采用了这个技术，它就必须准备好在这个文件要重新转成文件结构时，能进行逆转换操作。

3.1.2.1 文件结构

如果没有使用STRUcture指令，文件结构就被假定是缺省的。

文件结构没有内部的结构，被认为是数据字节的连续序列。

3.1.2.2 记录结构

记录结构必须被所有的FTP实现以“文本”文件（比如，ASCII或EBCDIC类型的文件）的方式承认。

记录结构的文件由连续的记录组成。

3.1.2.3 页结构

为了传送不连续的文件，FTP定义了一种页结构。这样的文件结构已

知的往往是“随机存取文件”或“holey文件”。这种结构有时候通过其他信息把文件联系成一个整体（比如，一个文件描述符），或者是文件的一部分（比如，页面存取控制）。在FTP里，这些文件的部分成为页。

为了提供不同的页大小和关联信息，每个页在传送时附加一个页头。

页头定义了下列域：

页头长度：包含这个字节在内的页头的逻辑字节数。最小的页头长是4。页索引：该部分在文件中的逻辑页编号。这不是页的传输序列号，该

索引用来指出文件的这一页。

数据长度：页中数据的逻辑字节数。最小的数据长度是0。

页类型：页的类型。定义了如下类型：

0 = 最后页

FTP协议的RFC文档规范,中文版。

用来指出页结构文件传输的末尾。页头长度必须是4，数据长度

必须是0。

1=简单页

这是的简单分页文件的一般类型，它没有与控制有关的页等级信

息。页头长度必须是4。

2=描述符页

该类型用来传输文件总体的描述信息。

3=访问控制页

该类型包含了一个附加的页头域，用来传送页分级访问控制信

息。页头长度必须是5。可选的域：为提供每个页的控制信息，可以使用有更多的页头域。比如，每页访问控制。

所有的域都有一个逻辑字节长度。逻辑字节大小由TYPE指令定义。参看附录一可获取更详细的信息，和页结构的一个特殊情况。

关于参数的警告：如果检索的版本和最初传送的版本一样，文件就必须用同样的参数存储和检索。相反地，如果使用了相同的参数来存储和检索数据，FTP的执行必须返回同一个文件。

3.2 建立数据连接

传输数据的细节包括在适当的端口建立数据连接和选择传输参数。用

户和server-DTP有缺省的数据端口。用户进程缺省的数据端口与控制连接端口相同（比如，U）。服务器进程缺省的数据端口与控制连接端口相临（比如，L-1）。

传输字节是8位的字节。字节的大小仅与实际的数据传输有关，它和主

机文件系统内的数据表示无关。

被动数据传输进程（可能是一个user-DTP，或一个第二server-DTP）在发送数据请求指令前应先在数据端口“监听”。FTP请求指令决定数据传输的方向。服务器在接收到请求以后，将初始化该端口的数据连接。当连接建立后，数据传输在DTP之间传送，server-PI对user-PI返回确认应答。

每个FTP的实现必须支持缺省数据端口的使用，并且只有user-PI可以初始化改变到一个非缺省的数据端口。

用户可能使用PORT指令指定轮流的数据端口。用户可能要求一个文件被转移到TAC行式打印机或从第三方主机接收。在后一种情况下，user-PI在两个server-PI间建立控制连接。一个服务器被命令（通过使用FTP指令）去“监听”另一个服务器将要初始化的连接。user-PI给一个server-PI发送一条包含另一台服务器的数据端口的PORT指令。最后双方发送相应的传送命令。用户控制器和服务器之间发送的指令和回应的严格顺序在FTP回应一节中定义。

通常，服务器负责维护数据连接——初始化和关闭它。例外的情况是，user-DTP在传输模式下要求关闭连接。在下列情况下服务器必须关闭数据连接：

1. 服务器在传输模式下完成了数据的发送，要求通过EOF关闭。

2. 服务器收到用户发来的ABORT指令。

3. 用户使用一个指令改变了端口。

FTP协议的RFC文档规范,中文版。

4. 控制连接合法关闭或因其他原因关闭。

5. 发生了无可挽救的错误。

否则服务器有选择关闭的权利，此时服务器必须对用户进程用250或226回应指出。

3.3 数据连接管理

缺省的数据连接端口：所有FTP实现必须支持缺省的数据连接端口，

只有user-PI能够初始化非缺省的端口。确定非默认数据端口：user-PI可以使用PORT指令指定一个非缺省用户端数据端口。user-PI可以使用PASV指令要求服务器端指定一个非缺省服务器端口。因为连接是由双方的地址定义的，任一方的改变都会导致不同的数据连接，在结束数据连接后允许双方使用新的端口发送指令。

数据连接的重用：在使用流式数据传输模型时，文件结束通过关闭连接指示。如果要传送多个文件，由于FTP需要暂时地控制连接记录以保证可靠的传输，此时就会出麻烦。所以连接不能立刻重新开始。解决的方法有两个，一个是确定非默认端口，另一个是使用另一种传输模式。就传输模式而言，因其固有的特点，流传输模式是不可靠的，因此无法确定连接是暂时还是永久关闭。其它传输模式（块模式，压缩模式）不通过关闭连接指出文件末尾。它们有足够的FTP编码分析数据连接以确定文件的末尾。因此使用这些传输模式可以在保持连接的情况下传送多个文件。

3.4 传输模式

下面考虑传输数据可选择的传输模式。有三种传输模式：一个是格式

化数据并允许重新开始程序；一个是为有效的传输而压缩数据；一个是对数据进行少量的处理或不进行处理。在最后一种模式下，结构属性和处理类型相互影响。在压缩模式下，表示类型决定填充的字节。

所有数据传输必须以一个文件结束符EOF结束，它可以显式给出，也可以通过关闭连接隐式给出。对于记录文件，所有记录结束符标记（EOR）是显式的，包括最后一个记录。对于以页结构传送的文件，使用“最后页”表示结束。

注意：本节从这里开始，除明确指出外，字节的意思是“传输字节”。为了传输的标准化，传送主机必须把行结束或记录结束的内部表示转

化为传输模式和文件结构指定的形式传送，接收方则进行相反的工作。IBM大型机的记录计数域可能不能为其它主机识别，所以记录结束标记在流模式下以双字节控制码传送，在块或压缩模式下以标记位传送。没有记录结构的ASCII或EBCDIC的文件，行结束符则用<CRLF>或<NL>分别指示。因为这样的转换对有些系统意味着额外的工作，所以相同的系统在传送非记录结构的文本文件时采用二进制或流表示比较合适。

FTP定义了下列传输模式：

3.4.1 流模式

数据以字节流的方式传送。使用的表示类型没有限制，允许记录结构。在记录结构文件中EOR和EOF表示为双字节控制码。控制码的第一个字

FTP协议的RFC文档规范,中文版。

节全是0。第二个字节的值为1时表示EOR，为2时表示EOF，如果要同时表示EOR和EOF，值为3。全1字节作为数据发送时必须使用双字节传送，其中数据保存在第二个字节内。如果是文件结构，通过发送方关闭连接表示EOF，接收到的所有数据就是文件内容。

3.4.2 块模式

文件以一系列数据块的方式传送，有一个或多个头字节。块头字节包

括一个计数域和描述符代码。计数域指出了数据块的总长度字节数，以此标记出下一个数据块的开始（不需要填充位）。描述符代码定义了：文件的最后块（EOF），记录的最后块（EOR），重新开始标记（参看错误恢复和重新开始一节）或可疑数据（比如，数据开始传输被怀疑是错误的或不可靠的）。最后的代码不是为了在FTP中进行差错控制。它是为了站点间交换特定类型的数据（比如，地震或天气数据），并不管本地错误（像“磁带读错误”这样的错误）接收所有数据。而只管传送，但是传送时要指出这部分是可疑的。该模式允许使用记录结构，页可以使用任何表示类型。块头包含3个字节。24位头信息中，低16位是字节计数，高8位表示描述符代码，如下所示：

+----------------+----------------+----------------+

| 描述符 | 字节计数 |

| 8 位 | 16 位 |

+----------------+----------------+----------------+

描述符代码由在描述符字节中的位标记说明。每个代码的十进制值是

字节中相应的位：

代码含义

128 数据块结束是EOR

64 数据块结束是EOF

32 数据块内有可疑错误

16 数据块是重新开始标记

以这种编码，对于特定块可能存在多个描述子编码条件，所需要的位

必须全部设置。重新开始标记包括在数据流中，它作为8位整数代表在控制连接上使用语言的可打印字节，但<SP>不得出现在其中。例如要传送6字节标记，以这种编码，对于特定块可能存在多个描述符代码的情况。所需要的位必须全部被标记。

重新开始标记包括在数据流中，它作为8位字节整数代表在控制连接上使用语言的可打印字符（比如，缺省--NVT-ASCII）。<SP>（空格，在合适的语言中）不可以使用在重新开始标记里。

例如，要传输一个6字符标记，如下：

FTP协议的RFC文档规范,中文版。

3.4.3 压缩模式有三种类型的信息可以被传送：常规数据，用字节串方式传送；压缩

数据，由重复和填充组成；控制信息，用双字节的escape序列发送。如果常规发送的数据n>0字节（小于等于127），这些n字节前加一个字节，最左位是0，右7位是数字n。

字节串：

1 7 8 8

+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+

|0| n | | d(1) | ... | d(n) |

+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+

^ ^

|--- n个字节的数据 ---|

d(1),..., d(n)表示n个字节的数据串，计数n必须准确。

要压缩一个数据位d的N个重复字符串，用下面的两个字节传送：

重复的字节:

2 6 8

+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+

|1 0| n | | d |

+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+

一串n个填充字节可以压缩为一个字节，而填充字节根据表示类型的不同而不同。如果类型是ASCII或EBCDIC，填充字节是<SP>（空格，ASCII代码32，EBCDIC代码64），如果是IMAGE或本地类型，填充字节是是一个0字节。

填充字符串：

2 6

+--------+--------+--------+ |描述符 | 字节计数 | |代码= 16| = 6 | +--------+--------+--------+ +--------+--------+--------+ | 标记 | 标记 | 标记 | | 8 位 | 8 位 | 8 位 | +--------+--------+--------+ +--------+--------+--------+ | 标记 | 标记 | 标记 | | 8 位 | 8 位 | 8 位 | +--------+--------+--------+

FTP协议的RFC文档规范,中文版。

+-+-+-+-+-+-+-+-+

|1 1| n |

+-+-+-+-+-+-+-+-+

escape序列是一个双字节，第一个字节是escape字节（全0），第二个字节包含了块模式定义的描述符代码。描述符代码的含义和块模式中的一样，它作用于其后串中的字节。

压缩模式对增加带宽有用，一个非常大的网络传输只需很小的CPU开销。它也可以最有效地减少像RJE主机那样产生的打印文件的大小。

3.5 错误恢复和重新开始

数据传输没有提供对位丢失或和混乱的检测，这个差错控制级由TCP实现。不过，重新开始程序提供了保护用户系统失败（包括主机失败，FTP进程失败，或潜在的网络失败）的方法。重新开始程序仅对块和压缩的数据传输模式有效。它要求数据的发送方在数据流中插入一个特殊的标记码来提供标记信息。标记仅对发送方有意义，但必须包含缺省的或控制连接的协商语言的可打印字符（ASCII 或EBCDIC）。标记可以表示位数，记录数，或任何系统识别一个数据检查点的其他信息。数据的接收方如果执行了重新开始程序，就会用接收方系统中的标记码标出相应的位置，然后把这个信息返回给用户。

发生系统失败事件后，用户可以通过FTP重新开始程序，指定标记点

来重新开始数据传输。下面是重新开始程序使用的例子：

数据的发送方在数据流中合适的点插入一个适当的标记块。接收方主

机在它的文件系统中标记相应的数据点，通过直接地或控制连接的110回应（依赖于用户的身份）把最后知道的标记信息告诉发送方。发生系统失败事件后，用户或控制进程使用一个重新开始指令让服务器在最后一个标记的位置重新开始，指令中的一个参数指出了最后一次服务器的标记。重新开始指令通过控制连接传送，并紧跟在系统发生失败时正在执行的指令（比如RETR，STOR或LIST）之后。

4. 文件传输功能

从user-PI到server-PI的通信信道建立在从用户到标准的服务器端口的

TCP连接上。用户协议解释器负责发送FTP指令和解释收到的回应；server-PI解释指令，发送应答，并指导它的DTP建立数据连接和传送数据。如果数据传输（被动传输进程）的第二方是user-DTP，通过user-FTP主机的内部协议对它进行控制；如果第二方是server-DTP，由user-PI发来的指令经过它自己的PI进行控制。如果清楚相关的可能回应，对理解本节描述的少数指令会有帮助。

4.1 FTP指令

4.1.1 访问控制指令

下列指令指定访问控制标识符（指令码在括号内给出）。

FTP协议的RFC文档规范,中文版。

用户名（USER）

它的参数是用来指定用户的Telnet字串。它用来进行用户鉴定，服务器对赋予文件的系统访问权限。该指令通常是建立数据连接后（有些服务器需要）用户发出的第一个指令。有些服务器还需要通过password或account指令获取额外的鉴定信息。服务器允许用户为了改变访问控制和/或帐户信息而发送新的USER指令。这会导致已经提供的用户，口令，帐户信息被清空，重新开始登录。所有的传输参数均不改变，任何正在执行的传输进程在旧的访问控制参数下完成。

口令（PASS）它的参数是用来指定用户口令的Telnet字符串。

此指令紧跟用户名指令，在某些站点它是完成访问控制不可缺少的一步。因为口令信息非常敏感，所以它的表示通常是被“掩盖”起来或什么也不显示。服务器没有十分安全的方法达到这样的显示效果，因此，user-FTP进程有责任去隐藏敏感的口令信息。

帐户（ACCT）

它的参数是用来指定用户帐户的Telnet字串。此指令不需要与USER指令相关，一些站点可能需要帐户用于登录，另一些仅是为了特殊的访问，比如存储文件。在后一种情况下，此命令可在任何时候发送。

用下面的回应码来区分这些情况以实现自动控制：如果登录需要帐户

信息，对成功的PASSword指令的回应码是332。另一方面，如果帐户信息不是登录时必须的，对成功的PASSword指令的回应码是230。如果帐户信息在以后的某指令发出后需要，服务器应返回332或532回应码，这要依赖于它是存储（尚不能确定ACCounT指令的接收）或放弃该指令。

改变工作路径（CWD）

该指令允许用户在不改变它的登录和帐户信息的状态下，为存储或下

载文件而改变工作目录或数据集。传输参数不会改变。它的参数是指定目录的路径名或其他系统的文件集标志符。

回到父目录（CDUP）

该指令是CWD的一种特殊情况，它用来简化传输目录树的程序，因为

各操作系统对父目录命名使用不同的语法。回应码与CWD的回应码相同。参看附录二获得更详细的信息。