协议及数据包浅析.docx

FTP协议及数据包浅析
第27章FTP：文献传送协议
27.1引言
FTP是另一个常见的应用程序。它是用于文献传输的Internet标准。我们必须分清文献传
送（filetransfer）和文献存取(fileaccess)之间的区别，前者是FTP提供的，后者是如NFS
（Sun的网络文献系统，第29章）等应用系统提供的。由FTP提供的文献传送是将一个完整的
文献从一个系统复制到另一个系统中。要使用FTP，就需要有登录服务器的注册帐号，或者通
过允许匿名FTP的服务器来使用（本章我们将给出这样的一个例子）。
与Telnet类似，FTP最早的设计是用于两台不同的主机，这两个主机也许运营在不同的操作系
统下、使用不同的文献结构、并也许使用不同字符集。但不同的是，Telnet获得异构性是强制两端
都采用同一个标准：使用7比特ASCII码的NVT。而FTP是采用另一种方法来解决不同系统间的差
异。FTP支持有限数量的文献类型（ASCII，二进制，等等）和文献结构（面向字节流或记录）。
参考文献959[Postel和Reynolds1985]是FTP的正式规范。该文献叙述了近年来文献传输
的历史演变。
27.2FTP协议
FTP与我们已描述的另一种应用不同，它采用两个TCP连接来传输一个文献。
1)控制连接以通常的客户服务器方式建立。服务器以被动方式打开众所周知的用于
FTP的端口（21），等待客户的连接。客户则以积极方式打开TCP端口21，来建立连
接。控制连接始终等待客户与服务器之间的通信。该连接将命令从客户传给服务器，
并传回服务器的应答。
由于命令通常是由用户键入的，所以IP对控制连接的服务类型就是“最大限度地减小迟延”。
2)每当一个文献在客户与服务器之间传输时，就创建一个数据连接。（其他时间也可以创
建，后面我们将说到）。
由于该连接用于传输目的，所以IP对数据连接的服务特点就是“最大限度提高吞吐量”。
图27-1描述了客户与服务器以及它们之间的连接情况
从图中可以看出，交互式用户通常不解决在控制连接中转换的命令和应答。这些细节均
由两个协议解释器来完毕。标有“用户接口”的方框功能是按用户所需提供各种交互界面
（全屏幕菜单选择，逐行输入命令，等等），并把它们转换成在控制连接上发送的FTP命令。
类似地，从控制连接上传回的服务器应答也被转换成用户所需的交互格式。
从图中还可以看出，正是这两个协议解释器根据需要激活文献传送功能。
27.2.1数据表达
FTP协议规范提供了控制文献传送与存储的多种选择。在以下四个方面中每一个方面都必
须作出一个选择。

1.文献类型
(a)ASCII码文献类型（默认选择）文本文献以NVTASCII码形式在数据连接中传输。这规定
发方将本地文本文献转换成NVTASCII码形式，而收方则将NVTASCII码再还原成本地文本文献。
其中，用NVTASCII码传输的每行都带有一个回车，而后是一个换行。这意味着收方必须扫描每
个字节，查找CR、LF对（我们在第15.2节见过的关于TFIP的ASCII码文献传输情况与此相同）。
(b)EBCDIC文献类型该文本文献传输方式规定两端都是EBCDIC系统。
(c)图像文献类型（也称为二进制文献类型）数据发送呈现为一个连续的比特流。通常
用于传输二进制文献。
(d)本地文献类型该方式在具有不同字节大小的主机间传输二进制文献。每一字节的比特
数由发方规定。对使用8bit字节的系统来说，本地文献以8bit字节传输就等同于图像文献传输。
2.格式控制
该选项只对ASCII和EBCDIC文献类型有效。
(a)非打印（默认选择）文献中不具有垂直格式信息。
(b)远程登录格式控制文献具有向打印机解释的远程登录垂直格式控制。
(c)Fortran回车控制每行首字符是Fortran格式控制符。
3.结构
（a）文献结构（默认选择）文献被认为是一个连续的字节流。不存在内部的文献结构。
（b）记录结构该结构只用于文本文献（ASCII或EBCDIC）。
（c）页结构每页都带有页号发送，以便收方能随机地存储各页。该结构由TOPS-20操
作系统提供（主机需求RFC不提倡采用该结构）。
4.传输方式
它规定文献在数据连接中如何传输。
（a）流方式（默认选择）文献以字节流的形式传输。对于文献结构，发方在文献尾提
示关闭数据连接。对于记录结构，有专用的两字节序列码标志记录结束和文献结束。
（b）块方式文献以一系列块来传输，每块前面都带有一个或多个首部字节。
（c）压缩方式一个简朴的全长编码压缩方法，压缩连续出现的相同字节。在文本文献
客户
用户接口
用户协议
解释器
用户数据传
输功能
文献系统
数据连接
控制连接
服务器
服务器协
议接口
服务器数据传
输功能
文献系统
(FTP命令)
(FTP应答)
在终端上
的用户
下载
318使用TCP/IP详解，卷1：协议
中常用来压缩空白串，在二进制文献中常用来压缩0字节（这种方式很少使用，也不受支持。
现在有一些更好的文献压缩方法来支持FTP）。
假如算一下所有这些选择的排列组合数，那么对传输和存储一个文献来说就有72种不同
的方式。幸运的是，其中很多选择不是废弃了，就是不为多数实现环境所支持，所以我们可
以忽略掉它们。
通常由Unix实现的FTP客户和服务器把我们的选择限制如下：
•类型：ASCII或图像。
•格式控制：只允许非打印。
•结构：只允许文献结构。
•传输方式：只允许流方式。
这就限制我们只能取一、两种方式：ASCII或图像（二进制）。
该实现满足主机需求RFC的最小需求（该RFC也规定能支持记录结构，但只有操作系统
支持它才行，而Unix不行）。
很多非Unix的实现提供了解决它们自己文献格式的FTP功能。主机需求RFC指出“FTP协
议有很多特性，虽然其中一些通常不实现，但对FTP中的每一个特性来说，都存在着至少一种
实现”。
27.2.4连接管理
数据连接有以下三大用途：
1)从客户向服务器发送一个文献。
2)从服务器向客户发送一个文献。
3)从服务器向客户发送文献或目录列表。
FTP服务器把文献列表从数据连接上发回，而不是控制连接上的多行应答。这就避免了行
的有限性对目录大小的限制，并且更易于客户将目录列表以文献形式保存，而不是把列表显
示在终端上。
我们已说过，控制连接一直保持到客户-服务器连接的全过程，但数据连接可以根据需要
随时来，随时走。那么需要如何为数据连接选端标语，以及谁来负责积极打开和被动打开？
一方面，我们前面说过通用传输方式（Unix环境下唯一的传输方式）是流方式，并且文献
结尾是以关闭数据连接为标志。这意味着对每一个文献传输或目录列表来说都要建立一个全
新的数据连接。其一般过程如下：
1)正由于是客户发出命令规定建立数据连接，所以数据连接是在客户的控制下建立的。
2)客户通常在客户端主机上为所在数据连接端选择一个临时端标语。客户从该端口发布
一个被动的打开。
3)客户使用PORT命令从控制连接上把端标语发向服务器。
4)服务器在控制连接上接受端标语，并向客户端主机上的端口发布一个积极的打开。服
务器的数据连接端一直使用端口20。
图27-4给出了第3步执行时的连接状态。假设客户用于控制连接的临时端口是1173，客户
用于数据连接的临时端口是1174。客户发出的命令是PORT命令，其参数是6个ASCII中的十进
制数字，它们之间由逗点隔开。前面4个数字指明客户上的IP地址，服务器将向它发出积极打
开（本例中是140.252.13.34），而后两位指明16bit端口地址。由于16bit端口地址是从这两个
数字中得来，所以其值在本例中就是4×256+150=1174。
图27-5给出了服务器向客户所在数据连接端发布积极打开时的连接状态。服务器的端点
是端口20。

服务器总是执行数据连接的积极打开。通常服务器也执行数据连接的积极关闭，除非当
客户向服务器发送流形式的文献时，需要客户来关闭连接（它给服务器一个文献结束的通
知）。
客户也有也许不发出PORT命令，而由服务器向正被客户使用的同一个端标语发出积极打
开，来结束控制连接。这是可行的，由于服务器面向这两个连接的端标语是不同的：一个是
20，另一个是21。但是，下节我们将看到为什么现有实现通常不这样做。