協(xié)議及數(shù)據(jù)包淺析

FTP協(xié)議及數(shù)據(jù)包淺析第27章FTP：文獻(xiàn)傳送協(xié)議

27.1引言

FTP是另一個(gè)常見的應(yīng)用程序。它是用于文獻(xiàn)傳輸?shù)腎nternet標(biāo)準(zhǔn)。我們必須分清文獻(xiàn)傳

送（filetransfer）和文獻(xiàn)存取(fileaccess)之間的區(qū)別，前者是FTP提供的，后者是如NFS

（Sun的網(wǎng)絡(luò)文獻(xiàn)系統(tǒng)，第29章）等應(yīng)用系統(tǒng)提供的。由FTP提供的文獻(xiàn)傳送是將一個(gè)完整的

文獻(xiàn)從一個(gè)系統(tǒng)復(fù)制到另一個(gè)系統(tǒng)中。要使用FTP，就需要有登錄服務(wù)器的注冊帳號(hào)，或者通

過允許匿名FTP的服務(wù)器來使用（本章我們將給出這樣的一個(gè)例子）。

與Telnet類似，F(xiàn)TP最早的設(shè)計(jì)是用于兩臺(tái)不同的主機(jī)，這兩個(gè)主機(jī)也許運(yùn)營在不同的操作系

統(tǒng)下、使用不同的文獻(xiàn)結(jié)構(gòu)、并也許使用不同字符集。但不同的是，Telnet獲得異構(gòu)性是強(qiáng)制兩端

都采用同一個(gè)標(biāo)準(zhǔn)：使用7比特ASCII碼的NVT。而FTP是采用另一種方法來解決不同系統(tǒng)間的差

異。FTP支持有限數(shù)量的文獻(xiàn)類型（ASCII，二進(jìn)制，等等）和文獻(xiàn)結(jié)構(gòu)（面向字節(jié)流或記錄）。

參考文獻(xiàn)959[Postel和Reynolds1985]是FTP的正式規(guī)范。該文獻(xiàn)敘述了近年來文獻(xiàn)傳輸

的歷史演變。

27.2FTP協(xié)議

FTP與我們已描述的另一種應(yīng)用不同，它采用兩個(gè)TCP連接來傳輸一個(gè)文獻(xiàn)。

1)控制連接以通常的客戶服務(wù)器方式建立。服務(wù)器以被動(dòng)方式打開眾所周知的用于

FTP的端口（21），等待客戶的連接?？蛻魟t以積極方式打開TCP端口21，來建立連

接。控制連接始終等待客戶與服務(wù)器之間的通信。該連接將命令從客戶傳給服務(wù)器，

并傳回服務(wù)器的應(yīng)答。

由于命令通常是由用戶鍵入的，所以IP對控制連接的服務(wù)類型就是“最大限度地減小遲延”。

2)每當(dāng)一個(gè)文獻(xiàn)在客戶與服務(wù)器之間傳輸時(shí)，就創(chuàng)建一個(gè)數(shù)據(jù)連接。（其他時(shí)間也可以創(chuàng)

建，后面我們將說到）。

由于該連接用于傳輸目的，所以IP對數(shù)據(jù)連接的服務(wù)特點(diǎn)就是“最大限度提高吞吐量”。

圖27-1描述了客戶與服務(wù)器以及它們之間的連接情況

從圖中可以看出，交互式用戶通常不解決在控制連接中轉(zhuǎn)換的命令和應(yīng)答。這些細(xì)節(jié)均

由兩個(gè)協(xié)議解釋器來完畢。標(biāo)有“用戶接口”的方框功能是按用戶所需提供各種交互界面

（全屏幕菜單選擇，逐行輸入命令，等等），并把它們轉(zhuǎn)換成在控制連接上發(fā)送的FTP命令。

類似地，從控制連接上傳回的服務(wù)器應(yīng)答也被轉(zhuǎn)換成用戶所需的交互格式。

從圖中還可以看出，正是這兩個(gè)協(xié)議解釋器根據(jù)需要激活文獻(xiàn)傳送功能。

27.2.1數(shù)據(jù)表達(dá)

FTP協(xié)議規(guī)范提供了控制文獻(xiàn)傳送與存儲(chǔ)的多種選擇。在以下四個(gè)方面中每一個(gè)方面都必

須作出一個(gè)選擇。1.文獻(xiàn)類型

(a)ASCII碼文獻(xiàn)類型（默認(rèn)選擇）文本文獻(xiàn)以NVTASCII碼形式在數(shù)據(jù)連接中傳輸。這規(guī)定

發(fā)方將本地文本文獻(xiàn)轉(zhuǎn)換成NVTASCII碼形式，而收方則將NVTASCII碼再還原成本地文本文獻(xiàn)。

其中，用NVTASCII碼傳輸?shù)拿啃卸紟в幸粋€(gè)回車，而后是一個(gè)換行。這意味著收方必須掃描每

個(gè)字節(jié)，查找CR、LF對（我們在第15.2節(jié)見過的關(guān)于TFIP的ASCII碼文獻(xiàn)傳輸情況與此相同）。

(b)EBCDIC文獻(xiàn)類型該文本文獻(xiàn)傳輸方式規(guī)定兩端都是EBCDIC系統(tǒng)。

(c)圖像文獻(xiàn)類型（也稱為二進(jìn)制文獻(xiàn)類型）數(shù)據(jù)發(fā)送呈現(xiàn)為一個(gè)連續(xù)的比特流。通常

用于傳輸二進(jìn)制文獻(xiàn)。

(d)本地文獻(xiàn)類型該方式在具有不同字節(jié)大小的主機(jī)間傳輸二進(jìn)制文獻(xiàn)。每一字節(jié)的比特

數(shù)由發(fā)方規(guī)定。對使用8bit字節(jié)的系統(tǒng)來說，本地文獻(xiàn)以8bit字節(jié)傳輸就等同于圖像文獻(xiàn)傳輸。

2.格式控制

該選項(xiàng)只對ASCII和EBCDIC文獻(xiàn)類型有效。

(a)非打印（默認(rèn)選擇）文獻(xiàn)中不具有垂直格式信息。

(b)遠(yuǎn)程登錄格式控制文獻(xiàn)具有向打印機(jī)解釋的遠(yuǎn)程登錄垂直格式控制。

(c)Fortran回車控制每行首字符是Fortran格式控制符。

3.結(jié)構(gòu)

（a）文獻(xiàn)結(jié)構(gòu)（默認(rèn)選擇）文獻(xiàn)被認(rèn)為是一個(gè)連續(xù)的字節(jié)流。不存在內(nèi)部的文獻(xiàn)結(jié)構(gòu)。

（b）記錄結(jié)構(gòu)該結(jié)構(gòu)只用于文本文獻(xiàn)（ASCII或EBCDIC）。

（c）頁結(jié)構(gòu)每頁都帶有頁號(hào)發(fā)送，以便收方能隨機(jī)地存儲(chǔ)各頁。該結(jié)構(gòu)由TOPS-20操

作系統(tǒng)提供（主機(jī)需求RFC不提倡采用該結(jié)構(gòu)）。

4.傳輸方式

它規(guī)定文獻(xiàn)在數(shù)據(jù)連接中如何傳輸。

（a）流方式（默認(rèn)選擇）文獻(xiàn)以字節(jié)流的形式傳輸。對于文獻(xiàn)結(jié)構(gòu)，發(fā)方在文獻(xiàn)尾提

示關(guān)閉數(shù)據(jù)連接。對于記錄結(jié)構(gòu)，有專用的兩字節(jié)序列碼標(biāo)志記錄結(jié)束和文獻(xiàn)結(jié)束。

（b）塊方式文獻(xiàn)以一系列塊來傳輸，每塊前面都帶有一個(gè)或多個(gè)首部字節(jié)。

（c）壓縮方式一個(gè)簡樸的全長編碼壓縮方法，壓縮連續(xù)出現(xiàn)的相同字節(jié)。在文本文獻(xiàn)

客戶

用戶接口

用戶協(xié)議

解釋器

用戶數(shù)據(jù)傳

輸功能

文獻(xiàn)系統(tǒng)

數(shù)據(jù)連接

控制連接

服務(wù)器

服務(wù)器協(xié)

議接口

服務(wù)器數(shù)據(jù)傳

輸功能

文獻(xiàn)系統(tǒng)

(FTP命令)

(FTP應(yīng)答)

在終端上

的用戶

下載

318使用TCP/IP詳解，卷1：協(xié)議

中常用來壓縮空白串，在二進(jìn)制文獻(xiàn)中常用來壓縮0字節(jié)（這種方式很少使用，也不受支持。

現(xiàn)在有一些更好的文獻(xiàn)壓縮方法來支持FTP）。

假如算一下所有這些選擇的排列組合數(shù)，那么對傳輸和存儲(chǔ)一個(gè)文獻(xiàn)來說就有72種不同

的方式。幸運(yùn)的是，其中很多選擇不是廢棄了，就是不為多數(shù)實(shí)現(xiàn)環(huán)境所支持，所以我們可

以忽略掉它們。

通常由Unix實(shí)現(xiàn)的FTP客戶和服務(wù)器把我們的選擇限制如下：

?類型：ASCII或圖像。

?格式控制：只允許非打印。

?結(jié)構(gòu)：只允許文獻(xiàn)結(jié)構(gòu)。

?傳輸方式：只允許流方式。

這就限制我們只能取一、兩種方式：ASCII或圖像（二進(jìn)制）。

該實(shí)現(xiàn)滿足主機(jī)需求RFC的最小需求（該RFC也規(guī)定能支持記錄結(jié)構(gòu)，但只有操作系統(tǒng)

支持它才行，而Unix不行）。

很多非Unix的實(shí)現(xiàn)提供了解決它們自己文獻(xiàn)格式的FTP功能。主機(jī)需求RFC指出“FTP協(xié)

議有很多特性，雖然其中一些通常不實(shí)現(xiàn)，但對FTP中的每一個(gè)特性來說，都存在著至少一種

實(shí)現(xiàn)”。27.2.4連接管理

數(shù)據(jù)連接有以下三大用途：

1)從客戶向服務(wù)器發(fā)送一個(gè)文獻(xiàn)。

2)從服務(wù)器向客戶發(fā)送一個(gè)文獻(xiàn)。

3)從服務(wù)器向客戶發(fā)送文獻(xiàn)或目錄列表。

FTP服務(wù)器把文獻(xiàn)列表從數(shù)據(jù)連接上發(fā)回，而不是控制連接上的多行應(yīng)答。這就避免了行

的有限性對目錄大小的限制，并且更易于客戶將目錄列表以文獻(xiàn)形式保存，而不是把列表顯

示在終端上。

我們已說過，控制連接一直保持到客戶-服務(wù)器連接的全過程，但數(shù)據(jù)連接可以根據(jù)需要

隨時(shí)來，隨時(shí)走。那么需要如何為數(shù)據(jù)連接選端標(biāo)語，以及誰來負(fù)責(zé)積極打開和被動(dòng)打開？

一方面，我們前面說過通用傳輸方式（Unix環(huán)境下唯一的傳輸方式）是流方式，并且文獻(xiàn)

結(jié)尾是以關(guān)閉數(shù)據(jù)連接為標(biāo)志。這意味著對每一個(gè)文獻(xiàn)傳輸或目錄列表來說都要建立一個(gè)全

新的數(shù)據(jù)連接。其一般過程如下：

1)正由于是客戶發(fā)出命令規(guī)定建立數(shù)據(jù)連接，所以數(shù)據(jù)連接是在客戶的控制下建立的。

2)客戶通常在客戶端主機(jī)上為所在數(shù)據(jù)連接端選擇一個(gè)臨時(shí)端標(biāo)語。客戶從該端口發(fā)布

一個(gè)被動(dòng)的打開。

3)客戶使用PORT命令從控制連接上把端標(biāo)語發(fā)向服務(wù)器。

4)服務(wù)器在控制連接上接受端標(biāo)語，并向客戶端主機(jī)上的端口發(fā)布一個(gè)積極的打開。服

務(wù)器的數(shù)據(jù)連接端一直使用端口20。

圖27-4給出了第3步執(zhí)行時(shí)的連接狀態(tài)。假設(shè)客戶用于控制連接的臨時(shí)端口是1173，客戶

用于數(shù)據(jù)連接的臨時(shí)端口是1174?？蛻舭l(fā)出的命令是PORT命令，其參數(shù)是6個(gè)ASCII中的十進(jìn)

制數(shù)字，它們之間由逗點(diǎn)隔開。前面4個(gè)數(shù)字指明客戶上的IP地址，服務(wù)器將向它發(fā)出積極打

開（本例中是4），而后兩位指明16bit端口地址。由于16bit端口地址是從這兩個(gè)

數(shù)字中得來，所以其值在本例中就是4×256+150=1174。

圖27-5給出了服務(wù)器向客戶所在數(shù)據(jù)連接端發(fā)布積極打開時(shí)的連接狀態(tài)。服務(wù)器的端點(diǎn)

是端口20。服務(wù)器總是執(zhí)行數(shù)據(jù)連接的積極打開。通常服務(wù)器也執(zhí)行數(shù)據(jù)連