RFC959 文件传输协议（FTP）翻译

发布时间：2023-07-12 21:14:54

前言

毕设课题"FTP客户端与服务器的设计与实现"。

带师说要参考RFC做才能标准化，先翻译一下。

官方文档：https://www.rfc-editor.org/rfc/inline-errata/rfc959.html

再别人翻译好的：https://github.com/sixsixQAQ/doc

最好是自己对照着读原文，翻译的有点错。

本备忘录的状态

本备忘录是文件传输协议（FTP）的官方规范。本备忘录的分发不受限制。

在本版本规范中，有下列新的可选命令：

1. CDUP
   • Change to Parent Directory
2. SMNT
   • Structure Mount
3. STOU
   • Store Unique
4. RMD
   • Remove Directory
5. MKD
   • Make Directory
6. SYST
   • System

注意，本规范兼容以往的版本。

1. Introduction

FTP的目标在于：

1. 促进文件共享（计算机程序/数据）
2. 鼓励间接地（通过程序）使用远程计算机
3. 使用户免受不同主机文件存储系统的差异。
4. 高效、可靠地传输数据。

虽然用户可以通过终端使用FTP，但是它主要是设计给程序使用的。

本规范的尝试是为了以一般、简单的协议设计满足多样化用户的需求，比如巨型机、迷你主机、个人工作站、TACs。

2. Overview

本部分介绍 历史、术语、FTP模型。

本节定义的术语仅仅指哪些在FTP中有特殊含义的。一些术语特定于FTP模型的，在回顾术语时，部分读者可能会从本节的FTP模型寻求帮助。

文件传输协议

2.1 历史

FTP已经发展了很多年了。附录三中是按时间顺序排列的FTP 的RFC文档。这些包含了1971年在麻省理工学院第一次提议在主机上实现的文件传输机制（RFC114），以及在RFC141中的评论和讨论。

RFC172 提供了一个面向用户级的文件传输协议（在不同主机之间，包括终端IMP）。一个修订版RFC265重述了 FTP 以供额外审查，而 RFC 281 建议进一步修改。

RFC 354 废弃了 RFC 264 和 265。文件传输协议扩展现在被定义为用于 ARPANET 上主机之间文件传输的协议，FTP 的主要功能定义为在主机之间高效、可靠地传输文件，并允许方便地使用远程 文件存储功能。

RFC 385 进一步评论了协议的错误、重点和补充内容，而 RFC 414 提供了有关工作服务器和用户 FTP 的状况报告。 1973 年发布的 RFC 430（以及其他太多的 RFC）对 FTP 提出了进一步的评论。 最后，“官方”FTP 文档作为 RFC 454 发布。

到 1973 年 7 月，FTP 的最新版本已发生相当大的变化，但总体结构保持不变。 RFC 542 作为新的“官方”规范发布，以反映这些变化。 然而，许多基于旧规范的实现并未更新。

1974 年，RFC 607 和 614 继续对 FTP 进行注释。 RFC 624 提出了进一步的设计更改和较小的修改。 1975 年，题为“Leaving Well Enough Alone”的 RFC 686 讨论了 FTP 所有早期版本和后期版本之间的差异。 RFC 691 对 RFC 686 进行了关于打印文件主题的小修订。

在从 NCP 过渡到 以TCP 作为底层协议的推动下，以及以往的努力下，RFC 765 诞生并作为FTP在TCP上的规范。

当前版本的 FTP 规范旨在 纠正一些小的文档错误，以改进 解释一些协议特性，并添加一些新的 可选命令。

文件传输协议
特别是，以下新的可选命令包含在 本版规范：

CDUP - Change to Parent Directory

SMNT - Structure Mount

STOU - Store Unique

RMD - Remove Directory

MKD - Make Directory

PWD - Print Directory

SYST - System

本规范与之前版本兼容。 按照之前的规范执行的程序会自动符合本规范。

2.2 术语

• ASCII
  ASCII字符集和在ARPA-Internet Protocol Handbook中定义的一样。在FTP中，ASCII被定义为8bit码集合的低半部分（也即最高有效位为0）
  （译者注：2的8次方是2的7次方的两倍，所以是“半”部分）

• accese controls
  access controls定义用户对使用系统的访问权限，以及系统上的文件。access controls是防止未经授权或意外使用文件所必须的。进行访问控制是服务器FTP进程的特权。

• byte size
  FTP 中值得关注的字节大小：逻辑上的字节大小，也即文件的字节大小；数据传输时的传输字节大小。传输字节大小总是8bit。传输字节大小不一定要和系统存储时的字节大小一样，也不是逻辑上用于解读数据结构的字节大小。
  （译者注：早期有的系统一个字节不是8bit）

文件传输协议

• control connection
  USER-PI 和 SERVER-PI 之间的通信路径，用于交换命令和回复。此连接遵循 Telnet 协议。

• data connection
  用于传输数据的全双工连接，以指定模式和类型。传输的数据可能是 一个文件、整个文件或多个文件。路径可能是一个服务器 DTP 和一个用户 DTP 之间，或两个server- DTP。

• data port
  passive数据传输进程会“监听”data port，从active传输进程获取一个连接，以便打开data connection。

• DTP
  数据传输进程建立并管理data connection，DTP可以是passive或者active。

• End-of-Line
  end-of-line序列，定义了打印行的分隔。这个序列是回车、换行。

• EOF
  end-of-file条件，定义了被传输文件的结尾。

• EOR
  end-of-record条件，定义了被传输记录（record）的结尾。

• error recovery
  一个允许用户从某些错误中恢复的过程，例如主机系统或传输过程出现故障。在FTP中，error recovery可以涉及在给出的检查点重启一个文件传输。

文件传输协议

• FTP commands
  包含控制信息的命令集合，它们从user-FTP流向server-FTP。

• file
  一组有序的计算机数据（包括程序）， 任意长度，由路径名唯一标识。

• mode
  数据通过data connection被传输时，会以不同mode进行。mode定义了数据传输的格式，包括EOR和EOF。FTP中定义的modes在Transmission Modes节有描述。

• NVT
  Network Virtual Terminal，定义在Telnet协议中。

• NVFS
  Network Virtual File System。它定义了一个网络文件系统，具有标准命令和路径名约定。

• page
  文件可以被构造成一组相互独立的page的集合。FTP支持传输不连续的文件，以相互独立的索引页。

• pathname
  路径名被定义为字符串，它必须由用户输入到文件系统以标识一个文件。路径名通常包含设备和（或）目录名称，以及文件名规范。FTP 尚未指定标准的路径名约定。每个用户必须遵循传输时使用的文件系统的文件命名约定。

• PI
  The protocol interpreter。协议的用户端和服务器端有着不同的角色，在用户协议解释器（user-PI）和服务器协议解释器（server-PI）中进行实现。

文件传输协议

• record
  顺序文件可以被构造成多个连续的叫做record的部分。FTP 支持记录结构，但文件不需要有记录结构。

• reply
  reply是服务器发送给用户的确认（肯定或否定），通过control connection来回复 FTP commands。replay的一般形式是完成代码（一般是错误码）后根文本字符串。代码通常供程序使用，而文本通常用于人类用户。

• server-DTP
  The data transfer process,在正常的active状态下，会用监听端口data port建立data connection。它设置传输和存储的参数，并以命令的形式传输来自其 PI 的数据。DTP可以以passive状态来监听，而不是在data port上发起一个连接。

• server-FTP process
  一个或一组进程，和一个user-FTP（也可能是另一个服务器）协作执行文件传输功能。这些功能由一个协议解释器（PI）和数据传输进程（DTP）组成。

• server-PI
  服务器协议解释器监听端口L，以获取一个来自user-PI的连接，并建立一个control communication connection。它从user-PI接收标准的FTP commands、发送回复，以及管理server-DTP。

• type
  数据的表示类型，用于数据传输和存储。type意味着数据存储时间和数据传输之间的转换。FTP中定义的表示类型在Rstablishing Data Connections章节有介绍。

文件传输协议

• user
  一个人或者一个代表想要获取文件传输服务的人的进程。人类用户可以直接和server-FTP进程交互以使用服务器，但是user-FTP进程的使用是首选，因为协议设计偏向于自动机。

• user-DTP
  一个数据传输进程，监听数据端口以获取来自server-FTP进程的连接。 如果两台服务器相互之间传输数据，则它们的user-DTP处于非活动状态。

• user-FTP process
  一些功能的集合，包括一个协议解释解释器、一个数据传输进程、一个用户接口。它和一个或多个server-FTP process协作以执行文件传输功能。用户接口允许用户在命令回复对话中使用本地语言。

• user-PI
  用户协议解释器，发起从端口U到srver-FTP process的control connection，发起FTP commands，控制user-DTP——如果它属于文件传输的一部分。

文件传输协议

2.3 The FTP Model

考虑了上面的定义，能够画出下面的FTP服务的模型：

图1：FTP使用模型

注意：

1. data connection可以被用于任一方向。
2. data connection不需要全时间段都存在。

在图1描述的模型中，user-PI启动control connection。control connection遵循Telnet protocol协议。在user初始化时，标准的FTP commands被user-PI编译并通过control connection发送给服务器进程。（user可以绕过user-PI进程，建立到server-FTP的直接的control connection，例如一个TAC终端，并独立地生成标准的FTP commands。） 标准的回复从server-PI发送到user-PI以响应命令，通过control connection。

FTP命令指定了data connection的参数（data port, transfer mode, representation type, structure）和文件系统操作的性质（store, retrieve, append, delete等）。user-DTP或其指定者应该监听特定的data port，服务器根据指定的参数发起data connection并传输数据。对于通过control connection发起FTP commands的主机，data port不需要在它本地。但user或者usr-FTP process必须确保监听指定的data port。还应注意的是，数据连接可用于同时发送和接收。

另一种场景下，用户可能希望在两个非本地主机之间传输文件。
user设置到两个服务器的contorl connections，然后安排两服务器之间的data connection。这种方式下，控制信息被传送给user-PI，但是数据在服务器数据传输进程之间进行。 下面是服务器-服务器交互模型：

协议要求control connection在数据传输过程中被一直打开。使用完FTP服务后关闭control connections是用户的职责，当然，这是由服务器来执行的。如果conntrol connection在没有任何命令的情况下关闭，服务器可能会在数据传输时中途退出。

• FTP和Telnet的关系

  FTP 在数据连接中使用 Telnet 协议。这可能以两种方法实现：第一，用户 PI 或服务器
  PI 在它们的实现过程中应用 Telnet 协议。第二，用户 PI 或服务器 PI 可能用系统中已经存在
  的 Telnet 模块。

  第二种方法使用更简单，达到了代码共享，模块化编程的目的。比第一种方法更独立和
  高效。实际上 FTP 对 Telnet 协议的依赖非常小，因此第一种方法也不一定会引入大量的代码。

3. Data Transfer Functions

文件只通过data connection传输。control contection用于传输命令，它们描述了执行的功能、命令的回复（见FTP Replies章节）。一些命令和主机之间的数据传输有关。这些数据传输命令包括MODE命令，它指定了如何转换数据的bits，以及STRUcture和TYPE命令，它们用于定义数据表示的方式。传输和表示基本上是独立的，但是Stream传输模式依赖于文件结构属性，而当使用“Compressed”传输模式时，填充字节的性质依赖于表示类型。

3.1 Data Representation And Storage

数据从发送主机的存储设备传送到接收主机的传送设备。通常需要对数据执行某种转换，因为数据存储的表示在两个系统上会有不同。For example, NVT-ASCII has different data storage representations in different systems. DEC TOPS-20s’s generally store NVT-ASCII as five 7-bit ASCII characters, left-justified in a 36-bit word. IBM Mainframe’s store NVT-ASCII as 8-bit EBCDIC codes. Multics stores NVT-ASCII as four 9-bit characters in a 36-bit word. 在不相似的系统之间传输文本时，最好将字符转换成标准的NVT-ASCII表示。发送端和接收端应该在标准表示和它们内部的表示之间执行必要转换。

由于表示不同，当在字长不同的主机之间传输二进制数据时（不是字符码）又会有问题。那就是并不总是能够知道发送端如何发送数据、接收端如何存储它。例如，从32-bit字长的系统传输32-bit的字节到36-bit字长的系统，在后一个系统中，可能需要（出于效率和实用性）将32-bit的字节右对齐存到36-bit字里。无论如何，用户应该能够选择数据表示和传输功能。需要注意的是，FTP提供了非常优先的数据类型表示。超出它能力范围的转换应该由用户直接完成。

3.1.1 DATA TYPES

用户指定的数据表示由FTP管理。 这个类型可以是隐式地（ASCII或者EBCDIC）或者显式地（本地字节）为解释器定义字节大小，作为“逻辑字节大小”。注意，这个和data connection上传输所用的字节大小（被称为传输字节大小）没有关系，不能混淆它们。例如，NVT_ASCII的逻辑字节大小是8bit。如果类型是本地字节，那么TYPE命令有个必选的第二个参数，用于指定逻辑字节大小。传输字节大小总是8bit。

START 此处起用了别人翻译好的

3.1.1.1 ASCII TYPE

这是缺省类型，必须被所有 FTP 实现支持。主要用来传输文本文件，除非主机双方认
为 EBCDIC 类型更方便。发送方将内部字符表示转换为标准的 8 位 NVT-ASCII 表示（参见 Telnet 协议）。接收方将标准格式数据转换为它自己的内部格式。NVT 规定，<CRLF>序列用来表示文本一行的结尾。（参见本章末文件结构中有关数据表示和存储的讨论）用标准 NVT-ASCII 表示意味着数据必须解释为 8 位字节。

对于ASCII 和 EBCDIC 格式参数将在下面讨论。

3.1.1.2 EBCDIC TYPE

这种类型用来在使用 EBCDIC 编码的主机间高效地传输。
传输时，数制被表示为 8 位的 EBCDIC 字符。EBCDIC 与 ASCII 类型的区别仅仅是字符
编码的不同。
行尾（End-of-Line）很少用在 EBCDIC 类型中表示结构，必要时应该用<NL>。

3.1.1.3 IMAGE TYPE

数据以 8 位连续字节流传输。接收端必须将数据存储为连续位。存储系统结构可能要将
文件（或对于记录结构文件来说，每个记录）填充到合适的边界（字节、字或块）。填充的
字节必须为 0，并追加到文件末尾（或每个记录末尾）。必须有方法来指出填充字节，当取
得文件时，以将填充字节剔除。填充转换方法应当公开，使用户可以方便的处理文件。
图像类型目的是为了高效地存储和检索文件，以及传输二进制文件。建议所有的 FTP
实现都应该支持这个类型。

3.1.1.4 LOCAL TYPE

数据以参数 Byte size 指定的逻辑字节长度传输。字节长度值必须是十进制整数，并且没
有缺省值。逻辑字节长度不一定要和传输字节长度一样。如果字节长度不同，那么逻辑字节
将忽略传输字节边界连续打包，并在最后做必要的填充。
当数据到达接收端主机时，将以独立的方式被转换为特定主机的逻辑字节长度。这个转
换过程必须是可逆的（就是说，用同样的参数会产生同样的文件）并且应该被 FTP 实现者
公开。
例如，用户发送 36 位浮点数到一个 32 位字长的主机时可以以本地字节长度 36 来发送。
接收端主机将存储逻辑字节，以方便操作。在这个例子中，将 36 位的逻辑字节放入 64 位双
字中将满足需要。
另一个例子中，一对用 36 位字长的主机间用“TYPE L 36”传送数据。数据将用 8 位传
输字节包装，因此 9 个传输字节代表两个主机字。

3.1.1.5. 格式控制

ASCII 和 EBCDIC 类型也支持第二个可选的参数。这代表了一种纵向的文件格式控制。
以下数据表示类型在 FTP 中定义：
一个被传输到主机的字符文件可能具有以下三个目的之一：为了打印；为了存储用来以
后重现；为了处理。如果文件传送是为了打印，接收主机必须知道垂直控制是如何被表示的。
第二种目的中，可能需要在主机中存储为一个文件，日后将其重现为一样的格式。最后一种
目的中，必须保证将文件从一主机传输到另一主机并在第二台主机上处理文件并不带来麻
烦。单独的 ASCII 或 EBCDIC 格式不能满足所有这些条件。因此，这些类型具有第二个参
数指定以下三种格式之一：

3.1.1.5.1. 非打印（NON PRINT）

如果第二个格式参数被省略，这将是缺省格式。非打印格式必须被所有 FTP 实现支持。
文件不要包含垂直格式信息。如果文件被送到打印过程，那么打印过程将假定使用标准
的间距和页边距值。
一般来说，这个格式被用作处理或存储。

3.1.1.5.2. TELNET 格式控制

文件包含 ASCII/EBCDIC 垂直格式控制（也就是，<CR>,<LF>,<NL>,<VT>,<FF>），
打印过程将适当的解释这些控制符。<CRLF>表示行末。

3.1.1.5.3. CARRIAGE CONTROL(ASA)

文件包含 ASA（FORTRAN）垂直格式控制字符。（参见 RFC 740 附录 C；《Communications of the ACM》7 卷，10 章，606 页，1964 十月）ASA 标准规定，每行或记录的头一个字符不
用来打印。这个字符用来决定本行或记录打印机的垂直走纸量。
ASA 标准指定如下控制字符：
字符 垂直间距
空 走纸一行
0 走纸两行
1 走纸到下页顶
＋ 不移动，也就是覆盖打印
打印机过程必须有方法区分结构体的结束。如果文件具有记录结构（后面将介绍）就没
有问题；记录会在传输与存储中显式的标记。如果文件没有记录结构，将以<CRLF>行尾标
记作为打印时行的分隔，但这些格式符会被 ASA 控制符覆盖。

END

3.1.2 DATA STRUCTURES

除了不同的表示类型外，FTP还允许指定文件结构。FTP中指定了下面三个文件结构：

• file-structure
  没有内部结构，并且文件是连续的数据字节的序列。

• record-structure
  文件由顺序的记录组成。

• page-structure
  文件由相互独立的索引页面组成。

如果没有使用STRUcture命令。默认为file-structure。但是对于文本文件，FTP必须能够处理文件结构和记录结构两种类型。文件的结构会影响文件传输模式（见Transmission Modes章节）、文件的解释与存储。

文件的“自然”机构依赖于存储文件的主机。源代码文件，在IBM大型机上通常存储在固定长度记录，但在DEC TOPS-20 上是分割成行的字符流，例如通过 <CRLF>。要让文件传输在这些不同的站点之间可用，就必须有某种方式让网站能够认识对方对文件的假设。

在文件以file-structure结构发送到record-oriented的主机时，存在一个问题：主机应该使用什么标准将文件划分为记录，以便在可以本地进行处理。如果这样的划分是必要的，FTP实现应该使用end-of-line序列，ASCII是<CRLF>，EBCDIC是<NL>，它们是分隔符。如果FTP实现采用这种技术，那么就必须准备好逆变换，以处理检索取回的文件是file-structure。

3.1.2.1 FILE STRUCTURE

文件结构是默认的，如果STRUcture命令未被使用。

3.1.2.2 RECORD STRUCTURE

对于text文件（也就是使用TYPE ASCII或EBCDIC），记录结构必须被所有FTP实现。

3.1.2.3. PAGE STRUCTURE

为了传输不连续的文件，FTP定义了页结构。

（暂略）

3.2 ESTABLISHING DATA CONNECTIONS

传输数据的机制包括：设置数据连接到合适的端口，选择用于传输的参数。user-DTP和server-DTP都有一个默认的数据端口。user进程的默认数据端口和控制连接的端口相同。server进程的默认数据端口是与控制连接相邻的端口。

传输字节大小是8bit。这个字节大小只与实际传输的数据相关，它不影响主机文件系统中数据的表示。

被动数据传输进程（可以是一个user-DTP或者第二个server-DTP）应该在发送传输请求命令之前监听数据端口。FTP请求命令决定了数据传输的方向。服务器一旦接收到传输请求，就会发起到指定端口的数据连接。连接建立后，数据传输将在两端DTP间进行，同时server-PI会向user-PI发送确认回复。

每个FTP实现必须支持使用默认数据端口，只有USER-PI可以使用变化的非默认端口。

用户可以通过PORT命令来指定一个可选的数据端口。用户可能想要将文件转储到TAC行式打印机或从第三方主机取回（下载）。在后一种情况下，user-PI同时建立到两server-PI的控制连接。一个服务器被告知监听以等待另一端发起一个连接。user-PI向一个server-PI发送PORT命令来之处另一端的数据端口。最后，两个server都被发送了适当的传输命令。在useer-controller和servers之间 确切的命令序列和回复的发送定义在FTP Replies章节。

一般来说，维护数据连接——发起和关闭它，是服务器的责任。例外情况是，当user-DTP以传输模式发送数据时，该传输模式需要连接被关闭以指示EOF。以下情况，服务器必须关闭数据连接：

1. 服务器已经完成了传输模式下的数据发送，并且该传输模式需要关闭连接以指示EOF。
2. 服务器从user收到了ABORT命令。
3. 端口指定被user发送来的命令改变。
4. 控制连接被合法地关闭，或以其他方式关闭。
5. 发生了不可恢复的错误。

其他情况下是否关闭连接是服务器可选择的，这种情况下，服务器必须（只能）用250或226响应通知用户进程。

3.3 DATA CONNECTION MANAGEMENT

默认的数据连接端口：
所有FTP实现必须支持使用默认的数据连接端口，而且只有user-PI可以使用非默认的端口。

协商的非默认数据端口
user-PI可以用PORT命令，来指定一个非默认的user side数据端口。user-PI可以用PASV命令请求服务端指定一个非默认的服务端数据端口。连接由一对地址表示，所以上面两种操作之一都也可以得到不同的数据连接，之后仍然可以用这两个命令在数据两端来使用新的端口来连接。

数据连接复用
当使用流模式传输数据时，end-of-file必须通过关闭连接来指示。这导致来一个问题：如果多个文件要在一个会话中传输，TCP需要等待一个time-out时间来确保可靠通信，所以不能马上重新连接。

有两个办法解决这个问题。第一个是协商一个非默认端口。第二是使用另一种传输模式。

对于传输模式，流传输模式有天生的不可靠性，因为无法确定连接是否提前关闭。其他传输模式（块模式、压缩模式）不用关闭连接来指示end-of-file。它们有足够的FTP编码，数据连接可以解析来确定end-of-file。因此使用这些模式可以使数据连接保持打开，以用于多个文件传输。

3.4 TRANSMISSION MODES

传输数据下来要考虑的，就是选择合适的传输方式。有三种模式：
一个格式化数据并允许重新开始过程；
一个压缩数据以高效传输；
一个不加修改和处理地传输数据。

最后一种模式与结构属性共同决定处理过程。在压缩模式中，表示类型决定了填充字节。

所有的数据传输必须以end-of-file结束，这可能是显式地表示，或隐式地以关闭连接来表示。对于使用记录结构的文件，所有的EOR都必须是显式的，包括最后一个记录。对于使用页结构传输的文件，使用“末页”的页类型。

注意：在本章其他部分，除非明确指出，字节都表示“传输字节”。

为了使传输标准化，发送主机将会把它内部的end-of-line和end-of-record表示转换为传输时的格式——这个格式预先由传输模式和文件结构描述，然后接收主机会执行逆转换，把它们转成内部表示。一个IBM大型机的记录计数字段可能不会被另一个数据识别，因此end-of-record信息可能在流模式会以2字节的控制码传输，或者块模式和压缩模式中作为标志位。end-of-line在没有记录结构的ASCII或EBCDIC文件中应该分别被<CRLF>或<NL>指示。由于这些转换对系统意味着额外的工作，相同系统传输非记录结构化的文本文件时，可能希望使用二进制表示和流传输模式。

FTP定义来下列传输模式：

3.4.1 STREAM MODE

数据作为字节流传输。对表示类型没有限制。允许记录结构。

在一个记录结构的文件中，EOR和EOF各自被一个2字节的控制码指示。第一个字节都是同样的转义字符。第二个字节中，EOR将低置1，其他位置0；EOF则将第二低位置1；也就是说这个字节对于EOR来说是1，对于EOF来说是2。EOR和EOF可能在传输结束时通过使最低两位置1来同时指定（就是值3）.。如果要发送转义字符，需要用转义字符来转义字符。

如果结构是文件结构，发送主机通过关闭数据连接来指示EOF，传输的所以字节就是数据原始字节。

3.4.2 BLOCK MODE

文件文以一系列数据块传输，前面是一个或多个标头字节。标头字节包含一个计数字段，一个描述符码。计数字段指示数据块字节的总数，从而表示下一个数据块的开始（没有填充位）。描述符码定义了：文件的最后一个块（EOF），记录中的最后一个块（EOR），重新开始标记（见Error Recovery and Restart章节）或者怀疑数据（也就是被怀疑在传输中可能不可靠的数据）。

（暂略）

3.4.3 COMPRESSED MODE

（暂略）

3.5 ERROR RECOVERY AND RESTART

没有提供检测数据丢失或乱序的方法。这个级别的错误控制由TCP处理。但是必须提供一个重新启动过程，以保护用户免受严重的系统故障（包括主机、FTP进程或底层网络的故障）。

重新启动过程只定义在块模式和压缩模式的数据传输。它要求数据发送者在数据流中插入一个特殊的标志码，它带有标志信息。标志码只对发送者有意义，但是必须是可打印的字符组成的——默认或者协商的control connection语言（ASCII或EBCDIC）中的。标志可以是位计数，记录计数，或者其他信息——系统通过它们可以识别数据的检查点。数据的接受者如果实现了重新启动过程，将会在接收系统中标记标志对应的位置，并将此信息返回给用户。

如果系统的事件失败，用户可以通过识别标记点，使用重新启动测哼需来重新开始数据传输。下面的例子阐述了重新启动程序的使用。

数据的发送者在数据流的适当位置插入一个标记块。接收主机在它的文件系统中标记相应的数据点，并向用户传达传达最后已知的发送者和接受者标志信息——直接响应或在control connection中回复110（取决于发送者是谁）。如果系统发生故障，用户或控制器进程通过发送带有服务器标记代码作为参数的重启命令，将服务器重新启动到上次标记的位置。重启命令通过控制连接来传输，并且后面紧跟错误发生时执行的命令（如RETR，STOR，LIST）。

4. FILE TRANSFER FUNCTIONS

从user-PI到server-PI的通信通道是以TCP连接来建立的，从用户到标准的服务器端口。user-PI负责发送FTP命令、解释收到的回复。server-PI解释命令、发送回复、指挥它的DTP建立数据连接和传输数据。如果数据传输（被动传输进程）的另一端是user-DTP，则user-DTP被user-FTP主机的内部协议管理。如果数据传输的另一端是server-DTP，则它被server-PI根据user-PI发送来的命令控制。FTP的回复在下一节讨论。本节描述一些命令，对理解可能出现的回复很有帮助。

4.1 FTP COMMANDS

4.1.1 ACCESS CONTROL COMMANDS

下来的命令指定了访问控制标识符。
（括号里面是命令的代码）

• USER NAME（USER）
  参数字段是一个用来标识用户的Telnet字符串。当访问server的文件系统时，它需要进行用户的鉴别。这个命令一般是在control connection建立后（一些服务器要求这一点）用户发送的第一个命令。有的服务器还需要附加的识别信息，例如密码 和/或 账户命令。服务器允许在任何时候输入一个新的USER命令，以改变访问控制 和/或 账户信息。这还有以下效果：刷新已经提供的用户、密码和账户信息然后再次开始登录步骤。所有的传输参数不改变，并且所有正在进行的文件传输在旧的访问控制参数下完成。

• PASSWORD（PASS）
  参数字段是一个Telnet字符串，指明了用户的密码。这个命令必须紧跟在用户名命令之后，而且对于有些站点，还要完成用户的访问控制鉴别。由于密码信息相当敏感，应该使用掩码代替或禁止回显。显然服务器没有办法做到这一点，因此隐藏敏感的密码信息就是user-FTP进程的责任。

• ACCOUNT（ACCT)
  参数字段是一个Telnet字符串，标识了用户的账户。这个命令不需要和USER命令相关。一些站点可能需要一个账户来登录，另一些站点仅用于特殊的访问权限，例如存储文件。后一种情况下，这个命令可能在任何时候到达。

  有一些响应码用来自动区分这些情况：当需要账户信息来登录时，PASSword命令成功的响应码是332。另一种情况如果账户信息不是用来登录的，PASSword命令成功响应码是230。如果帐户信息需要在随后的对话命令中给出，服务器应该根据是保留（等侍收到 ACCounT 命令）还是放弃命令来相应的返回 332 或 532。

• CHANGE WORKING DIRECTORY（CWD）
  这个命令允许用户以不同的目录进行文件存储或检索，而不用改变登录或账户信息。传输参数同样未改变。参数是一个路径名，指定了一个目录或者其他系统上的文件组名。

• CHANGE TO PARENT DIRECTORY（CDUP）
  这个命令是CWD的特例。因为在不同的系统下父目录的表达可能使用不同的语法，所以可以用这个命令简化目录树的传输实现。它的响应码应该和CWD的响应码相同。更多信息见附录2。

• STRUCTURE MOUNT（SMNT）
  这个命令允许用户挂载一个不同的文件系统数据结构，而不用更改他的登录或账户信息。传输参数不会改变。参数是一个路径名，指定了一个目录或其他系统上的文件组名。

• REINITIALIZE（REIN）
  这个命令终止一个USER，刷新所有的I/O和账户信息——除了正在传输的进程，会等它们完成。所有的参数重设为默认值，控制连接保持打开。此时等同于控制连接刚刚建立的状态。这个命令之后可能需要USER命令。

• LOGOUT（QUIT）
  这个命令终止一个USER，而且如果没有文件在传输，服务器会关闭控制连接。如果在传输，连接会保持打开以等待响应结果，然后服务器会关闭它。如果user-process正在为多个USERs传输文件但是不希望关闭连接再重新建立，应该使用REIN命令而非QUIT命令。

  控制连接如果非预期地关闭，会引起服务器产生等同于ABOR和QUIT命令的行为。

4.1.2 TRANSFER PARAMETER COMMANDS

所有的数据传输参数都有默认值，而且制定了数据传输参数的命令只有在要改变默认值时才需要参数。默认值是最后一次指定的值，或者未指定，则是标准默认值。这意味着服务器必须“记住”可用的默认值。这些命令可以在 FTP 服务请求前以任何顺序执行。下面这些命令用来指定数据传输参数：

• DATA PORT （PORT）
  参数指定了数据连接时的HOST-PORT。user和server都有默认的数据端口，并且在一般情况下这条命令和它的响应都不需要。如果使用了这个命令，那它的参数是一个32bit的主机地址和16bit的TCP端口地址的级联。地址信息被分解成8bit一个的数据段，每个段的值都被转换成一个10进制数（用字符串表示）。段之间用逗号分割，一个PORT命令像下面这样：

  PORT h1,h2,h3,h4,p1,p2

  h1 是因特网主机地址的高8位。

• PASSIVE (PASV)
  这个命令要求server-DTP“监听”一个数据端口（不是它的默认端口）以等待一个连接，而不是收到传输命令后主动发起连接。命令的响应包括服务器监听的主机地址和端口号。

• REPRESENTATION TYPE（TYPE）
  参数指定了表示类型，在Data Representation and Storage章节有描述。某些类型需要第二个参数。第一关参数用单个的Telnet字符表示，对于ASCII和EBCDIC的第二个格式化参数也是如此。第二个参数的本地字节表示是一个10进制整数，用于指定字节大小。参数之间用<SP>（Space，ASCII码是32）分隔开。

  下面的码用来表示类型：

  

  默认的表示类型是ASCII Non-print。如果格式化参数改变，之后又单独改变第一个参数，那么格式化参数会变回到默认的Non-print 。

• FILE STRUCTURE（STRU）
  参数是一个单独的Telnet字符码，指定了文件结构，文件结构在Data Representation and Storage章节有描述。

  下面的码用来表示文件结构：

  F - File (no record structure)
  R - Record structure
  P - Page structure 
  

  默认的结构是File。

• TRANSFER MODE（MODE）
  参数是一个单独的Telnet字符码，指定了数据传输模式，在Section on Transmission Modes章节有描述。

  下面的码用来表示传输模式：

  S - Stream
  B - Block
  C - Compressed
  

  默认的传输模式是Stream。

4.1.3 FTP SERVICE COMMANDS

FTP service commands定义了用户需要的文件传输或者文件系统功能。FTP service commands的参数一般是一个pathname。路径名的语法必须
符合服务器站点的惯例（尽量用默认标准）和control connection语言的习惯。建议的默认处理是使用最后一个指定的设备、目录或文件名，或者是本地用户的默认标准。命令可以使用任何顺序，但是 “rename from”命令必须后跟一个“rename to”命令，restart 命令必须后跟中断服务命令（例如STOR或RETR）。当要传输数据以响应FTP service commands时，应该总是通过data connection来发送，少数特定的命令除外。下面的命令指定了FTP service requests：

• RETRIEVE （RETR）
  这个命令使server-DTP传输一个文件的拷贝，在pathname中指定，到数据连接另一端的server-DTP或者user-DTP。服务器站点的文件内容和状态不应该受影响。

• STORE（STOR）
  这个命令使server-DTP接受通过data connection的数据，并把数据存为服务器站点上的文件。如果pathname指定的文件在服务器站点已经存在，则它的内容会被传输的数据覆盖。如果不存在，就创建一个新的。

• STORE UNIQUE（STOU）
  这个命令很像STOR命令，但是它的会在当前目录下以唯一的文件名创建文件。250 Transfer Started response中必须包含生成的文件名。

• APPEND（with create）（APPE）
  这个命令使得server-DTP接受从data connection传来的数据并存储在服务器文件中。如果指定的文件已经存在，则数据应该附加到那个文件，否则就创建那个文件。

• ALLOCATE （ALLO）
  一些服务器可能需要这个命令来分配充足的空间来保存传输的新文件。参数应该是一个10进制整数，表示存储文件要分配的字节数（使用逻辑字节大小）。对于以记录或页结构发送的文件，一个最大记录或页大小也可能是必须的，这个值在第二个参数字段中用10进制整数表示。第二个参数是可选的，但是当它存在时，应该用三个Telnet字符<SP>R<SP>和第一个参数分开。命令应该后跟STORe或者APPEnd命令。对于那些不要求文件最大大小被预先声明的服务器，ALLO命令应该被当作NOOP命令对待（不操作）。对于那些只对最大记录和页大小感兴趣的服务器，第一个参数应该被忽略。

• RESTART （REST）
  参数字段指定了需要重新开始传输的文件的位置标记。这个命令不会引起文件传输，只是忽略文件中指定标记点前的数据。这个命令应该后面紧跟适当的使得文件传输恢复的FTP service command。

• RENAME FROM（RNFR）
  这个命令指定了重命名文件的旧的pathname。这个命令后面必须紧跟“rename to”命令，它指示了新的文件名。

• RENAME TO（RNTO）
  这个命令指定了新的文件路径名，文件预先在“rename from”中指定。这两个命令一切使一个文件被重命名。

• ABORT （ABOR）
  这个命令告诉服务器终止先前的FTP service command以及任何相关的数据传输。abort命令可能需要服务器的“特殊注意”，正如在Section on FTP Commands章节中所说，使服务器强制识别。如果先前的命令以及完成（包括数据传输），那么什么操作都不会采取。control connection不会被服务器关闭，但是data connection必须被关闭。

  服务器一旦收到这个命令，有两种情况：

  1）FTP service command已经完成
  2）FTP service command还在进行

  第一种情况下，服务器关闭data connection（如果它是打开着的）然后响应226回复，之处abort命令成功处理。

  第二种情况下，服务器停止正在进行的FTP service，并关闭data connection，返回426回复，表示请求服务异常终止。然后服务器发送226响应代码，表示abort命令成功处理。

• DELETE （DELE）
  这个命令使服务器站点的文件被删除，由pathname指定。如果期外一个额外的保护级别，（例如询问：“Do you really wish to delete？”），它一个由user-FTP进程提供。

• REMOVE DIRECTORY（RMD）
  这个命令移除指定路径下的目录（如果是绝对路径），或者是当前工作目录的子目录（如果是相对路径）。参看附录 II

• MAKE DIRECTORY（MKD）
  该命令在指定的路径下新建一个目录（如果是绝对路径），或者在当前工作目录下建子目录（如果路径是相对的）。参看附录 II。

• PRINT WORKING DIRECTORY（PWD）
  这个命令返回当前工作目录的名字。参看附录 II。

• LIST（LIST）
  这个命令使得从server向passive DTP发送一个列表。如果pathname指定了一个目录或者其他文件组，服务器应该发送一个指定目录的文件列表。如果pathname是一个文件，那么服务器应该发送该文件的当前信息。若参数为null，则指用户的当前工作目录或默认目录。数据传输通过data connection以ASCII或EBCDIC类型来传输。（用户必须确保TYPE是一个合适的ASCII或EBCDIC）由于不同系统的文件信息差异很大，这个信息很难被程序自动使用，但是对于人类用户却很有用。

• NAME LIST（NLST）
  这个命令从服务端发送目录列表到用户端。pathname应该指定一个目录或其他系统特定的文件组描述符。若参数为null就表示当前目录。server将只返回文件名组成的字节流，没有别的信息。数据以ASCII或EBCDIC类型通过data connection传输，合法的路径名字符串被<CRLF>或<NL>分隔。（用户依然需要确保TYPE是正确的。）这个命令是用来返回可供程序使用的信息，以供进一步地自动处理文件。例如，在实现一个“multiple get”功能时。

• SITE PARAMETERS（SITE）
  这个命令被服务器使用，用来提供特定于服务器系统的服务，这对于文件传输来说很重要，但是还不够通用，无法作为命令包含在协议里。这些服务的性质和其语法规范可以在HELP SITE命令中指处。

• SYSTEM（SYST）
  这个命令用来查明服务器的操作系统类型。回复的第一个单词应该是系统的名称——当前版本的Assigned Numbers document[4]中列出的。

• STATUS（STAT）
  这个命令通过control connection以回复的形式发送一个状态响应。命令可以在文件传输期间发送（与Telnet IP和同步信号一起——参见Section on FTP Commands章节），这种情况下，服务器将响应正在进行的操作的状态，或者它也可以在两个文件传输之间发送。在后一种情况下，命令可以有一个参数自动。如果参数是一个pathname，命令类似“list”命令，除了是通过control connection来传输的。如果给出了部分路径名，服务器可能响应指定的路径下的文件名列表或者相关属性。如果没有参数，服务器应该返回一般的server-FTP进程的状态信息。这应该包括当前所有传输参数的值和连接状况。

• HELP（HELP）
  这个命令引起服务器通过conrol connection向user发送帮助性的信息，关于其实现情况。这个命令可以带一个参数（例如，任意的命令名），并返回更多的详细信息作为响应。回复类型是211或214。建议在输入USER命令之前允许HELP命令。server可能使用这个回复来指定站点相关的参数，例如，响应 HELP SITE。

• NOOP（NOOP）
  这个命令不影响任何参数或之前输入的命令。它表示不操作，仅仅让server发送一个OK回复。

文件传输协议在控制连接上的所有通信都遵守 Telnet 协议。因为 Telnet 传输使用的语言可能是一个协商的选项，下两部分提到的所有参考信息将使用“Telnet 语言”和相应的“Telnet 行尾符”。当然可以将这些转换成 NVT-ASCII 和<CRLF>。没有其它的 Telnet 协议
规范被引用。

FTP commands是以“Telnet end of line code”终止的“Telnet strnigs”。命令码本身是字母字符，以<SP>（Space）结束，或者当没有参数时以Telnet EOL结束。命令码和命令的语义在本节描述；详细的命令语法在Commnds章节指定，详情的序列在Sequencing of Commands and Replies章节指出，使用这些命令的场景在ypical FTP Scenarios章节提供。

FTP commands可以分为 访问控制命令、数据传输参数命令、FTP service 请求命令。特定命令（例如 ABOR， STAT， QUIT）可以在数据传输进行时，通过control connection发送。一些服务器可能无法同时监控control connections和data connections，此时就要发出一些特殊的动作来引起服务器的注意 。以下有序格式是暂时推荐的：

1. 用户系统在 Telnet 流中插入 Telnet"中断过程"（Interrupt Process-IP）信号。
2. 用户系统发出 Telnet “同步”（Synch）信号。
3. 用户系统在 Telnet 流中插入命令（例如，ABOR）。
4. 服务器 PI，在接收到"IP"后，扫描 telnet 流，寻找 FTP 命令

（对于其它服务器，这些操作可能没有必要，但并不会引起意外的后果。）

4.2 FTP REPLIES

设计FTP commands的回复是用来确保请求和文件传输动作的同步，同时保证用户时刻知道服务器的状态。每个命令必须生成至少一个回复，也可以生成多个。在多个回复时必须是易于区分的。此外，一些命令出现在连续的组中，例如USER、PASS和ACCT，或者是RNFR和RNTO。回复展示了一种中间态，表示前面的命令都成功了。序列中任何点出错，都需要重新开始整个序列。

命令-响应序列的细节，将由下面一组状态图表明确表示。

一个FTP回复由一个3位数字（转换成3个数字字符传递）后跟一些文本组成。数字是用于自动处理以进行下一步的，文本是用于给人类阅读的。3位数字已经包含了足够的细细你，因此user-proecess（user-PI）不需要再检测文本，而是可以直接忽略文本或者，适当地，把它传给用户。特定情况下，文本可以是服务器特定的，所以每个回复码的文本可能不同。

一个FTP回复定义为3个数字码，后面跟着空格<SP>，然后跟着一行文本（最大长度已经指定了），并以Telnet end-of-line字符终止。当然也有这种情况：文本的长度长得超过了一行。在这种情况下，完整的文本必须放在括号中，所以user-process知道它合适可以停止读取回复（也就是停止从control connection处理输入）然后做其他事情。这需要第一行有一个特殊格式来指示有更多行，并在最后一行指定它为最后一行。至少一行要包含适当的回复码来指示状态。为了满足所有这些，决定第一行和最后一行的回复码应该相同。

因此多行回复的格式是，第一行以精确的回复码开始，后面紧跟一个'-'（一个减号），然后跟着文本。最后一行将以同行样的回复码开始，后面紧跟着空格<SP>，可选的一些文本，然后是Telnet end-of-line码。

例如：

123-First line
Second line
    234 A line beginning with numbers
123 The last line

然后user-porcess只需要搜索相同的回复码第二次出现的地方，后跟<SP>，在一行的开头，并且立刻忽略所有行。如果中间的某一行以3位数字开头，服务器必须在前面填充来避免混淆。

通过添加“人造的”第一行和最后一，这个方案允许使用标准系统例行程序来产生响应信息（例如，产生STST响应）。在极少数情况下，例行程序能够产生三位数字和<SP>开头的行，每个行的开头都应该被一些中性的文本填充，例如<SP>。

该方案假设多行回复不能嵌套。

3位回复数字的每一个都有特殊含义。这是为了让用户进程允许一组从非常简单到非常复杂的回复。第一位数字表示响应是good，bad或incomplete（参考状态图），简单的user-process可以通过仅仅检测第一位来确定它的下一步操作（按计划执行，重做，放弃等）。通过检测第二位数，user-process能够知道大概发生了什么类型的错误（例如文件系统错误、命令语法错误）。第三位数是用于信息分级（例如，RNTO命令前没有RNFR命令）。

第一位响应码有5个值：

• 1yz Positive Preliminary reply
  请求的动作正在被发起，在执行下一个命令之前期待一个回复。（user-process在完成回复之前又发送一个命令将违反协议，但是server-FTP进程排队任何命令，当一个之前的命令在执行时。）这个类型的回复能够用来指示命令已经被接受，并且user-process现在可以注意data connections，对于实现来说同时监控两者连接很困难。对于每个命令，server-FTP进程可以发送至多一个1yz回复。

• 2yz Positive Completion reply
  请求的操作已经成功完成，新的请求可以发起。

• 3yz Positive Intermediate reply
  命令已经被接受，但是请求的操作正在暂停中，等待收到更多的信息。用户应该发送又一个命令指定这个信息。这个回复用于命令序列组。

• 4yz Transient Negative Completion reply
  命令没有被接受并且请求的操作没有执行，但是错误条件是暂时的，可以再次请求。用户应该返回到命令序列（如果有的话）的开始。很难给暂时赋予一个含义，特别是两个站点（server-porcess和user-process）必须在解释上达成一致。 每个4yz的回复可能有一个不同的时间值，但总体目的都是鼓励user-process再一次尝试。判断一个响应应该属于 4yz 号还是 5yz 号的一个规则是看这个命令是否可以不加修改并在相同的用户、服务器状态下（例如，命令和参数不变，用户没有改变文件访问权限或用户名，服务器没有加新的实现）再次重复。

• 5yz Permanent Negative Completion reply
  命令没有被接受，且请求的操作没有执行。不鼓励user-process重复同样的请求（以相同的序列）。一些“永久的”错误状态可以被修正，因此人类用户也许希望控制用户进程在将来的某点上重新开始命令队列。（比如改变拼写或目录状态之后。）

下面的功能分组编码在第二位数字：

• x0z Syntax
  这些回复指语法错误。语法正确但不符合人儿和功能类别、命令为实现、命令多余。

• x1z Information
  这些回复用于请求信息的回复，例如status或help。

• x2z Connections
  设计control connection和data connection的回复。

• x3z Authentication and accounting
  对于登录进程和账户例程的回复。

• x4z Unspecified
  什么都未指定的。

• x5z File system
  这些回复指示了服务器文件系统、请求的传输、其他文件系统操作的状态。

第三位数对第二位数指定的功能目录中的每一个给出了更精确的分级含义。下面的回复清单将会阐述这一点。注意，与每个回复相关的文本是被推荐的，而不是强制的，甚至可以根据命令进行更改。回复码，必须遵循上一节的规范，也就是，服务器实现不应该为与前面描述的有细微差异的场景发明新的回复码，而是采用已经定义的码。

一个TYPE或ALLO这样的命令，成功执行后不会给user-process任何新的信息，将会产生200回复。如果一个命令因为与计算机系统无关而没有被特定的server-FTP process实现，例如在TOPS20站点的ALLO，服务器仍然希望回复一个Positive Completion reply，以便通知一般的用户进程可以继续进行其操作。这种情况的回复是202，例如，回复的文本是：“No storage allocation necessary.”。另一方面，如果请求的命令不是站点特定的且未被实现，响应是502。其改进是504，表示命令已经实现，但是请求的参数没有实现。

4.2.1 Reply Codes by Function Groups

• 200 Command okay.

• 500 Syntax error, command unrecognized.
  This may include errors such as command line too long.

• 501 Syntax error in parameters or arguments.

• 202 Command not implemented, superfluous at this site.

• 502 Command not implemented.

• 503 Bad sequence of commands.

• 504 Command not implemented for that parameter.

• 110 Restart marker reply.
  In this case, the text is exact and not left to the
  particular implementation; it must read:
  MARK yyyy = mmmm
  Where yyyy is User-process data stream marker, and mmmm
  server’s equivalent marker (note the spaces between markers
  and “=”).

• 211 System status, or system help reply.

• 212 Directory status.

• 213 File status.

• 214 Help message.
  On how to use the server or the meaning of a particular
  non-standard command. This reply is useful only to the
  human user.

• 215 NAME system type.
  Where NAME is an official system name from the list in the
  Assigned Numbers document.

• 120 Service ready in nnn minutes.

• 220 Service ready for new user.

• 221 Service closing control connection.
  Logged out if appropriate.

• 421 Service not available, closing control connection.
  This may be a reply to any command if the service knows it
  must shut down.

• 125 Data connection already open; transfer starting.

• 225 Data connection open; no transfer in progress.

• 425 Can’t open data connection.

• 226 Closing data connection.
  Requested file action successful (for example, file
  transfer or file abort).

• 426 Connection closed; transfer aborted.

• 227 Entering Passive Mode (h1,h2,h3,h4,p1,p2).

• 230 User logged in, proceed.

• 530 Not logged in.

• 331 User name okay, need password.

• 332 Need account for login.

• 532 Need account for storing files.

• 150 File status okay; about to open data connection.

• 250 Requested file action okay, completed.

• 257 “PATHNAME” created.

• 350 Requested file action pending further information.

• 450 Requested file action not taken.
  File unavailable (e.g., file busy).

• 550 Requested action not taken.
  File unavailable (e.g., file not found, no access).

• 451 Requested action aborted. Local error in processing.

• 551 Requested action aborted. Page type unknown.

• 452 Requested action not taken.
  Insufficient storage space in system.

• 552 Requested file action aborted.
  Exceeded storage allocation (for current directory or
  dataset).

• 553 Requested action not taken.
  File name not allowed.

4.2.2 Numeric Order List of Reply Codes

• 110 Restart marker reply.
  In this case, the text is exact and not left to the
  particular implementation; it must read:
  MARK yyyy = mmmm
  Where yyyy is User-process data stream marker, and mmmm
  server’s equivalent marker (note the spaces between markers
  and “=”).

• 120 Service ready in nnn minutes.

• 125 Data connection already open; transfer starting.

• 150 File status okay; about to open data connection.

• 200 Command okay.

• 202 Command not implemented, superfluous at this site.

• 211 System status, or system help reply.

• 212 Directory status.

• 213 File status.

• 214 Help message.
  On how to use the server or the meaning of a particular
  non-standard command. This reply is useful only to the
  human user.

• 215 NAME system type.
  Where NAME is an official system name from the list in the
  Assigned Numbers document.

• 220 Service ready for new user.

• 221 Service closing control connection.
  Logged out if appropriate.

• 225 Data connection open; no transfer in progress.

• 226 Closing data connection.
  Requested file action successful (for example, file
  transfer or file abort).

• 227 Entering Passive Mode (h1,h2,h3,h4,p1,p2).

• 230 User logged in, proceed.

• 250 Requested file action okay, completed.

• 257 “PATHNAME” created.

• 331 User name okay, need password.

• 332 Need account for login.

• 350 Requested file action pending further information.

• 421 Service not available, closing control connection.
  This may be a reply to any command if the service knows it
  must shut down.

• 425 Can’t open data connection.

• 426 Connection closed; transfer aborted.

• 450 Requested file action not taken.
  File unavailable (e.g., file busy).

• 451 Requested action aborted: local error in processing.

• 452 Requested action not taken.
  Insufficient storage space in system.

• 500 Syntax error, command unrecognized.
  This may include errors such as command line too long.

• 501 Syntax error in parameters or arguments.

• 502 Command not implemented.

• 503 Bad sequence of commands.

• 504 Command not implemented for that parameter.

• 530 Not logged in.

• 532 Need account for storing files.

• 550 Requested action not taken.
  File unavailable (e.g., file not found, no access).

• 551 Requested action aborted: page type unknown.

• 552 Requested file action aborted.
  Exceeded storage allocation (for current directory or
  dataset).

• 553 Requested action not taken.
  File name not allowed.

5. DECLARATIVE SPECIFICATIONS

5.1 MINIMUM IMPLEMENTATION

为了让FTP没有多余的、错误的消息地工作，下面的最小实现必须被所有服务器接受：

• TYPE
  • ASCII Non-print
• MODE
  • Stream
• STRUCTURE
  • File
  • Record
• COMMANDS
  • USER, QUIT, PORT,
  • TYPE, MODE, STRU 和它们的默认值
  • RETR, STOR,
  • NOOP

传输参数的默认值是：
TYPE - ASCII Non-print
MODE - Stream
STRU - File

所有主机必须接受上面的作为标准默认值。

5.2 CONNECTIONS

服务端协议解释器应该监听端口L。
用户和用户协议解释器应该发起全双工的control connection。
服务器和用户进程应该遵循ARPA-Internet Protocol Handbook[1]描述的Telnet协议。
服务器没有必要一定要提供命令行编辑，而是可以要求它用户主机完成。
当所有的传输和回复完成后，control connection应该在用户的请求下由server关闭。

user-DTP必须监听指定的数据端口，这可以是默认的用户端口（U）或者一个在PORT命令中指定的端口。服务器应该在它的默认端口（L-1）发起data connection。传输的方向和使用的端口将由FTP service command决
定。

注意，所有的FTP实现必须支持使用默认端口进行数据传输，而且只有USER-PI可以发起使用非默认端口。

当数据在两个服务器A和B（参考图2）之间传输时，由user-PI，C，建立到两个服务器的控制连接。

其中一个服务器A被发送一个PASV命令，告知其监听其data port，而不是在收到服务命令后主动发起一个连接。

当user-PI收到一个PASV命令的确认（其中包含主机的身份和被监听的端口）时，user-PI就会通过PORT命令将A的端口a发送给B，然后返回回复。

user-PI可以向A和B发送相应的服务命令。服务器B发起连接和传输进程。命令的回复序列在下面列出，其中消息是竖直方向同步、水平方向不同步的。

data connection应该由服务器，这遵循Establishing Data Connections中所描述的。

如果要在数据传输后关闭data connection，并且不需要关闭连接来指示文件结束，则服务器必须立刻执行此操作。

一直等到下一个传输命令是不允许的，因为用户进程已经测试了data connection以查看是否需要进行监听（记住：在发送传输请求之前，用户必须监听一个关闭的data port）

为了防止此处出现竞争情况，服务器关闭连接后会发送回复（226）（或者如果连接保持打开状态，则发送“file transfer completed”回复（250）,并且user-PI在发送新的传输命令之前应该等待其中一个回复）。

任何时候，当用户或服务器发现连接被另一端关闭时，它应该立刻读取连接上排队的任何剩余数据，并在字节的一侧发出关闭消息。

5.3 COMMANDS

命令都是Telnet 字符串，通过control connections（在FTP Cmmands一节中有描述）传输。

命令的功能和语义在Section on Access Control Commands, Transfer Parameter Commands, FTP Service Command, Miscellaneous Commands章节都有描述。这里指定了命令的语法。

命令以一个命令码开始，后面跟着一个参数字段。命令码是四个或更少的字母组成，大小写被视为等同的，因此，下面的都被视为代表retrieve命令：

RETR    Retr    retr    ReTr    eETr

这也适用于任何表示参数值的符号，例如A或a代表 ASCII类型。命令码和参数字段由一个或多个空格分隔。

参数字段由一个可变长度的字符串组成，以NVT-ASCII表示的字符序列<CRLF>（回车、换行）结尾；对于其他协商语言，可能会使用不同的行尾字符。应该注意的是，服务器在收到行尾代码之前不会采取任何操作。

语法以NVT-ASCII的方式在下面指定。参数字段中的字符都是ASCII字符，包括任何ASCII表示的十进制整数。方括号表示可选参数字段。如果未采用该选项，则隐式指定适当的默认值。

5.3.1 FTP COMMANDS

下面的是FTP命令：

USER <SP> <username> <CRLF>
PASS <SP> <password> <CRLF>
ACCT <SP> <account-information> <CRLF>
CWD <SP> <pathname> <CRLF>
CDUP <CRLF>
SMNT <SP> <pathname> <CRLF>
QUIT <CRLF>
REIN <CRLF>
PORT <SP> <host-port> <CRLF>
PASV <CRLF>
TYPE <SP> <type-code> <CRLF>
STRU <SP> <structure-code> <CRLF>
MODE <SP> <mode-code> <CRLF>
RETR <SP> <pathname> <CRLF>
STOR <SP> <pathname> <CRLF>
STOU <CRLF>
APPE <SP> <pathname> <CRLF>
ALLO <SP> <decimal-integer>
        [<SP> R <SP> <decimal-integer>] <CRLF>
REST <SP> <marker> <CRLF>
RNFR <SP> <pathname> <CRLF>
RNTO <SP> <pathname> <CRLF>
ABOR <CRLF>
DELE <SP> <pathname> <CRLF>
RMD <SP> <pathname> <CRLF>
MKD <SP> <pathname> <CRLF>
PWD <CRLF>
LIST [<SP> <pathname>] <CRLF>
NLST [<SP> <pathname>] <CRLF>
SITE <SP> <string> <CRLF>
SYST <CRLF>
STAT [<SP> <pathname>] <CRLF>
HELP [<SP> <string>] <CRLF>
NOOP <CRLF>

5.3.2 FTP COMMANDS ATGUMENTS

上面的参数字段的语法（适当的使用了BNF表示法）如下：

<username> ::= <string>
<password> ::= <string>
<account-information> ::= <string>
<string> ::= <char> | <char><string>
<char> ::= any of the 128 ASCII characters except <CR> and
<LF>
<marker> ::= <pr-string>
<pr-string> ::= <pr-char> | <pr-char><pr-string>
<pr-char> ::= printable characters, any
                              ASCII code 33 through 126
<byte-size> ::= <number>
<host-port> ::= <host-number>,<port-number>
<host-number> ::= <number>,<number>,<number>,<number>
<port-number> ::= <number>,<number>
<number> ::= any decimal integer 1 through 255
<form-code> ::= N | T | C
<type-code> ::= A [<sp> <form-code>]
                               | E [<sp> <form-code>]
                               | I
                               | L <sp> <byte-size>
<structure-code> ::= F | R | P
<mode-code> ::= S | B | C
<pathname> ::= <string>
<decimal-integer> ::= any decimal integer

5.4 SEQUENCING OF COMMANDS AND REPLIES

用户和服务器之间的通信时交互式的会话。因此，用户每发出一个命令，服务器都会给予一个回复。在发送新的命令之前，用户应该等待上一个命令的回复，以判断是成功或失败。

某些命令需要两次回复，用户也应该等待它们。这些回复可以是，例如，这些响应可能报告文件传输正在进行或已经完成，也可能是数据连接的关闭。它们是文件传输命令的第二个响应。

一组很重要的回复是连接问候。一般情况下，当连接完成时，服务器会发送220回复， “asaiting input”。用户应该在发送任何命令之前等待这个问候信息。如果服务器无法立刻接受输入，会立刻回复一个120 “expected delay”，并在准备好的时候回复220。这样用户就会知道不要因为延迟而挂断连接。

Spontaneous Replies

有时系统自发地有一个消息要发送给用户（通常是所有用户）。例如， “System going down in 15 minutes”。FTP没有规定将此类自发消息从server发送给user。推荐的做法是将这些消息在server-PI中排队，并在下一次给user-PI的回复中发送。（可能使其成为一个多行回复）

下面的表列出了每个命令可能的成功和失败的回复。这些必须被严格遵守；服务器可以替换回复中的文本，但是命令码、特定的命令回复序列不能被改变。

Command-Reply Sequences

本节展示命令回复序列。列出了每个命令的可能的回复；命令按组列出。

初步响应列在最前面（后跟它们的成功响应，缩进的或在下面的）；
然后是成功或失败的完成响应；
最后是为后序命令准备的中间响应。

这个列表是状态图的基础，状态图将在后面介绍。

Connection Establishment
        120
            220
        220
        421
Login
        USER
                230
                530
                500, 501, 421
                331, 332
        PASS
                230
                202
                530
                500, 501, 503, 421
                332
        ACCT
                230
                202
                530
                500, 501, 503, 421
        CWD
                250
                500, 501, 502, 421, 530, 550
        CDUP
                200
                500, 501, 502, 421, 530, 550
        SMNT
                202, 250
                500, 501, 502, 421, 530, 550
                
Logout
        REIN
                120
                        220
                220
                421
                500, 502
        QUIT
                221
                500
Transfer parameters
        PORT
                200
                500, 501, 421, 530
        PASV
                227
                500, 501, 502, 421, 530
        MODE
                200
                500, 501, 504, 421, 530
        TYPE
                200
                500, 501, 504, 421, 530
        STRU
                200
                500, 501, 504, 421, 530
                
File action commands
        ALLO
                200
                202
                500, 501, 504, 421, 530
        REST
                500, 501, 502, 421, 530
                350
        STOR
                125, 150
                        (110)
                        226, 250
                        425, 426, 451, 551, 552
                532, 450, 452, 553
                500, 501, 421, 530
        STOU
                125, 150
                        (110)
                        226, 250
                        425, 426, 451, 551, 552
                532, 450, 452, 553
                500, 501, 421, 530
        RETR
                125, 150
                        (110)
                        226, 250
                        425, 426, 451
                450, 550
                500, 501, 421, 530
        LIST
                125, 150
                        226, 250
                        425, 426, 451
                450
                500, 501, 502, 421, 530
        NLST
                125, 150
                        226, 250
                        425, 426, 451
                450
                500, 501, 502, 421, 530
        APPE
                125, 150
                        (110)
                        226, 250
                        425, 426, 451, 551, 552
                532, 450, 550, 452, 553
                500, 501, 502, 421, 530
        RNFR
                450, 550
                500, 501, 502, 421, 530
                350
        RNTO
                250
                532, 553
                500, 501, 502, 503, 421, 530
        DELE
                250
                450, 550
                500, 501, 502, 421, 530
        RMD
                250
                500, 501, 502, 421, 530, 550
        MKD
                257
                500, 501, 502, 421, 530, 550
        PWD
                257
                500, 501, 502, 421, 550
        ABOR
                225, 226
                500, 501, 502, 421
Informational commands
        SYST
                215
                500, 501, 502, 421
        STAT
                211, 212, 213
                450
                500, 501, 502, 421, 530
        HELP
                211, 214
                500, 501, 502, 421
Miscellaneous commands
        SITE
                200
                202
                500, 501, 530
        NOOP
                200
                500 421

6. STATE DIAGRAMS

这里我们展示了一个非常简单的FTP实现的状态图。消息码只有第一个数字被使用。每一组FTP命令或命令序列对应一个状态图。

命令分组是通过构造每个命令的模型，然后把结构相似的命令组合在一起分组得到的。

每个命令或者命令序列都有三种可能的结果：success(S)，failure(F)，error(E)。

在下面的状态图中，我们用符号B表示begin，符号W表示 wait for reply。

我们先展示代表了最大一组FTP命令的状态图：

这个模型对应下面的命令：

ABOR, ALLO, DELE, CWD, CDUP, SMNT, HELP, MODE, NOOP, PASV,
QUIT, SITE, PORT, SYST, STAT, RMD, MKD, PWD, STRU, TYPE

另一大组命令由一个非常相似的图表示：

这个模型的命令是：

APPE, LIST, NLST, REIN, RETR, STOR, STOU

注意，第二个模型也可以用于表示第一组命令。唯一的区别是，在第一组中，100系列的回复是非预期的，因此被当作错误对待。而第二组则预期（某些也需要）100系列的回复。请记住，每个命令只允许有一个100系列的回复。

剩余的图模拟了命令序列，最简单的或许是rename序列：

下一个图是一个普通的restart命令模型：

我们注意到上面的三个模型都很相似。restart不同于rename的只有两个地方，就是在第二阶段中对100系列回复的处理，第二组期望（某一些可能必须)100 系列响应。每个命令最多允许一个 100 系列的响应。

最复杂的模型图是login序列：

最后，我们展示一个一般化图表来，来描述命令和响应交互：

7. TYPICAL FTP SCENARIO

用户在主机U，想要 往/从 主机S传输文件：
一般来说，user和server的通信将会通过一个user-FTP进程进行调解/中介。下面是一个典型的场景。
user-FTP提示符显示在括号中，‘---->‘代表从主机U到主机S的命令，’<----’ 代表从主机S到主机U的回复。

LOCAL COMMANDS BY USER             ACTION INVOLVED
ftp (host) multics<CR>          Connect to host S, port L,
								establishing control connections.
								<---- 220 Service ready <CRLF>.
                                                                    
username Doe <CR>               USER Doe<CRLF>---->
                                <---- 331 User name ok,
                                         need password<CRLF>.
                                                                    
password mumble <CR>            PASS mumble<CRLF>---->
                                <---- 230 User logged in<CRLF>.
                                                                    
retrieve (local type)           ASCII<CR>
                                (local pathname) test 1 <CR> User-FTP opens local file in ASCII.
                                (for. pathname) test.pl1<CR> RETR test.pl1<CRLF> ---->
                                <---- 150 File status okay;
                                            about to open data
                                            connection<CRLF>.
                                Server makes data connection
                                to port U.

                                <---- 226 Closing data connection,
                                            file transfer successful<CRLF>.
                                                                                
type Image<CR>                  TYPE I<CRLF> ---->
                                <---- 200 Command OK<CRLF>
                                                                    
store (local type) image<CR>
(local pathname) file dump<CR> User-FTP opens local file in Image.
(for.pathname) >udd>cn>fd<CR> STOR >udd>cn>fd<CRLF> ---->
                               <---- 550 Access denied<CRLF>
                                                                    
terminate                       QUIT <CRLF> ---->
                                Server closes all
                                connections.

8. CONNECTION ESTABLISHMENT

FTP control connection是通过user进程端口U和服务器端口L直接的TCP建立的。该协议分配的服务端口是21（八进制是25），也就是L=21。

APPENDIX I - PAGE STRUCTURE

暂时用不到，先不翻译了

APPENDIX II - DIRECTORY COMMANDS

由于UNIX拥有树形的目录结构，因此目录像普通文件一样易于操作。扩展这些FTP服务器以包含那些目录创建命令很有用。由于ARPA-Internet以及其他主机也拥有树状目录，因此这些命令对这些命令的需求是很普遍的。

4个目录命令以及加入到FTP：

MKD pathname
    Make a directory with the name "pathname".
RMD pathname
    Remove the directory with the name "pathname".
PWD
    Print the current working directory name.
CDUP
    Change to the parent of the current working directory.

pathname参数应该是创建/删除一个当前工作目录的子目录的，除非pathname字符串包含足够的信息来向服务器指定其他信息，例如pathnam是绝对路径名（在UNIX或Multics中），或者路径名类似于TOPS-20的<abso.lute.path>。

REPLY CODES

CDUP命令是CWD命令的特例，包含这个命令是为了简化在程序中实现传输目录树——两个对父目录命名语法不同的操作系统之间。CDUP的回复码与CWD的回复码相同。

RWD的回复码等同于DELE的回复码。

MKD的回复码有点复杂。一个刚创建好的目录，很可能是下一个CWD命令的对象。不幸的是，MKD的参数不一定都适用于CWD。例如，当 TOPS-20 子目录仅仅由给出的子目录的名字创建。就是说，对于 TOPS-20 主机上的 FTP 服务器，下面的命令将失败：

MKD MYDIR
CWD MYDIR

新目录只能通过其绝对路径名来访问；也就是说，如果执行上面的 MKD 命令时工作在<DFRANKLIN>目录，则新的子目录只能由<DFRANKLIN.MYDIR>来访问。

甚至在 UNIX 和 Multics 主机上，MKD 的参数也不一定是适合的。如果是相对的路径名，用户必须在相同的当前路径，才能够到达子目录。依赖于应用程序，这可能是不方便的。这样，程序不一定在任何情况下都是健壮的。

为了解决这些问题，在成功完成 MKD 命令后，服务器应当返回如下形式的一行信息：

257<space>"<directory-name>"<space><commentary>

也就是服务器告知用户访问创建的目录应该用什么字符串。目录的名字可以是任意的字符；里面的双引号应该使用两个双引号转义（"quote-doubling"约定）

例如，用户连接到目录 /usr/dm，创建子目录，命名路径：

CWD /usr/dm
200 directory changed to /usr/dm
MKD pathname
257 "/usr/dm/pathname" directory created

一个内嵌双引号的例子：

MKD foo"bar
257 "/usr/dm/foo""bar" directory created
CWD /usr/dm/foo"bar
200 directory changed to /usr/dm/foo"bar

创建已经存在的目录，就会产生错误。对此服务器必须返回一个"access denied"错误回复，例如：

CWD /usr/dm
200 directory changed to /usr/dm
MKD pathname
521-"/usr/dm/pathname" directory already exists;
521 taking no action.

MKD 的失败返回代码和它的创建代码 STOR 很类似。同样的，如果在创建子目录时，和已经存在的文件的名字相同，也会引起创建子目录失败，返回“存取失败””（这在 UNIX上是个问题，不应该发生在 TOPS-20）。

本质上，因为 PWD 命令返回的信息和 MKD 命令成功返回的信息一样，成功的PWD命令也使用 257 号响应代码。

SUBTLETIES

因为这些命令在将子树从一台机器传输到另一台机器时最有用，仔细观察，MKD的参数将被翻译为当前工作目录的子目录，除非它包含足够信息来向目标主机指明是其他情况。以 TOPS-20 为例：

CWD <some.where>
200 Working directory changed
MKD overrainbow
257 "<some.where.overrainbow>" directory created
CWD overrainbow
431 No such directory
CWD <some.where.overrainbow>
200 Working directory changed

CWD <some.where>
200 Working directory changed to <some.where>
MKD <unambiguous>
257 "<unambiguous>" directory created
CWD <unambiguous>

注意第一个例子将在当前目录下创建子目录。

相反的，第二个例子的参数，包含了足够的信息，告知 TOPS-20目录是一个顶层的目录。

同样要注意在第一个例子里，用户企图用名字来访问刚建立的目录，而不是 TOPS-20 返回的信息，这是违反协议的。

如果已经有一个<overrainbow>目录，这个例子就可能出现问题，这在一些 TOPS-20 主机的实现是不确定的。

使用 RMD 命令时也有同样的问题。要点是：除非主机的路径名规则可以区分出是绝对路径还是相对路径，否则 MKD 和 RMD 命令的参数看做子目录名。MKD 命令的 257 响应必须总是包括被创建目录的绝对路径。