RFC959 文件传输协议（FTP）翻译
发布时间：2023-07-12 21:14:54
文章目录
-
- 前言
- 本备忘录的状态
- 1. Introduction
- 2. Overview
-
- 2.1 历史
- 2.2 术语
- 2.3 The FTP Model
- 3. Data Transfer Functions
-
- 3.1 Data Representation And Storage
-
- 3.1.1 DATA TYPES
-
- 3.1.1.1 ASCII TYPE
- 3.1.1.2 EBCDIC TYPE
- 3.1.1.3 IMAGE TYPE
- 3.1.1.4 LOCAL TYPE
- 3.1.1.5. 格式控制
-
- 3.1.1.5.1. 非打印（NON PRINT）
- 3.1.1.5.2. TELNET 格式控制
- 3.1.1.5.3. CARRIAGE CONTROL(ASA)
- 3.1.2 DATA STRUCTURES
前言
想做一下FTP的项目，带师说要参考RFC做才能标准化，先翻译一下。
官方文档：https://www.rfc-editor.org/rfc/inline-errata/rfc959.html
再别人翻译好的：https://github.com/sixsixQAQ/doc
本备忘录的状态
本备忘录是文件传输协议（FTP）的官方规范。本备忘录的分发不受限制。
在本版本规范中，有下列新的可选命令：
- CDUP
- Change to Parent Directory
- SMNT
- Structure Mount
- STOU
- Store Unique
- RMD
- Remove Directory
- MKD
- Make Directory
- SYST
- System
注意，本规范兼容以往的版本。
1. Introduction
FTP的目标在于：
- 促进文件共享（计算机程序/数据）
- 鼓励间接地（通过程序）使用远程计算机
- 使用户免受不同主机文件存储系统的差异。
- 高效、可靠地传输数据。
虽然用户可以通过终端使用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 之间，或一个两者之间服务器 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使用模型
注意：
- data connection可以被用于任一方向。
- 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 规定，
对于ASCII 和 EBCDIC 格式参数将在下面讨论。
3.1.1.2 EBCDIC TYPE
这种类型用来在使用 EBCDIC 编码的主机间高效地传输。
传输时，数制被表示为 8 位的 EBCDIC 字符。EBCDIC 与 ASCII 类型的区别仅仅是字符
编码的不同。
行尾（End-of-Line）很少用在 EBCDIC 类型中表示结构，必要时应该用
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 垂直格式控制（也就是，
打印过程将适当的解释这些控制符。
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 走纸到下页顶
＋ 不移动，也就是覆盖打印
打印机过程必须有方法区分结构体的结束。如果文件具有记录结构（后面将介绍）就没
有问题；记录会在传输与存储中显式的标记。如果文件没有记录结构，将以
记作为打印时行的分隔，但这些格式符会被 ASA 控制符覆盖。
END
3.1.2 DATA STRUCTURES
未完待续