27.1 引言

FTP是另一個常見的應用程序。它是用于文件傳輸的Internet標準。我們必須分清文件傳送（file transfer）和文件存取(file access)之間的區別，前者是FTP提供的，后者是如NFS（Sun的網絡文件系統，第29章）等應用系統提供的。由FTP提供的文件傳送是將一個完整的文件從一個系統復制到另一個系統中。要使用FTP，就需要有登錄服務器的注冊帳號，或者通過允許匿名FTP的服務器來使用（本章我們將給出這樣的一個例子）。

與Telnet類似，FTP最早的設計是用于兩臺不同的主機，這兩個主機可能運行在不同的操作系統下、使用不同的文件結構、并可能使用不同字符集。但不同的是，Telnet獲得異構性是強制兩端都采用同一個標準：使用7比特ASCII碼的NVT。而FTP是采用另一種方法來處理不同系統間的差異。FTP支持有限數量的文件類型（ASCII，二進制，等等）和文件結構（面向字節流或記錄）。

參考文獻959 [Postel和Reynolds 1985] 是FTP的正式規范。該文獻敘述了近年來文件傳輸的歷史演變。

27.2 FTP協議

FTP與我們已描述的另一種應用不同，它采用兩個TCP連接來傳輸一個文件。

1：控制連接以通常的客戶服務器方式建立。服務器以被動方式打開眾所周知的用于FTP的端口（21），等待客戶的連接。客戶則以主動方式打開TCP端口21，來建立連接。控制連接始終等待客戶與服務器之間的通信。該連接將命令從客戶傳給服務器，并傳回服務器的應答。
由于命令通常是由用戶鍵入的，所以IP對控制連接的服務類型就是“最大限度地減小遲延”。

2：每當一個文件在客戶與服務器之間傳輸時，就創建一個數據連接。（其他時間也可以創建，后面我們將說到）。

由于該連接用于傳輸目的，所以IP對數據連接的服務特點就是“最大限度提高吞吐量”。

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

圖27-1 文件傳輸中的處理過程

從圖中可以看出，交互式用戶通常不處理在控制連接中轉換的命令和應答。這些細節均由兩個協議解釋器來完成。標有“用戶接口”的方框功能是按用戶所需提供各種交互界面（全屏幕菜單選擇，逐行輸入命令，等等），并把它們轉換成在控制連接上發送的FTP命令。類似地，從控制連接上傳回的服務器應答也被轉換成用戶所需的交互格式。

從圖中還可以看出，正是這兩個協議解釋器根據需要激活文件傳送功能。

27.2.1 數據表示

FTP協議規范提供了控制文件傳送與存儲的多種選擇。在以下四個方面中每一個方面都必須作出一個選擇。

1. 文件類型

a：ASCII碼文件類型（默認選擇）文本文件以NVT ASCII碼形式在數據連接中傳輸。這要求發方將本地文本文件轉換成NVT ASCII碼形式，而收方則將NVT ASCII碼再還原成本地文本文件。其中，用NVT ASCII碼傳輸的每行都帶有一個回車，而后是一個換行。這意味著收方必須掃描每個字節，查找CR、LF對（我們在第15.2節見過的關于TFIP的ASCII碼文件傳輸情況與此相同）。

b：EBCDIC文件類型該文本文件傳輸方式要求兩端都是EBCDIC系統。
圖像文件類型（也稱為二進制文件類型）數據發送呈現為一個連續的比特流。通常用于傳輸二進制文件。

c：本地文件類型該方式在具有不同字節大小的主機間傳輸二進制文件。每一字節的比特數由發方規定。對使用8bit字節的系統來說，本地文件以8bit字節傳輸就等同于圖像文件傳輸。

2. 格式控制

該選項只對ASCII和EBCDIC文件類型有效。

a：非打印（默認選擇）文件中不含有垂直格式信息。

b：遠程登錄格式控制文件含有向打印機解釋的遠程登錄垂直格式控制。

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

3. 結構

a：文件結構（默認選擇）文件被認為是一個連續的字節流。不存在內部的文件結構。

b：記錄結構該結構只用于文本文件（ASCII或EBCDIC）。

c：頁結構每頁都帶有頁號發送，以便收方能隨機地存儲各頁。該結構由TO PS-20操作系統提供（主機需求RFC不提倡采用該結構）。

4. 傳輸方式

它規定文件在數據連接中如何傳輸。

a：流方式（默認選擇）文件以字節流的形式傳輸。對于文件結構，發方在文件尾提示關閉數據連接。對于記錄結構，有專用的兩字節序列碼標志記錄結束和文件結束。

b：塊方式文件以一系列塊來傳輸，每塊前面都帶有一個或多個首部字節。

c：壓縮方式一個簡單的全長編碼壓縮方法，壓縮連續出現的相同字節。在文本文件中常用來壓縮空白串，在二進制文件中常用來壓縮0字節（這種方式很少使用，也不受支持。現在有一些更好的文件壓縮方法來支持FTP）。

如果算一下所有這些選擇的排列組合數，那么對傳輸和存儲一個文件來說就有72種不同的方式。幸運的是，其中很多選擇不是廢棄了，就是不為多數實現環境所支持，所以我們可以忽略掉它們。

通常由Unix實現的FTP客戶和服務器把我們的選擇限制如下：

? 類型：ASCII或圖像。

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

? 結構：只允許文件結構。

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

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

該實現滿足主機需求RFC的最小需求（該RFC也要求能支持記錄結構，但只有操作系統支持它才行，而Unix不行）。

很多非Unix的實現提供了處理它們自己文件格式的FTP功能。主機需求RFC指出“FTP協議有很多特征，雖然其中一些通常不實現，但對FTP中的每一個特征來說，都存在著至少一種實現”。

27.2.2 FTP命令

命令和應答在客戶和服務器的控制連接上以NVT ASCII碼形式傳送。這就要求在每行結尾都要返回CR、LF對（也就是每個命令或每個應答）。

從客戶發向服務器的Telnet命令（以IAC打頭）只有中斷進程（<IAC,IP>）和Telnet的同步信號（緊急方式下<IAC,DM>）。我們將看到這兩條Telnet命令被用來中止正在進行的文件傳輸，或在傳輸過程中查詢服務器。另外，如果服務器接受了客戶端的一個帶選項的Telnet命令（WILL，WONT，DO或DONT），它將以DONT或WONT響應。

這些命令都是3或4個字節的大寫ASCII字符，其中一些帶選項參數。從客戶向服務器發送的FTP命令超過30種。圖27-2給出了一些常用命令，其中大部分將在本章再次遇到。

圖27-2 常用的FTP命令

下節我們將通過一些例子看到，在用戶交互類型和控制連接上傳送的FTP命令之間有時是一對一的。但也有些操作下，一個用戶命令產生控制連接上多個FTP命令。

27.2.3 FTP應答

應答都是ASCII碼形式的3位數字，并跟有報文選項。其原因是軟件系統需要根據數字代碼來決定如何應答，而選項串是面向人工處理的。由于客戶通常都要輸出數字應答和報文串，一個可交互的用戶可以通過閱讀報文串（而不必記憶所有數字回答代碼的含義）來確定應答的含義。

應答3位碼中每一位數字都有不同的含義（我們將在第28章看到簡單郵件傳送輸協議，SMTP，使用相同的命令和應答約定）。

圖27-3給出了應答代碼第1位和第2位的含義。

圖27-3 應答代碼3位數字中第1位和第2位的含義

第3位數字給出差錯報文的附加含義。例如，這里是一些典型的應答，都帶有一個可能的報文串。

? 125 數據連接已經打開;傳輸開始。

? 200 就緒命令。

? 214 幫助報文(面向用戶)。

? 331 用戶名就緒,要求輸入口令。

? 425 不能打開數據連接。

? 452 錯寫文件。

? 500 語法錯誤(未認可的命令)。

? 501 語法錯誤(無效參數)。

? 502 未實現的 MODE ( 方式命令 ) 類型。

通常每個FTP命令都產生一行回答。例如，QUIT命令可以產生如下應答：

221 Goodbye.

如果需要產生一條多行應答，第1行在3位數字應答代碼之后包含一個連字號，而不是空格，最后一行包含相同的3位數字應答代碼，后跟一個空格符。例如，HELP命令可以產生如下應答：

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），而后兩位指明16 bit端口地址。由于16 bit端口地址是從這兩個數字中得來，所以其值在本例中就是4×256+150=1174。

圖27-5給出了服務器向客戶所在數據連接端發布主動打開時的連接狀態。服務器的端點是端口20。

圖27-4 在FTP控制連接上通過的PORT命令

圖27-5 主動打開數據連接的FTP服務器

服務器總是執行數據連接的主動打開。通常服務器也執行數據連接的主動關閉，除非當客戶向服務器發送流形式的文件時，需要客戶來關閉連接（它給服務器一個文件結束的通知）。

客戶也有可能不發出PORT命令，而由服務器向正被客戶使用的同一個端口號發出主動打開，來結束控制連接。這是可行的，因為服務器面向這兩個連接的端口號是不同的：一個是20，另一個是21。不過，下節我們將看到為什么現有實現通常不這樣做。

27.3 FTP的例子

現在看一些使用FTP的例子：它對數據連接的管理，采用NVT ASCII碼的文本文件如何發送，FTP使用Telnet同步信號來中止進行中的文件傳輸，最后是常用的“匿名FTP”。

27.3.1 連接管理：臨時數據端口

先看一下FTP的連接管理，它只在服務器上用簡單FTP會話顯示一個文件。我們用-d標志（debug）來運行svr4主機上的客戶。這告訴它要打印控制連接上變換的命令和應答。所有前面冠以--->的行是從客戶上發向服務器的，所有以3位數字開頭的行都是服務器的應答。客戶的交互提示是ftp>。

當FTP客戶提示我們注冊姓名時，它打印了默認值（我們在客戶上的注冊名）。當我們敲RETURN鍵時，默認值被發送出去。

對一個文件列出目錄的要求引發一個數據連接的建立和使用。本例體現了我們在圖27-4和圖27-5中給出的程序。客戶要求TCP為其數據連接的終端提供一個臨時端口號，并用PORT命令發送這個端口號（1174）給服務器。我們也看到一個交互用戶命令（dir）成為兩個FTP命令（PORT和LIST）。

圖27-6是控制連接上分組交換的時間系列（已除去了控制連接的建立和結束，以及所有窗口大小的通知）。我們關注該圖中數據連接在哪兒被打開、使用和過后的關閉。

圖27-7是數據連接的時間系列。圖中的起始時間與圖27-6中的相同。已除去了所有窗口大小通知，但留下服務類型字段，以說明數據連接使用另一個服務類型（最大吞吐量），而不同于控制連接（最小時延）（服務類型(TOS)值在圖3-2中）。

在時間系列上，FTP服務器執行數據連接的主動打開，從端口20（稱為ftp-data）到來自PORT命令的端口號（1174）。本例中還可以看到服務器在哪兒向數據連接上執行寫操作，服務器對數據連接執行主動的關閉，這就告訴客戶列表已完成。

圖27-6 FTP控制連接示例

圖27-7 FTP數據連接示例

27.3.2 連接管理：默認數據端口

如果客戶沒有向服務器發出PORT命令，來指明客戶數據連接端的端口號，服務器就用與控制連接正在用的相同的端口號給數據連接。這會給使用流方式（Unix FTP客戶和服務器一直使用）的客戶帶來一些問題。正如下面所示：

Host Requirements RFC建議使用流方式的FTP客戶在每次使用數據連接前發一個PORT命令來啟用一個非默認的端口號。

回到先前的例子（圖27-6），如果我們要求在列出第1個目錄后幾秒鐘再列出另一個目錄，那該怎么辦？客戶將要求其內核選擇另一個臨時端口號（可能是1175），下一個數據連接將建立在svr4端口1175和bsdi端口20之間。但在圖27-7中服務器執行數據連接的主動打開，我們在18.6節說明了服務器將不把端口20分配給新的數據連接，這是因為本地端口號已被更早的連接使用，而且還處于2MSL等待狀態。

服務器通過指明我們在18.6節中提到的SO_REUSEADDR選項，來解決這個問題。這讓它把端口20分配給新連接，而新連接將從處于2MSL等待狀態的端口（1174）處得到一個不一樣的外部端口號（1175），這樣一切都解決了。

如果客戶不發送PORT命令，而在客戶上指明一個臨時端口號，那么情況將改變。我們可以通過執行用戶命令sendport給FTP來使之發生。Unix FTP客戶用這個命令在每個數據連接使用之前關閉向服務器發送PORT命令。

圖27-8給出了用于兩個連續LIST命令的數據連接時間系列。控制連接起自主機svr4上的端口11 76，所以在沒有PORT命令的情況下，客戶和服務器給數據連接使用相同的端口號（除去了窗口通知和服務類型值）。

圖27-8 兩個連續LIST命令的數據連接

事件序列如下：

1：控制連接是建立在客戶端口1176到服務器端口21上的（這里我們不展示）。

2：當客戶為端口1176上的數據連接做被動打開時，由于該端口已被客戶上的控制連接使用，所以必須確定SO_REUSEADDR選項。

3：服務器給端口20到端口1176的數據連接（報文段1）做主動打開。即便端口1176已在客戶上被使用，客戶仍會接受它（報文段2），這是因為下面這一對插口是不同的：
<svr4,1176,bsdi,21>
<svr4,1176,bsdi,20>
（在bsdi上的端口號是不同的）。TCP通過查看源IP地址、源端口號、目的IP地址、目的端口號分用各呼入報文段，只要這4個元素中的一個不同，就行。

4：服務器對數據連接（報文段5）做主動的關閉，即把這對插口置入服務器上的一個2MSL等待。
<svr4,1176,bsdi,20>

5：客戶在控制連接上發送另一個LIST命令（這里我們不展示）。在此之前，客戶在端口11 76上為其數據連接端做一個被動打開。客戶必須再一次指明SO_REUSEADDR，這是因為端口號11 76已在使用。

6：服務器給從端口20到端口11 76的數據連接發出一個主動打開。在此之前，服務器必須指明SO_REUSEADDR，這是因為本地端口（20）與處于2MSL等待狀態的連接是相關聯的，但從18.6節所示可知，該連接將不成功。其原由是這個連接用插口對(socket pair)與步驟4中的仍處于2MSL等待狀態的插口對相同。TCP規定禁止服務器發送同步信息（SYN）。這樣就沒辦法讓服務器跨過插口對的2MSL等待狀態來重用相同的插口對。

在這一步伯克利軟件分發（BSD）服務器每隔5秒就重試一次連接請求，直到滿18次，總共90秒。我們看到報文段9將在大約1分鐘后成功（我們在第18章提到過，SVR4使用一個30秒的MSL，以兩個MSL來達到持續1分鐘的等待）。我們沒看到在這個時間系列上的這些失敗有任何同步（SYN）信息，這是因為主動打開失敗，服務器的TCP不再發送一個SYN。

Host Requirements RFC建議使用PORT命令的原因是在兩個相繼使用數據連接之間避免出現這個2MSL。通過不停地改變某一端的端口號，我們所說的這個問題就不會出現。

27.3.3 文本文件傳輸：NVT ASCII表示還是圖像表示

讓我們查證一下默認的文本文件傳輸使用NVT ASCII碼。這次不指定-d標志，所以不看客戶命令，但注意到客戶還將打印服務器的響應：

因為文件有4行，所以從數據連接上傳輸42個字節。Unix下的每一新行符（\n）被服務器轉換成NVT ASCII碼的2字節行結尾序列（\r\n）來傳輸，然后再由客戶轉換成原先形式來存儲。

新客戶試圖確定服務器是否是相同類型的系統，一旦相同，就可以用二進制碼（圖像文件類型）來傳輸文件，而不是ASCII碼。這可以獲得兩個方面的好處：

1：發方和收方不必查看每一字節（很大的節約）。

2：如果主機操作系統使用比2字節的NVT ASCII碼序列更少的字節來作行尾，就會傳輸更少的字節數（很小的節約）。

我們可以看到使用一個BSD/386客戶和服務器的最優效果。啟動排錯（debug）方式來看客戶FTP命令：

注冊到服務器后，客戶FTP自動發出SYST命令，服務器將用自己的系統類型來響應。如果應答起自字符串“215 UNIX Type:L8”，并且如果客戶在每字節為8bit的Unix系統上運行，那么二進制方式（圖像）將被所有文件傳輸所使用，除非被用戶改變。

當我們取文件hello.c時，客戶自動發出命令TYPE I把文件類型定成圖像。這樣在數據連接上只有38字節被傳輸。

Host Requirements RFC指出一個FTP服務器必須支持SYST命令（這曾是RFC 959中的一個選項）。但支持它的使用文本的系統（見封2）僅僅是BSD/386和AIX 3.2.2。SunOS 4.1.3和Solaris 2.x用500（不能理解的命令）來應答。SVR4采用極不大眾化的應答行為500，并關閉控制連接！

27.3.4 異常中止一個文件的傳輸：Telnet同步信號

現在看一下FTP客戶是怎樣異常中止一個來自服務器的文件傳輸。異常中止從客戶傳向服務器的文件很容易—只要客戶停止在數據連接上發送數據，并發出ABOR命令到控制連接上的服務器即可。而異常中止接收就復雜多了，這是因為客戶要告知服務器立即停止發送數據。我們前面提到要使用Telnet同步信號，下面的例子就是這樣。

我們先發起一個接收，并在它開始后鍵入中斷鍵。這里是交互會話，其中初始注冊被略去：

在我們鍵入中斷鍵之后，客戶立即告知我們它將發起異常中止，并正在等待服務器完成。服務器發出兩個應答：426和226。這兩個應答都是由Unix服務器在收到來自客戶的緊急數據和ABOR命令時發出的。

圖27-9和圖27-10展示了會話時間系列。我們已把控制連接（實線）和數據連接（虛線）合在一起來說明它們之間的關系。

圖27-9 異常中止一個文件的傳輸（前半部）

圖27-9的前面12個報文段是我們所期望的。通過控制連接的命令和應答建立起文件傳輸，數據連接被打開，第1個報文段的數據從服務器發往客戶。

圖27-10 異常中止一個文件的傳輸（后半部）

在圖27-10中，報文段13是數據連接上來自服務器的第6個數據報文段，后跟由我們鍵入的中斷鍵產生的報文段14。客戶發出10個字節來異常中止傳輸：

<IAC,IP,IAC,DM,A,B,O,R,\r,\n>
由于20.8節中詳細討論過這個問題，我們看到有兩個報文段（14和15）涉及到TCP的緊急指針（我們在圖26-17中看過對Telnet問題也做相同的處理）。Host Requirements RFC指出緊急指針應指向緊急數據的最后一個字節，而多數伯克利的派生實現使之指向緊急數據最后一個字節后面的第一個字節。了解到緊急指針將（錯誤地）指向下一個要寫的字節（數據標志，DM。在序號為54處），FTP客戶進程特意寫前3個字節作為緊急數據。首先寫下的3字節緊急數據與緊急指針一起被立即發送，緊接著是后面7個字節（BSD FTP服務器不會出現由客戶使用的緊急指針的解釋問題。當服務器收到控制連接上的緊急數據時，它讀下一個FTP命令，尋找ABOR或STAT，忽略嵌入的Telnet命令）。

注意到盡管服務器指出傳輸被異常中止（報文段18，在控制連接上），客戶進程還要在數據連接上再接收14個報文段的數據（序列號是1537~5120）。這些報文段可能在收到異常中止時，還在服務器上的網絡設備驅動器中排隊，但客戶打印“收到1536字節”，意思是在發出異常中止后（報文段14和15），略去收到的所有數據報文段。

一旦Telnet用戶鍵入中斷鍵，我們在圖26-17中看到Unix客戶在默認情況下不發出中斷進程命令作為緊急數據。因為幾乎沒有機會用流控制來中止從客戶進程到服務器進程的數據流，所以我們說這樣就行了。FTP的客戶進程也通過控制連接發送一個中斷進程命令，因為兩個連接正在被使用，因此沒有機會用流控制來中止控制連接。為什么FTP發送中斷進程命令作為緊急數據而Telnet不呢？答案在于FTP使用兩個連接，而Telnet只使用一個，在某些操作系統上要求一個進程同時監控兩個連接的輸入是困難的。FTP假設這些臨界的操作系統至少提供緊急數據在控制連接上已到達的通知，而后讓服務器從處理數據連接切換到控制連接上來。

27.3.5 匿名FTP

FTP的一種形式很常用，我們下面給出它的例子。它被稱為匿名FTP，當有服務器支持時，允許任何人注冊并使用FTP來傳輸文件。使用這個技術可以提供大量的自由信息。

怎樣找出你正在搜尋的站點是一個完全不同的問題。我們將在30.4節簡要介紹。

我們將把匿名FTP用在站點ftp.uu.net上（一個常用的匿名FTP站點）來取本書的勘誤表文件。要使用匿名FTP，須使用“anonymous”（復習數遍就能正確地拼寫）用戶名來注冊。當提示輸入口令時，我們鍵入自己的電子郵箱地址。

不壓縮是因為很多現行匿名FTP文件是用Unixcompress(1)程序壓縮的，這樣導致文件帶有.Z的擴展名。這些文件必須使用二進制文件類型來傳輸，而不是ASCII碼文件類型。

27.3.6 來自一個未知IP地址的匿名FTP

可以把一些使用匿名FTP的域名系統（DNS）特征和選路特征結合在一起。在14.5節中我們談到DNS中指針查詢現象—取一個IP地址并返回其主機名。不幸的是并非所有系統管理員都能正確地創立涉及指針查詢的名服務器。他們經常記得把新主機加入名字到地址匹配的文件中，卻忘了把他們加入到地址到名字匹配的文件中。對此，可用traceroute經常看到這種現象，即它打印一個IP地址，而不是主機名。

有些匿名FTP服務器要求客戶有一個有效域名。這就允許服務器來記錄正在執行傳輸的主機域名。由于服務器在來自客戶IP數據報中收到的關于客戶的唯一標識是客戶的IP地址，所以服務器能叫DNS來做指針查詢，并獲得客戶的域名。如果負責客戶主機的名服務器沒有正確地創立，指針查詢將失敗。

要看清這個錯誤，我們來做以下諸步驟：

1：把主機slip（見封2的圖）的IP地址換成140.252.13.67。這是給作者子網的一個有效IP地址，但沒有涉及到noao.edu域的域名服務器。

2：把在bsdi上SLIP連接的目的IP地址換成140.252.13.67。

3：把將數據報引向140.252.13.67的sun上的路由表入口加入路由器bsdi（回憶一下我們在9.2節中關于這個選路表的討論）。

從Internet上仍然可以訪問我們的主機slip，這是因為在10.4節中路由器gateway和netb正好把所有目的是子網140.252.13的所有數據報都發送給路由器sun。路由器sun知道利用我們在上述第3步建立的路由表入口來如何處理這些數據報。我們所創建的是擁有完整Internet連接性的主機，但沒有有效的域名。結果，指針查詢IP地址140.252.13.67將失敗。

現在給一個我們所知的服務器使用匿名FTP，需要一個有效的域名：

來自服務器的出錯應答是無需加以說明的。

27.4 小結

FTP是文件傳輸的Internet標準。與多數其他TCP應用不同，它在客戶進程和服務器進程之間使用兩個TCP連接—一個控制連接，它一直持續到客戶進程與服務器進程之間的會話完成為止；另一個按需可以隨時創建和撤消的數據連接。

FTP使用的關于數據連接的連接管理讓我們更詳細地了解TCP連接管理需求。我們看到TCP在不發出PORT命令的客戶進程上對2MSL等待狀態的作用。

FTP使用NVT ASCII碼做跨越控制連接的所有遠程登錄命令和應答。數據傳輸的默認方式通常也是NVT ASCII碼。我們看到較新的Unix客戶進程會自動發送命令來查看服務器是否是8bit字節的Unix主機，并且如果是，那么就使用二進制方式來傳輸所有文件，那將帶來更高的效率。

我們也展示了匿名FTP的一個例子，它是在Internet上分發軟件的常用形式。