FTP 协议介绍

FTP协议采用两个TCP连接来传输一个文件。

1）控制连接以通常的客户服务器方式建立。服务器以被动方式打开众所周知的用于FTP的端口21，等待

      客户的连接。客户则以主动方式打开TCP端口21，来建立连接。控制连接始终等待客户与服务器之间

      的通信。该连接将命令从客户传给服务器，并传回服务器的应答。

      由于命令通常是由用户键入的，所以IP对控制连接的服务类型是“最大限度地减少延迟”。

2）每当一个文件在客户和服务器之间传输时，就创建一个数据连接。

      由于该连接用于传输目的，所以IP对数据连接的服务特点就是“最大限度提高吞吐量”。

    交互式用户通常不处理在控制连接中转换的命令和应答。这些细节均由两个协议解释器来完成。标有“用户接口”的方框功能是按用户所提供各种。交互界面，并把它们转换成在控制连接上发送的FTP命令。类似地，从控制连接上传回的服务器应答也被转换成用户所需的交互格式。

文件类型

   1）ASCII码文件类型（默认类型）文本文件以NVT_ASCII码形式在数据连接中传输。这要求发方将本地文本文件转换成NVT_ASCII码形式，而收方将NVT_ASCII码再还原成本地文本文件。其中，用NVT_ASCII码传输的每行都带有一个回车，而后是一个换行。这意味着收方必须扫描每个字节，查找CR/lF对。

   2）EBCDIC文件类型  该文本文件传输方式要求两端都是EBCDIC系统。

   3）图像文件类型（也称为二进制文件类型）  数据发送呈现为一个连续的比特流。通常用于传输二进制文件。

   4）本地文件类型  该方式在具有不同字节大小的主机间传输二进制文件。每一字节的比特数由发方规定。对使用

         8bit字节的系统来说，本地文件以8bit字节传输就等同于图像文件传输。

格式控制

    该选项只对ASCII和EBCDIC文件有效。

    （a）非打印（默认选择）文件中不含有垂直个格式信息

    （b）远程登录格式控制  文件含有向打印机解释的远程登录垂直格式控制

    （c）Fortran 回车控制  每行首字符是Fortran格式控制符

结构

     （a）文件结构（默认选择）文件被认为是一个连续的字节流。不存在内部的文件结构。

     （b）记录结构  该结构只用于文本文件（ASCII 或EBCDIC）。

     （c）页结构  每页都带有页号发送，以便收方能随机地存储各页。

传输方式

    规定文件在数据连接中如何传输

     （a）流方式（默认方式）文件以字节流的形式传输。对于文件结构，发方在文件尾提示关闭数据连接。

               对于记录结构，有专用的两字节序列码标志记录结束和文件结束。

     （b）块方式  文件以一系列块来传输，每块前面都带有一个或多个首部字节。

     （c）压缩方式   一个简单的全场编码压缩方法，压缩连续出现的相同字节。在文本文件中常用来压缩空白

              串，在二进制文件中常用来压缩0字节。  

      如果算一下这些选择的组合数，那么对传输和存储一个文件来说就有72种不同的方式。幸运的是，其中很多选择

不是废弃了，就是不为多数实现环境所支持，所以我们可以忽略掉它们。

      通常由Unix实现的FTP客户和服务器把我们的选择限制如下：

      .类型：ASCII 或图像。

      .格式控制：只允许非打印

      .结构：只允许文件结构、

      .传输方式：只允许流方式

      这就限制我们只能取一、两种方式：ASCII或者图像（二进制）

 FTP命令     

        命令和应答在客户和服务器的控制连接上以NVT_ASCII码形式传送。这就要求在每行结尾都要返回

CR、LF对（也就是每个命令或每个应答）。

下图是一些常有命令：

在用户交互类型和控制连接上传送的F T P命令之间有时是
一对一的。但也有些操作下，一个用户命令产生控制连接上多个F T P命令。

FTP应答

应答都是A S C I I码形式的3位数字，并跟有报文选项。其原因是软件系统需要根据数字代码来
决定如何应答，而选项串是面向人工处理的。由于客户通常都要输出数字应答和报文串，一个可
交互的用户可以通过阅读报文串（而不必记忆所有数字回答代码的含义）来确定应答的含义。
应答3位码中每一位数字都有不同的含义

下图给出了应答代码第1位和第2位的含义。

第3位数字给出差错报文的附加含义。例如，这里是一些典型的应答，都带有一个可能的
报文串。
• 125 数据连接已经打开；传输开始。
• 200 就绪命令。
• 214 帮助报文（面向用户）。
• 331 用户名就绪，要求输入口令。
• 425 不能打开数据连接。
• 452 错写文件。
• 500 语法错误（未认可的命令）。
• 501 语法错误（无效参数）。
• 502 未实现的M O D E (方式命令)类型。

连接管理

数据连接有以下三大用途：

1) 从客户向服务器发送一个文件。
2) 从服务器向客户发送一个文件。
3) 从服务器向客户发送文件或目录列表。

F T P服务器把文件列表从数据连接上发回，而不是控制连接上的多行应答。这就避免了行
的有限性对目录大小的限制，而且更易于客户将目录列表以文件形式保存，而不是把列表显
示在终端上。

我们已说过，控制连接一直保持到客户-服务器连接的全过程，但数据连接可以根据需要
随时来，随时走。那么需要怎样为数据连接选端口号，以及谁来负责主动打开和被动打开？
首先，我们前面说过通用传输方式（ U n i x环境下唯一的传输方式）是流方式，并且文件
结尾是以关闭数据连接为标志。这意味着对每一个文件传输或目录列表来说都要建立一个全
新的数据连接。其一般过程如下：

1) 正由于是客户发出命令要求建立数据连接，所以数据连接是在客户的控制下建立的。
2) 客户通常在客户端主机上为所在数据连接端选择一个临时端口号。客户从该端口发布
一个被动的打开。
3) 客户使用P O RT命令从控制连接上把端口号发向服务器。
4) 服务器在控制连接上接收端口号，并向客户端主机上的端口发布一个主动的打开。服
务器的数据连接端一直使用端口2 0。

     图2给出了第3步执行时的连接状态。假设客户用于控制连接的临时端口是11 7 3，客户
用于数据连接的临时端口是11 7 4。客户发出的命令是P O RT命令，其参数是6个A S C I I中的十进
制数字，它们之间由逗点隔开。前面4个数字指明客户上的I P地址，服务器将向它发出主动打
开（本例中是1 4 0 . 2 5 2 . 1 3 . 3 4），而后两位指明16 bit端口地址。由于16 bit端口地址是从这两个
数字中得来，所以其值在本例中就是4×256+150 = 11 7 4。
      图3给出了服务器向客户所在数据连接端发布主动打开时的连接状态。服务器的端点
是端口2 0。

                 图2、在FTP控制连接上通过的PORT命令

               图3、主动打开数据连接的FTP服务器

        服务器总是执行数据连接的主动打开。通常服务器也执行数据连接的主动关闭，除非当
客户向服务器发送流形式的文件时，需要客户来关闭连接（它给服务器一个文件结束的通
知）。

FTP的例子

        现在看一些使用F T P的例子：它对数据连接的管理，采用NVT ASCII码的文本文件如何发
送，F T P使用Te l n e t同步信号来中止进行中的文件传输，最后是常用的“匿名F T P”。

连接管理：临时数据端口

        先看一下F T P的连接管理，它只在服务器上用简单F T P会话显示一个文件。我们用- d标志
（d e b u g）来运行s v r 4主机上的客户。这告诉它要打印控制连接上变换的命令和应答。所有前
面冠以- - - >的行是从客户上发向服务器的，所有以3位数字开头的行都是服务器的应答。客户
的交互提示是f t p >。

svr4 % ftp -d bsdi                                                         -d 选项用作排错输出
Connected to bsdi.                                                      客户执行控制连接的主动打开
220 bsdi FTP server (Version 5.60) ready                  服务器响应就绪
Name (bsdi:rstevens):                                                 客户提示我们输入
---> USER rstevens                                                     键入R E T U R N，客户发送默认信息
331 Password required for rstevens.
P a s s w o r d :                                                            键入口令；它不需要回显
---> PASS XXXXXXXX                                                  客户以明文发送它
230 User rstevens logged in.
ftp> dir hello.c                                                               要求列出一个文件的目录
---> PORT 140,252,13,34,4,150 
200 PORT Command successful.
---> LIST hello.c
150 Opening ASCII mode data connection for /bin/ls.
-rw-r--r-- 1 rstevens staff 38 Jul 17 12:47 hello.c
226 Transfer complete.
remote: hello.c                                                               客户输出
56 bytes received in 0.03 seconds (1.8 Kbytes/s)
ftp> q u i t                                                                      我们已完成
---> QUIT
221 Goodbye

    当F T P客户提示我们注册姓名时，它打印了默认值（我们在客户上的注册名）。当我们敲
R E T U R N键时，默认值被发送出去。
    对一个文件列出目录的要求引发一个数据连接的建立和使用。客户要求T C P为其数据连接的

终端提供一个临时端口号，并用P O RT命令发送这个端口号（ 11 7 4）给服务器。我们也看到

一个交互用户命令（ d i r）成为两个F T P命令（P O RT和L I S T）。

     图4 是控制连接上分组交换的时间系列（已除去了控制连接的建立和结束，以及所有
窗口大小的通知）。我们关注该图中数据连接在哪儿被打开、使用和过后的关闭。

     图5 是数据连接的时间系列。图中的起始时间与图4 中的相同。已除去了所有窗口大
小通知，但留下服务类型字段，以说明数据连接使用另一个服务类型（最大吞吐量），而不同
于控制连接（最小时延）。
     在时间系列上， F T P服务器执行数据连接的主动打开，从端口2 0（称为f t p - d a t a）到来
自P O RT命令的端口号（ 11 7 4）。本例中还可以看到服务器在哪儿向数据连接上执行写操作，
服务器对数据连接执行主动的关闭，这就告诉客户列表已完成。

                                           图4、FTP控制连接示例

                               图5 FTP数据连接示例

连接管理：默认数据端口

       如果客户没有向服务器发出P O RT命令，来指明客户数据连接端的端口号，服务器就用与
控制连接正在用的相同的端口号给数据连接。这会给使用流方式（ Unix FTP客户和服务器一
直使用）的客户带来一些问题。正如下面所示：
        Host Requirements RFC建议使用流方式的F T P客户在每次使用数据连接前发一个
PORT命令来启用一个非默认的端口号。
        回到先前的例子（图4），如果我们要求在列出第1个目录后几秒钟再列出另一个目录，
那该怎么办？客户将要求其内核选择另一个临时端口号（可能是11 7 5），下一个数据连接将建
立在s v r 4端口11 7 5和b s d i端口2 0之间。但在图5中服务器执行数据连接的主动打开，服务器将

不把端口2 0分配给新的数据连接，这是因为本地端口号已被更早的连接使用，而且还处于2 M S L等待状态。
       服务器通过指明S O R E U S E A D D R选项，来解决这个问题。这让它
把端口2 0分配给新连接，而新连接将从处于2 M S L等待状态的端口（ 11 7 4）处得到一个不一样
的外部端口号（11 7 5），这样一切都解决了。
       如果客户不发送P O RT命令，而在客户上指明一个临时端口号，那么情况将改变。我们可
以通过执行用户命令s e n d p o r t给F T P来使之发生。Unix FTP客户用这个命令在每个数据连接使
用之前关闭向服务器发送P O RT命令。
        图7给出了用于两个连续L I S T命令的数据连接时间系列。控制连接起自主机s v r 4上的端
口11 7 6，所以在没有P O RT命令的情况下，客户和服务器给数据连接使用相同的端口号（除去
了窗口通知和服务类型值）。

事件序列如下：
1) 控制连接是建立在客户端口11 7 6到服务器端口2 1上的（这里我们不展示）

2) 当客户为端口11 7 6上的数据连接做被动打开时，由于该端口已被客户上的控制连接使
     用，所以必须确定S O R E U S E A D D R选项。
3) 服务器给端口2 0到端口11 7 6的数据连接（报文段1）做主动打开。即便端口11 7 6已在客
    户上被使用，客户仍会接受它（报文段2），这是因为下面这一对插口是不同的：
    <svr4, 1176, bsdi, 21>
    <svr4, 1176, bsdi, 20>
  （在b s d i上的端口号是不同的）。T C P通过查看源I P地址、源端口号、目的I P地址、目
    的端口号分用各呼入报文段，只要这4个元素中的一个不同，就行。
4) 服务器对数据连接（报文段5）做主动的关闭，即把这对插口置入服务器上的一个
     2 M S L等待。
     <svr4, 1176, bsdi, 20>
5) 客户在控制连接上发送另一个L I S T命令（这里我们不展示）。在此之前，客户在端口
     11 7 6上为其数据连接端做一个被动打开。客户必须再一次指明S O R E U S E A D D R，这是
     因为端口号11 7 6已在使用。

6) 服务器给从端口2 0到端口11 7 6的数据连接发出一个主动打开。在此之前，服务器必须指
    明S O R E U S E A D D R，这是因为本地端口（2 0）与处于2 M S L等待状态的连接是相关联的，
    该连接将不成功。其原由是这个连接用插口对(socket pair)与步骤
    4中的仍处于2 M S L等待状态的插口对相同。T C P规定禁止服务器发送同步信息（ S Y N）。
    这样就没办法让服务器跨过插口对的2 M S L等待状态来重用相同的插口对。
    在这一步伯克利软件分发（B S D）服务器每隔5秒就重试一次连接请求，直到满1 8次，总共
    9 0秒。我们看到报文段9将在大约1分钟后成功（S V R 4使用一个3 0秒
的M S L，以两个M S L来达到持续1分钟的等待）。我们没看到在这个时间系列上的这些失败
有任何同步（S Y N）信息，这是因为主动打开失败，服务器的T C P不再发送一个S Y N。
Host Requirements RFC建议使用P O RT命令的原因是在两个相继使用数据连接之间避免出
现这个2 M S L。通过不停地改变某一端的端口号，我们所说的这个问题就不会出现。

图7、连续两个LIST命令的数据连接

文本文件传输：NVT ASCII表示还是图像表示

。。。

异常中止一个文件的传输：Telnet 同步信号

。。。。

匿名FTP

。。。。

小结

F T P是文件传输的I n t e r n e t标准。与多数其他T C P应用不同，它在客户进程和服务器进程
之间使用两个T C P连接—一个控制连接，它一直持续到客户进程与服务器进程之间的会话
完成为止；另一个按需可以随时创建和撤消的数据连接。
F T P使用的关于数据连接的连接管理让我们更详细地了解T C P连接管理需求。我们看到
T C P在不发出P O RT命令的客户进程上对2 M S L等待状态的作用。
F T P使用NVT ASCII码做跨越控制连接的所有远程登录命令和应答。数据传输的默认方式
通常也是NVT ASCII码。我们看到较新的U n i x客户进程会自动发送命令来查看服务器是否是8
b i t字节的U n i x主机，并且如果是，那么就使用二进制方式来传输所有文件，那将带来更高的
效率。