第27章FTP：文件傳送協議
27.1 引言
FTP是另一個常見的應用程序。它是用於文件傳輸的I n t e r n e t標准。我們必須分清文件傳
送（file transfer）和文件存取(file access)之間的區別，前者是F T P提供的，后者是如N F S
（S u n的網絡文件系統，第2 9章）等應用系統提供的。由F T P提供的文件傳送是將一個完整的
文件從一個系統復制到另一個系統中。要使用F T P，就需要有登錄服務器的注冊帳號，或者通
過允許匿名F T P的服務器來使用（本章我們將給出這樣的一個例子）。
與Te l n e t類似，F T P最早的設計是用於兩台不同的主機，這兩個主機可能運行在不同的操作系
統下、使用不同的文件結構、並可能使用不同字符集。但不同的是，Te l n e t獲得異構性是強制兩端
都采用同一個標准：使用7比特A S C I I碼的N V T。而F T P是采用另一種方法來處理不同系統間的差
異。F T P支持有限數量的文件類型（A S C I I，二進制，等等）和文件結構（面向字節流或記錄）。
參考文獻959 [Postel 和Reynolds 1985] 是F T P的正式規范。該文獻敘述了近年來文件傳輸
的歷史演變。
27.2 FTP協議
F T P與我們已描述的另一種應用不同，它采用兩個T C P連接來傳輸一個文件。
1) 控制連接以通常的客戶服務器方式建立。服務器以被動方式打開眾所周知的用於
F T P的端口（2 1），等待客戶的連接。客戶則以主動方式打開T C P端口2 1，來建立連
接。控制連接始終等待客戶與服務器之間的通信。該連接將命令從客戶傳給服務器，
並傳回服務器的應答。
由於命令通常是由用戶鍵入的，所以I P對控制連接的服務類型就是“最大限度地減小遲延”。
2) 每當一個文件在客戶與服務器之間傳輸時，就創建一個數據連接。（其他時間也可以創
建，后面我們將說到）。
由於該連接用於傳輸目的，所以I P對數據連接的服務特點就是“最大限度提高吞吐量”。
圖2 7 - 1描述了客戶與服務器以及它們之間的連接情況
從圖中可以看出，交互式用戶通常不處理在控制連接中轉換的命令和應答。這些細節均
由兩個協議解釋器來完成。標有“用戶接口”的方框功能是按用戶所需提供各種交互界面
（全屏幕菜單選擇，逐行輸入命令，等等），並把它們轉換成在控制連接上發送的F T P命令。
類似地，從控制連接上傳回的服務器應答也被轉換成用戶所需的交互格式。
從圖中還可以看出，正是這兩個協議解釋器根據需要激活文件傳送功能。
27.2.1 數據表示
FTP協議規范提供了控制文件傳送與存儲的多種選擇。在以下四個方面中每一個方面都必
須作出一個選擇。
1. 文件類型
(a) ASCII碼文件類型（默認選擇）文本文件以NVT ASCII碼形式在數據連接中傳輸。這要求
發方將本地文本文件轉換成NVT ASCII碼形式，而收方則將NVT ASCII碼再還原成本地文本文件。
其中，用NVT ASCII碼傳輸的每行都帶有一個回車，而后是一個換行。這意味着收方必須掃描每
個字節，查找C R、L F對（我們在第1 5 . 2節見過的關於T F I P的A S C I I碼文件傳輸情況與此相同）。
(b) EBCDIC文件類型該文本文件傳輸方式要求兩端都是E B C D I C系統。
(c) 圖像文件類型（也稱為二進制文件類型） 數據發送呈現為一個連續的比特流。通常
用於傳輸二進制文件。
(d) 本地文件類型 該方式在具有不同字節大小的主機間傳輸二進制文件。每一字節的比特
數由發方規定。對使用8 bit字節的系統來說，本地文件以8 bit字節傳輸就等同於圖像文件傳輸。
2. 格式控制
該選項只對A S C I I和E B C D I C文件類型有效。
(a) 非打印（默認選擇）文件中不含有垂直格式信息。
(b) 遠程登錄格式控制文件含有向打印機解釋的遠程登錄垂直格式控制。
(c) Fortran 回車控制每行首字符是F o r t r a n格式控制符。
3. 結構
（a）文件結構（默認選擇）文件被認為是一個連續的字節流。不存在內部的文件結構。
（b）記錄結構該結構只用於文本文件（A S C I I或E B C D I C）。
（c）頁結構 每頁都帶有頁號發送，以便收方能隨機地存儲各頁。該結構由TO P S - 2 0操
作系統提供（主機需求R F C不提倡采用該結構）。
4. 傳輸方式
它規定文件在數據連接中如何傳輸。
（a）流方式 （默認選擇）文件以字節流的形式傳輸。對於文件結構，發方在文件尾提
示關閉數據連接。對於記錄結構，有專用的兩字節序列碼標志記錄結束和文件結束。
（b）塊方式文件以一系列塊來傳輸，每塊前面都帶有一個或多個首部字節。
（c）壓縮方式 一個簡單的全長編碼壓縮方法，壓縮連續出現的相同字節。在文本文件
客戶
用戶接口
用戶協議
解釋器
用戶數據傳
輸功能
文件系統
數據連接
控制連接
服務器
服務器協
議接口
服務器數據傳
輸功能
文件系統
( F T P命令)
( F T P應答)
在終端上
的用戶
下載
318使用TCP/IP詳解，卷1：協議
中常用來壓縮空白串，在二進制文件中常用來壓縮0字節（這種方式很少使用，也不受支持。
現在有一些更好的文件壓縮方法來支持F T P）。
如果算一下所有這些選擇的排列組合數，那么對傳輸和存儲一個文件來說就有7 2種不同
的方式。幸運的是，其中很多選擇不是廢棄了，就是不為多數實現環境所支持，所以我們可
以忽略掉它們。
通常由U n i x實現的FTP 客戶和服務器把我們的選擇限制如下：
• 類型：A S C I I或圖像。
• 格式控制：只允許非打印。
• 結構：只允許文件結構。
• 傳輸方式：只允許流方式。
這就限制我們只能取一、兩種方式：A S C I I或圖像（二進制）。
該實現滿足主機需求R F C的最小需求（該R F C也要求能支持記錄結構，但只有操作系統
支持它才行，而U n i x不行）。
很多非U n i x的實現提供了處理它們自己文件格式的F T P功能。主機需求R F C指出“F T P協
議有很多特征，雖然其中一些通常不實現，但對F T P中的每一個特征來說，都存在着至少一種
實現”。
27.2.4 連接管理
數據連接有以下三大用途：
1) 從客戶向服務器發送一個文件。
2) 從服務器向客戶發送一個文件。
3) 從服務器向客戶發送文件或目錄列表。
F T P服務器把文件列表從數據連接上發回，而不是控制連接上的多行應答。這就避免了行
的有限性對目錄大小的限制，而且更易於客戶將目錄列表以文件形式保存，而不是把列表顯
示在終端上。
我們已說過，控制連接一直保持到客戶-服務器連接的全過程，但數據連接可以根據需要
隨時來，隨時走。那么需要怎樣為數據連接選端口號，以及誰來負責主動打開和被動打開？
首先，我們前面說過通用傳輸方式（U n i x環境下唯一的傳輸方式）是流方式，並且文件
結尾是以關閉數據連接為標志。這意味着對每一個文件傳輸或目錄列表來說都要建立一個全
新的數據連接。其一般過程如下：
1) 正由於是客戶發出命令要求建立數據連接，所以數據連接是在客戶的控制下建立的。
2) 客戶通常在客戶端主機上為所在數據連接端選擇一個臨時端口號。客戶從該端口發布
一個被動的打開。
3) 客戶使用P O RT命令從控制連接上把端口號發向服務器。
4) 服務器在控制連接上接收端口號，並向客戶端主機上的端口發布一個主動的打開。服
務器的數據連接端一直使用端口2 0。
圖2 7 - 4給出了第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。
圖2 7 - 5給出了服務器向客戶所在數據連接端發布主動打開時的連接狀態。服務器的端點
是端口2 0。
服務器總是執行數據連接的主動打開。通常服務器也執行數據連接的主動關閉，除非當
客戶向服務器發送流形式的文件時，需要客戶來關閉連接（它給服務器一個文件結束的通
知）。
客戶也有可能不發出P O RT命令，而由服務器向正被客戶使用的同一個端口號發出主動打
開，來結束控制連接。這是可行的，因為服務器面向這兩個連接的端口號是不同的：一個是
2 0，另一個是2 1。不過，下節我們將看到為什么現有實現通常不這樣做。