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

前言

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

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

本备忘录的状态

本备忘录是文件传输协议（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 之间，或一个两者之间服务器 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。还应注意的是，数据连接可用于同时发送和接收。

另一种场景下，用户可能希望在两个非本地主机之间传输文件。

（太长了受不了了，直接读英文会更快，而且很多术语翻译会很别扭，意思都有点变了）

这里放个别人翻译好的：https://github.com/sixsixQAQ/doc