27.1 引言

FTP是另一個常見的應(yīng)用程序霎苗。它是用于文件傳輸?shù)腎nternet標(biāo)準(zhǔn)秩铆。我們必須分清文件傳送（file transfer）和文件存取(file access)之間的區(qū)別冷溃，前者是FTP提供的镜会，后者是如NFS（Sun的網(wǎng)絡(luò)文件系統(tǒng)，第29章）等應(yīng)用系統(tǒng)提供的讨跟。由FTP提供的文件傳送是將一個完整的文件從一個系統(tǒng)復(fù)制到另一個系統(tǒng)中。要使用FTP鄙煤，就需要有登錄服務(wù)器的注冊帳號晾匠，或者通過允許匿名FTP的服務(wù)器來使用（本章我們將給出這樣的一個例子）。

與Telnet類似梯刚，F(xiàn)TP最早的設(shè)計(jì)是用于兩臺不同的主機(jī)凉馆，這兩個主機(jī)可能運(yùn)行在不同的操作系統(tǒng)下、使用不同的文件結(jié)構(gòu)、并可能使用不同字符集澜共。但不同的是向叉，Telnet獲得異構(gòu)性是強(qiáng)制兩端都采用同一個標(biāo)準(zhǔn)：使用7比特ASCII碼的NVT。而FTP是采用另一種方法來處理不同系統(tǒng)間的差異嗦董。FTP支持有限數(shù)量的文件類型（ASCII母谎，二進(jìn)制，等等）和文件結(jié)構(gòu)（面向字節(jié)流或記錄）京革。

參考文獻(xiàn)959 [Postel和Reynolds 1985] 是FTP的正式規(guī)范销睁。該文獻(xiàn)敘述了近年來文件傳輸?shù)臍v史演變。

27.2 FTP協(xié)議

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

1：控制連接以通常的客戶服務(wù)器方式建立睡毒。服務(wù)器以被動方式打開眾所周知的用于FTP的端口（21）来惧，等待客戶的連接⊙莨耍客戶則以主動方式打開TCP端口21供搀，來建立連接∧浦粒控制連接始終等待客戶與服務(wù)器之間的通信葛虐。該連接將命令從客戶傳給服務(wù)器，并傳回服務(wù)器的應(yīng)答棉钧。
由于命令通常是由用戶鍵入的屿脐，所以IP對控制連接的服務(wù)類型就是“最大限度地減小遲延”。

2：每當(dāng)一個文件在客戶與服務(wù)器之間傳輸時宪卿，就創(chuàng)建一個數(shù)據(jù)連接的诵。（其他時間也可以創(chuàng)建，后面我們將說到）佑钾。

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

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

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

從圖中可以看出代赁，交互式用戶通常不處理在控制連接中轉(zhuǎn)換的命令和應(yīng)答。這些細(xì)節(jié)均由兩個協(xié)議解釋器來完成兽掰。標(biāo)有“用戶接口”的方框功能是按用戶所需提供各種交互界面（全屏幕菜單選擇芭碍，逐行輸入命令，等等）禾进，并把它們轉(zhuǎn)換成在控制連接上發(fā)送的FTP命令豁跑。類似地，從控制連接上傳回的服務(wù)器應(yīng)答也被轉(zhuǎn)換成用戶所需的交互格式。

從圖中還可以看出艇拍，正是這兩個協(xié)議解釋器根據(jù)需要激活文件傳送功能狐蜕。

27.2.1 數(shù)據(jù)表示

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

1. 文件類型

a：ASCII碼文件類型（默認(rèn)選擇）文本文件以NVT ASCII碼形式在數(shù)據(jù)連接中傳輸层释。這要求發(fā)方將本地文本文件轉(zhuǎn)換成NVT ASCII碼形式，而收方則將NVT ASCII碼再還原成本地文本文件快集。其中贡羔，用NVT ASCII碼傳輸?shù)拿啃卸紟в幸粋€回車，而后是一個換行个初。這意味著收方必須掃描每個字節(jié)乖寒，查找CR、LF對（我們在第15.2節(jié)見過的關(guān)于TFIP的ASCII碼文件傳輸情況與此相同）院溺。

b：EBCDIC文件類型該文本文件傳輸方式要求兩端都是EBCDIC系統(tǒng)楣嘁。
圖像文件類型（也稱為二進(jìn)制文件類型）數(shù)據(jù)發(fā)送呈現(xiàn)為一個連續(xù)的比特流。通常用于傳輸二進(jìn)制文件珍逸。

c：本地文件類型該方式在具有不同字節(jié)大小的主機(jī)間傳輸二進(jìn)制文件逐虚。每一字節(jié)的比特數(shù)由發(fā)方規(guī)定。對使用8bit字節(jié)的系統(tǒng)來說谆膳，本地文件以8bit字節(jié)傳輸就等同于圖像文件傳輸叭爱。

2. 格式控制

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

a：非打邮　（默認(rèn)選擇）文件中不含有垂直格式信息买雾。

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

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

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

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

b：記錄結(jié)構(gòu)該結(jié)構(gòu)只用于文本文件（ASCII或EBCDIC）睦尽。

c：頁結(jié)構(gòu)每頁都帶有頁號發(fā)送器净，以便收方能隨機(jī)地存儲各頁。該結(jié)構(gòu)由TO PS-20操作系統(tǒng)提供（主機(jī)需求RFC不提倡采用該結(jié)構(gòu)）当凡。

4. 傳輸方式

它規(guī)定文件在數(shù)據(jù)連接中如何傳輸山害。

a：流方式（默認(rèn)選擇）文件以字節(jié)流的形式傳輸。對于文件結(jié)構(gòu)沿量，發(fā)方在文件尾提示關(guān)閉數(shù)據(jù)連接浪慌。對于記錄結(jié)構(gòu)，有專用的兩字節(jié)序列碼標(biāo)志記錄結(jié)束和文件結(jié)束朴则。

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

c：壓縮方式一個簡單的全長編碼壓縮方法，壓縮連續(xù)出現(xiàn)的相同字節(jié)汹想。在文本文件中常用來壓縮空白串外邓，在二進(jìn)制文件中常用來壓縮0字節(jié)（這種方式很少使用，也不受支持」盘停現(xiàn)在有一些更好的文件壓縮方法來支持FTP）损话。

如果算一下所有這些選擇的排列組合數(shù)，那么對傳輸和存儲一個文件來說就有72種不同的方式槽唾。幸運(yùn)的是丧枪，其中很多選擇不是廢棄了，就是不為多數(shù)實(shí)現(xiàn)環(huán)境所支持庞萍，所以我們可以忽略掉它們拧烦。

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

? 類型：ASCII或圖像。

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

? 結(jié)構(gòu)：只允許文件結(jié)構(gòu)屎篱。

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

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

該實(shí)現(xiàn)滿足主機(jī)需求RFC的最小需求（該RFC也要求能支持記錄結(jié)構(gòu)重虑，但只有操作系統(tǒng)支持它才行践付，而Unix不行）。

很多非Unix的實(shí)現(xiàn)提供了處理它們自己文件格式的FTP功能缺厉。主機(jī)需求RFC指出“FTP協(xié)議有很多特征永高，雖然其中一些通常不實(shí)現(xiàn)，但對FTP中的每一個特征來說提针，都存在著至少一種實(shí)現(xiàn)”命爬。

27.2.2 FTP命令

命令和應(yīng)答在客戶和服務(wù)器的控制連接上以NVT ASCII碼形式傳送。這就要求在每行結(jié)尾都要返回CR辐脖、LF對（也就是每個命令或每個應(yīng)答）饲宛。

從客戶發(fā)向服務(wù)器的Telnet命令（以IAC打頭）只有中斷進(jìn)程（<IAC,IP>）和Telnet的同步信號（緊急方式下<IAC,DM>）。我們將看到這兩條Telnet命令被用來中止正在進(jìn)行的文件傳輸嗜价，或在傳輸過程中查詢服務(wù)器艇抠。另外，如果服務(wù)器接受了客戶端的一個帶選項(xiàng)的Telnet命令（WILL久锥，WONT家淤，DO或DONT），它將以DONT或WONT響應(yīng)瑟由。

這些命令都是3或4個字節(jié)的大寫ASCII字符絮重，其中一些帶選項(xiàng)參數(shù)。從客戶向服務(wù)器發(fā)送的FTP命令超過30種。圖27-2給出了一些常用命令青伤，其中大部分將在本章再次遇到督怜。

圖27-2 常用的FTP命令

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

27.2.3 FTP應(yīng)答

應(yīng)答都是ASCII碼形式的3位數(shù)字擎厢，并跟有報文選項(xiàng)究流。其原因是軟件系統(tǒng)需要根據(jù)數(shù)字代碼來決定如何應(yīng)答，而選項(xiàng)串是面向人工處理的动遭。由于客戶通常都要輸出數(shù)字應(yīng)答和報文串芬探，一個可交互的用戶可以通過閱讀報文串（而不必記憶所有數(shù)字回答代碼的含義）來確定應(yīng)答的含義。

應(yīng)答3位碼中每一位數(shù)字都有不同的含義（我們將在第28章看到簡單郵件傳送輸協(xié)議厘惦，SMTP偷仿，使用相同的命令和應(yīng)答約定）。

圖27-3給出了應(yīng)答代碼第1位和第2位的含義宵蕉。

圖27-3 應(yīng)答代碼3位數(shù)字中第1位和第2位的含義

第3位數(shù)字給出差錯報文的附加含義酝静。例如，這里是一些典型的應(yīng)答羡玛，都帶有一個可能的報文串别智。

? 125 數(shù)據(jù)連接已經(jīng)打開;傳輸開始。

? 200 就緒命令稼稿。

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

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

? 425 不能打開數(shù)據(jù)連接让歼。

? 452 錯寫文件敞恋。

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

? 501 語法錯誤(無效參數(shù))谋右。

? 502 未實(shí)現(xiàn)的 MODE ( 方式命令 ) 類型硬猫。

通常每個FTP命令都產(chǎn)生一行回答。例如改执，QUIT命令可以產(chǎn)生如下應(yīng)答：

221 Goodbye.

如果需要產(chǎn)生一條多行應(yīng)答浦徊，第1行在3位數(shù)字應(yīng)答代碼之后包含一個連字號，而不是空格天梧，最后一行包含相同的3位數(shù)字應(yīng)答代碼盔性，后跟一個空格符。例如呢岗，HELP命令可以產(chǎn)生如下應(yīng)答：

27.2.4 連接管理

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

1：從客戶向服務(wù)器發(fā)送一個文件冕香。

2：從服務(wù)器向客戶發(fā)送一個文件蛹尝。

3：從服務(wù)器向客戶發(fā)送文件或目錄列表。

FTP服務(wù)器把文件列表從數(shù)據(jù)連接上發(fā)回悉尾，而不是控制連接上的多行應(yīng)答突那。這就避免了行的有限性對目錄大小的限制，而且更易于客戶將目錄列表以文件形式保存构眯，而不是把列表顯示在終端上愕难。

我們已說過，控制連接一直保持到客戶-服務(wù)器連接的全過程惫霸，但數(shù)據(jù)連接可以根據(jù)需要隨時來猫缭，隨時走。那么需要怎樣為數(shù)據(jù)連接選端口號壹店，以及誰來負(fù)責(zé)主動打開和被動打開猜丹？

首先，我們前面說過通用傳輸方式（Unix環(huán)境下唯一的傳輸方式）是流方式硅卢，并且文件結(jié)尾是以關(guān)閉數(shù)據(jù)連接為標(biāo)志射窒。這意味著對每一個文件傳輸或目錄列表來說都要建立一個全新的數(shù)據(jù)連接。其一般過程如下：

1：正由于是客戶發(fā)出命令要求建立數(shù)據(jù)連接将塑，所以數(shù)據(jù)連接是在客戶的控制下建立的脉顿。

2：客戶通常在客戶端主機(jī)上為所在數(shù)據(jù)連接端選擇一個臨時端口號〉懔龋客戶從該端口發(fā)布一個被動的打開艾疟。

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

4：服務(wù)器在控制連接上接收端口號开财，并向客戶端主機(jī)上的端口發(fā)布一個主動的打開。服務(wù)器的數(shù)據(jù)連接端一直使用端口20误褪。

圖27-4給出了第3步執(zhí)行時的連接狀態(tài)责鳍。假設(shè)客戶用于控制連接的臨時端口是1173，客戶用于數(shù)據(jù)連接的臨時端口是1174兽间±穑客戶發(fā)出的命令是PORT命令，其參數(shù)是6個ASCII中的十進(jìn)制數(shù)字嘀略，它們之間由逗點(diǎn)隔開恤溶。前面4個數(shù)字指明客戶上的IP地址，服務(wù)器將向它發(fā)出主動打開（本例中是140.252.13.34）帜羊，而后兩位指明16 bit端口地址咒程。由于16 bit端口地址是從這兩個數(shù)字中得來，所以其值在本例中就是4×256+150=1174讼育。

圖27-5給出了服務(wù)器向客戶所在數(shù)據(jù)連接端發(fā)布主動打開時的連接狀態(tài)帐姻。服務(wù)器的端點(diǎn)是端口20稠集。

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

圖27-5 主動打開數(shù)據(jù)連接的FTP服務(wù)器

服務(wù)器總是執(zhí)行數(shù)據(jù)連接的主動打開。通常服務(wù)器也執(zhí)行數(shù)據(jù)連接的主動關(guān)閉饥瓷，除非當(dāng)客戶向服務(wù)器發(fā)送流形式的文件時剥纷，需要客戶來關(guān)閉連接（它給服務(wù)器一個文件結(jié)束的通知）。

客戶也有可能不發(fā)出PORT命令呢铆，而由服務(wù)器向正被客戶使用的同一個端口號發(fā)出主動打開晦鞋，來結(jié)束控制連接。這是可行的棺克，因?yàn)榉?wù)器面向這兩個連接的端口號是不同的：一個是20悠垛，另一個是21。不過逆航，下節(jié)我們將看到為什么現(xiàn)有實(shí)現(xiàn)通常不這樣做鼎文。

27.3 FTP的例子

現(xiàn)在看一些使用FTP的例子：它對數(shù)據(jù)連接的管理，采用NVT ASCII碼的文本文件如何發(fā)送因俐，F(xiàn)TP使用Telnet同步信號來中止進(jìn)行中的文件傳輸拇惋，最后是常用的“匿名FTP”。

27.3.1 連接管理：臨時數(shù)據(jù)端口

先看一下FTP的連接管理抹剩，它只在服務(wù)器上用簡單FTP會話顯示一個文件撑帖。我們用-d標(biāo)志（debug）來運(yùn)行svr4主機(jī)上的客戶。這告訴它要打印控制連接上變換的命令和應(yīng)答澳眷。所有前面冠以--->的行是從客戶上發(fā)向服務(wù)器的胡嘿，所有以3位數(shù)字開頭的行都是服務(wù)器的應(yīng)答∏唬客戶的交互提示是ftp>衷敌。

當(dāng)FTP客戶提示我們注冊姓名時，它打印了默認(rèn)值（我們在客戶上的注冊名）拓瞪。當(dāng)我們敲RETURN鍵時缴罗，默認(rèn)值被發(fā)送出去。

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

圖27-6是控制連接上分組交換的時間系列（已除去了控制連接的建立和結(jié)束泰演，以及所有窗口大小的通知）呻拌。我們關(guān)注該圖中數(shù)據(jù)連接在哪兒被打開、使用和過后的關(guān)閉睦焕。

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

在時間系列上抬闷，F(xiàn)TP服務(wù)器執(zhí)行數(shù)據(jù)連接的主動打開妇蛀，從端口20（稱為ftp-data）到來自PORT命令的端口號（1174）。本例中還可以看到服務(wù)器在哪兒向數(shù)據(jù)連接上執(zhí)行寫操作笤成，服務(wù)器對數(shù)據(jù)連接執(zhí)行主動的關(guān)閉评架，這就告訴客戶列表已完成。

圖27-6 FTP控制連接示例

圖27-7 FTP數(shù)據(jù)連接示例

27.3.2 連接管理：默認(rèn)數(shù)據(jù)端口

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

Host Requirements RFC建議使用流方式的FTP客戶在每次使用數(shù)據(jù)連接前發(fā)一個PORT命令來啟用一個非默認(rèn)的端口號浙芙。

回到先前的例子（圖27-6），如果我們要求在列出第1個目錄后幾秒鐘再列出另一個目錄籽腕，那該怎么辦嗡呼？客戶將要求其內(nèi)核選擇另一個臨時端口號（可能是1175），下一個數(shù)據(jù)連接將建立在svr4端口1175和bsdi端口20之間皇耗。但在圖27-7中服務(wù)器執(zhí)行數(shù)據(jù)連接的主動打開南窗，我們在18.6節(jié)說明了服務(wù)器將不把端口20分配給新的數(shù)據(jù)連接，這是因?yàn)楸镜囟丝谔栆驯桓绲倪B接使用郎楼，而且還處于2MSL等待狀態(tài)万伤。

服務(wù)器通過指明我們在18.6節(jié)中提到的SO_REUSEADDR選項(xiàng)，來解決這個問題呜袁。這讓它把端口20分配給新連接敌买，而新連接將從處于2MSL等待狀態(tài)的端口（1174）處得到一個不一樣的外部端口號（1175），這樣一切都解決了傅寡。

如果客戶不發(fā)送PORT命令放妈，而在客戶上指明一個臨時端口號北救，那么情況將改變荐操。我們可以通過執(zhí)行用戶命令sendport給FTP來使之發(fā)生。Unix FTP客戶用這個命令在每個數(shù)據(jù)連接使用之前關(guān)閉向服務(wù)器發(fā)送PORT命令珍策。

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

圖27-8 兩個連續(xù)LIST命令的數(shù)據(jù)連接

事件序列如下：

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

2：當(dāng)客戶為端口1176上的數(shù)據(jù)連接做被動打開時疗绣，由于該端口已被客戶上的控制連接使用线召，所以必須確定SO_REUSEADDR選項(xiàng)。

3：服務(wù)器給端口20到端口1176的數(shù)據(jù)連接（報文段1）做主動打開多矮。即便端口1176已在客戶上被使用缓淹，客戶仍會接受它（報文段2），這是因?yàn)橄旅孢@一對插口是不同的：
<svr4,1176,bsdi,21>
<svr4,1176,bsdi,20>
（在bsdi上的端口號是不同的）塔逃。TCP通過查看源IP地址讯壶、源端口號、目的IP地址湾盗、目的端口號分用各呼入報文段伏蚊，只要這4個元素中的一個不同，就行格粪。

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

5：客戶在控制連接上發(fā)送另一個LIST命令（這里我們不展示）匀借。在此之前颜阐，客戶在端口11 76上為其數(shù)據(jù)連接端做一個被動打開∠爬撸客戶必須再一次指明SO_REUSEADDR凳怨，這是因?yàn)槎丝谔?1 76已在使用。

6：服務(wù)器給從端口20到端口11 76的數(shù)據(jù)連接發(fā)出一個主動打開是鬼。在此之前肤舞，服務(wù)器必須指明SO_REUSEADDR，這是因?yàn)楸镜囟丝冢?0）與處于2MSL等待狀態(tài)的連接是相關(guān)聯(lián)的均蜜，但從18.6節(jié)所示可知李剖，該連接將不成功。其原由是這個連接用插口對(socket pair)與步驟4中的仍處于2MSL等待狀態(tài)的插口對相同囤耳。TCP規(guī)定禁止服務(wù)器發(fā)送同步信息（SYN）篙顺。這樣就沒辦法讓服務(wù)器跨過插口對的2MSL等待狀態(tài)來重用相同的插口對。

在這一步伯克利軟件分發(fā)（BSD）服務(wù)器每隔5秒就重試一次連接請求充择，直到滿18次德玫，總共90秒。我們看到報文段9將在大約1分鐘后成功（我們在第18章提到過椎麦，SVR4使用一個30秒的MSL宰僧，以兩個MSL來達(dá)到持續(xù)1分鐘的等待）。我們沒看到在這個時間系列上的這些失敗有任何同步（SYN）信息观挎，這是因?yàn)橹鲃哟蜷_失敗琴儿，服務(wù)器的TCP不再發(fā)送一個SYN段化。

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

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

讓我們查證一下默認(rèn)的文本文件傳輸使用NVT ASCII碼。這次不指定-d標(biāo)志晒屎，所以不看客戶命令佃延，但注意到客戶還將打印服務(wù)器的響應(yīng)：

因?yàn)槲募?行，所以從數(shù)據(jù)連接上傳輸42個字節(jié)夷磕。Unix下的每一新行符（\n）被服務(wù)器轉(zhuǎn)換成NVT ASCII碼的2字節(jié)行結(jié)尾序列（\r\n）來傳輸履肃，然后再由客戶轉(zhuǎn)換成原先形式來存儲。

新客戶試圖確定服務(wù)器是否是相同類型的系統(tǒng)坐桩，一旦相同尺棋，就可以用二進(jìn)制碼（圖像文件類型）來傳輸文件，而不是ASCII碼绵跷。這可以獲得兩個方面的好處：

1：發(fā)方和收方不必查看每一字節(jié)（很大的節(jié)約）膘螟。

2：如果主機(jī)操作系統(tǒng)使用比2字節(jié)的NVT ASCII碼序列更少的字節(jié)來作行尾，就會傳輸更少的字節(jié)數(shù)（很小的節(jié)約）碾局。

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

注冊到服務(wù)器后，客戶FTP自動發(fā)出SYST命令净当，服務(wù)器將用自己的系統(tǒng)類型來響應(yīng)内斯。如果應(yīng)答起自字符串“215 UNIX Type:L8”，并且如果客戶在每字節(jié)為8bit的Unix系統(tǒng)上運(yùn)行像啼，那么二進(jìn)制方式（圖像）將被所有文件傳輸所使用俘闯，除非被用戶改變。

當(dāng)我們?nèi)∥募ello.c時忽冻，客戶自動發(fā)出命令TYPE I把文件類型定成圖像真朗。這樣在數(shù)據(jù)連接上只有38字節(jié)被傳輸。

Host Requirements RFC指出一個FTP服務(wù)器必須支持SYST命令（這曾是RFC 959中的一個選項(xiàng)）僧诚。但支持它的使用文本的系統(tǒng)（見封2）僅僅是BSD/386和AIX 3.2.2遮婶。SunOS 4.1.3和Solaris 2.x用500（不能理解的命令）來應(yīng)答。SVR4采用極不大眾化的應(yīng)答行為500湖笨，并關(guān)閉控制連接旗扑！

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

現(xiàn)在看一下FTP客戶是怎樣異常中止一個來自服務(wù)器的文件傳輸。異常中止從客戶傳向服務(wù)器的文件很容易—只要客戶停止在數(shù)據(jù)連接上發(fā)送數(shù)據(jù)赶么，并發(fā)出ABOR命令到控制連接上的服務(wù)器即可肩豁。而異常中止接收就復(fù)雜多了脊串，這是因?yàn)榭蛻粢嬷?wù)器立即停止發(fā)送數(shù)據(jù)辫呻。我們前面提到要使用Telnet同步信號清钥，下面的例子就是這樣。

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

在我們鍵入中斷鍵之后怖侦，客戶立即告知我們它將發(fā)起異常中止篡悟，并正在等待服務(wù)器完成。服務(wù)器發(fā)出兩個應(yīng)答：426和226匾寝。這兩個應(yīng)答都是由Unix服務(wù)器在收到來自客戶的緊急數(shù)據(jù)和ABOR命令時發(fā)出的搬葬。

圖27-9和圖27-10展示了會話時間系列。我們已把控制連接（實(shí)線）和數(shù)據(jù)連接（虛線）合在一起來說明它們之間的關(guān)系艳悔。

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

圖27-9的前面12個報文段是我們所期望的急凰。通過控制連接的命令和應(yīng)答建立起文件傳輸，數(shù)據(jù)連接被打開猜年，第1個報文段的數(shù)據(jù)從服務(wù)器發(fā)往客戶抡锈。

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

在圖27-10中，報文段13是數(shù)據(jù)連接上來自服務(wù)器的第6個數(shù)據(jù)報文段乔外，后跟由我們鍵入的中斷鍵產(chǎn)生的報文段14床三。客戶發(fā)出10個字節(jié)來異常中止傳輸：

<IAC,IP,IAC,DM,A,B,O,R,\r,\n>
由于20.8節(jié)中詳細(xì)討論過這個問題杨幼，我們看到有兩個報文段（14和15）涉及到TCP的緊急指針（我們在圖26-17中看過對Telnet問題也做相同的處理）撇簿。Host Requirements RFC指出緊急指針應(yīng)指向緊急數(shù)據(jù)的最后一個字節(jié)，而多數(shù)伯克利的派生實(shí)現(xiàn)使之指向緊急數(shù)據(jù)最后一個字節(jié)后面的第一個字節(jié)差购。了解到緊急指針將（錯誤地）指向下一個要寫的字節(jié)（數(shù)據(jù)標(biāo)志补疑，DM。在序號為54處）歹撒，F(xiàn)TP客戶進(jìn)程特意寫前3個字節(jié)作為緊急數(shù)據(jù)莲组。首先寫下的3字節(jié)緊急數(shù)據(jù)與緊急指針一起被立即發(fā)送，緊接著是后面7個字節(jié)（BSD FTP服務(wù)器不會出現(xiàn)由客戶使用的緊急指針的解釋問題暖夭。當(dāng)服務(wù)器收到控制連接上的緊急數(shù)據(jù)時锹杈，它讀下一個FTP命令，尋找ABOR或STAT迈着，忽略嵌入的Telnet命令）竭望。

注意到盡管服務(wù)器指出傳輸被異常中止（報文段18，在控制連接上）裕菠，客戶進(jìn)程還要在數(shù)據(jù)連接上再接收14個報文段的數(shù)據(jù)（序列號是1537~5120）咬清。這些報文段可能在收到異常中止時，還在服務(wù)器上的網(wǎng)絡(luò)設(shè)備驅(qū)動器中排隊(duì)，但客戶打印“收到1536字節(jié)”旧烧，意思是在發(fā)出異常中止后（報文段14和15）影钉，略去收到的所有數(shù)據(jù)報文段。

一旦Telnet用戶鍵入中斷鍵掘剪，我們在圖26-17中看到Unix客戶在默認(rèn)情況下不發(fā)出中斷進(jìn)程命令作為緊急數(shù)據(jù)平委。因?yàn)閹缀鯖]有機(jī)會用流控制來中止從客戶進(jìn)程到服務(wù)器進(jìn)程的數(shù)據(jù)流，所以我們說這樣就行了夺谁。FTP的客戶進(jìn)程也通過控制連接發(fā)送一個中斷進(jìn)程命令廉赔，因?yàn)閮蓚€連接正在被使用，因此沒有機(jī)會用流控制來中止控制連接匾鸥。為什么FTP發(fā)送中斷進(jìn)程命令作為緊急數(shù)據(jù)而Telnet不呢蜡塌？答案在于FTP使用兩個連接，而Telnet只使用一個勿负，在某些操作系統(tǒng)上要求一個進(jìn)程同時監(jiān)控兩個連接的輸入是困難的岗照。FTP假設(shè)這些臨界的操作系統(tǒng)至少提供緊急數(shù)據(jù)在控制連接上已到達(dá)的通知，而后讓服務(wù)器從處理數(shù)據(jù)連接切換到控制連接上來笆环。

27.3.5 匿名FTP

FTP的一種形式很常用攒至，我們下面給出它的例子。它被稱為匿名FTP躁劣，當(dāng)有服務(wù)器支持時濒憋，允許任何人注冊并使用FTP來傳輸文件眼虱。使用這個技術(shù)可以提供大量的自由信息。

怎樣找出你正在搜尋的站點(diǎn)是一個完全不同的問題。我們將在30.4節(jié)簡要介紹修肠。

我們將把匿名FTP用在站點(diǎn)ftp.uu.net上（一個常用的匿名FTP站點(diǎn)）來取本書的勘誤表文件朦乏。要使用匿名FTP顾翼，須使用“anonymous”（復(fù)習(xí)數(shù)遍就能正確地拼寫）用戶名來注冊芋忿。當(dāng)提示輸入口令時，我們鍵入自己的電子郵箱地址蒋荚。

不壓縮是因?yàn)楹芏喱F(xiàn)行匿名FTP文件是用Unixcompress(1)程序壓縮的戳稽，這樣導(dǎo)致文件帶有.Z的擴(kuò)展名。這些文件必須使用二進(jìn)制文件類型來傳輸期升，而不是ASCII碼文件類型惊奇。

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

可以把一些使用匿名FTP的域名系統(tǒng)（DNS）特征和選路特征結(jié)合在一起。在14.5節(jié)中我們談到DNS中指針查詢現(xiàn)象—取一個IP地址并返回其主機(jī)名播赁。不幸的是并非所有系統(tǒng)管理員都能正確地創(chuàng)立涉及指針查詢的名服務(wù)器颂郎。他們經(jīng)常記得把新主機(jī)加入名字到地址匹配的文件中，卻忘了把他們加入到地址到名字匹配的文件中容为。對此乓序，可用traceroute經(jīng)乘吕遥看到這種現(xiàn)象，即它打印一個IP地址替劈，而不是主機(jī)名寄雀。

有些匿名FTP服務(wù)器要求客戶有一個有效域名。這就允許服務(wù)器來記錄正在執(zhí)行傳輸?shù)闹鳈C(jī)域名抬纸。由于服務(wù)器在來自客戶IP數(shù)據(jù)報中收到的關(guān)于客戶的唯一標(biāo)識是客戶的IP地址，所以服務(wù)器能叫DNS來做指針查詢耿戚，并獲得客戶的域名湿故。如果負(fù)責(zé)客戶主機(jī)的名服務(wù)器沒有正確地創(chuàng)立，指針查詢將失敗膜蛔。

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

1：把主機(jī)slip（見封2的圖）的IP地址換成140.252.13.67。這是給作者子網(wǎng)的一個有效IP地址皂股，但沒有涉及到noao.edu域的域名服務(wù)器墅茉。

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

3：把將數(shù)據(jù)報引向140.252.13.67的sun上的路由表入口加入路由器bsdi（回憶一下我們在9.2節(jié)中關(guān)于這個選路表的討論）呜呐。

從Internet上仍然可以訪問我們的主機(jī)slip就斤，這是因?yàn)樵?0.4節(jié)中路由器gateway和netb正好把所有目的是子網(wǎng)140.252.13的所有數(shù)據(jù)報都發(fā)送給路由器sun。路由器sun知道利用我們在上述第3步建立的路由表入口來如何處理這些數(shù)據(jù)報蘑辑。我們所創(chuàng)建的是擁有完整Internet連接性的主機(jī)洋机，但沒有有效的域名。結(jié)果洋魂，指針查詢IP地址140.252.13.67將失敗绷旗。

現(xiàn)在給一個我們所知的服務(wù)器使用匿名FTP，需要一個有效的域名：

來自服務(wù)器的出錯應(yīng)答是無需加以說明的副砍。

27.4 小結(jié)

FTP是文件傳輸?shù)腎nternet標(biāo)準(zhǔn)衔肢。與多數(shù)其他TCP應(yīng)用不同，它在客戶進(jìn)程和服務(wù)器進(jìn)程之間使用兩個TCP連接—一個控制連接豁翎，它一直持續(xù)到客戶進(jìn)程與服務(wù)器進(jìn)程之間的會話完成為止角骤；另一個按需可以隨時創(chuàng)建和撤消的數(shù)據(jù)連接。

FTP使用的關(guān)于數(shù)據(jù)連接的連接管理讓我們更詳細(xì)地了解TCP連接管理需求心剥。我們看到TCP在不發(fā)出PORT命令的客戶進(jìn)程上對2MSL等待狀態(tài)的作用启搂。

FTP使用NVT ASCII碼做跨越控制連接的所有遠(yuǎn)程登錄命令和應(yīng)答。數(shù)據(jù)傳輸?shù)哪J(rèn)方式通常也是NVT ASCII碼刘陶。我們看到較新的Unix客戶進(jìn)程會自動發(fā)送命令來查看服務(wù)器是否是8bit字節(jié)的Unix主機(jī)胳赌，并且如果是，那么就使用二進(jìn)制方式來傳輸所有文件匙隔，那將帶來更高的效率疑苫。

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