1、 下載第27章FTP：文件傳送協(xié)議27.1引言 FTP是另一個常見的應用程序。它是用于文件傳輸的 Internet標準。我們必須分清文件傳送（ file transfer ）和文件存取 (file access) 之間的區(qū)別，前者是 FTP提供的，后者是如 NFS（Sun的網絡文件系統(tǒng)，第 29章）等應用系統(tǒng)提供的。由 FTP提供的文件傳送是將一個完整的文件從一個系統(tǒng)復制到另一個系統(tǒng)中。要使用 FTP，就需要有登錄服務器的注冊帳號，或者通過允許 FTP的服務器來使用（本章我們將給出這樣的一個例子）。 與Telnet類似，FTP最早的設計是用于兩臺不同的主機，這兩個主機可能運行在不同的操作系統(tǒng)下

2、、使用不同的文件結構、并可能使用不同字符集。但不同的是，Telnet獲得異構性是強制兩端都采用同一個標準：使用7比特ASCII碼的NVT。而FTP是采用另一種方法來處理不同系統(tǒng)間的差異。FTP支持有限數量的文件類型（ASCII，二進制，等等）和文件結構（面向字節(jié)流或記錄）。 參考文獻959 Postel 和 Reynolds 1985 是FTP的正式規(guī)范。該文獻敘述了近年來文件傳輸的歷史演變。 27.2 FTP協(xié)議 FTP與我們已描述的另一種應用不同，它采用兩個 TCP連接來傳輸一個文件。 1) 控制連接以通常的客戶服務器方式建立。服務器以被動方式打開眾所周知的用于FTP 的端口（ 21），等

3、待客戶的連接。客戶則以主動方式打開 TCP端口21，來建立連接。控制連接始終等待客戶與服務器之間的通信。該連接將命令從客戶傳給服務器， 并傳回服務器的應答。 由于命令通常是由用戶鍵入的，所以IP對控制連接的服務類型就是“最大限度地減小遲延”。 2) 每當一個文件在客戶與服務器之間傳輸時，就創(chuàng)建一個數據連接。（其他時間也可以創(chuàng)建，后面我們將說到）。 由于該連接用于傳輸目的，所以IP對數據連接的服務特點就是“最大限度提高吞吐量”。圖27-1描述了客戶與服務器以及它們之間的連接情況 從圖中可以看出，交互式用戶通常不處理在控制連接中轉換的命令和應答。這些細節(jié)均由兩個協(xié)議解釋器來完成。標有“用戶接口”的

4、方框功能是按用戶所需提供各種交互界面 （全屏幕菜單選擇，逐行輸入命令，等等），并把它們轉換成在控制連接上發(fā)送的 FTP命令。類似地，從控制連接上傳回的服務器應答也被轉換成用戶所需的交互格式。 從圖中還可以看出，正是這兩個協(xié)議解釋器根據需要激活文件傳送功能。 27.2.1 數據表示 FTP協(xié)議規(guī)范提供了控制文件傳送與存儲的多種選擇。在以下四個方面中每一個方面都必 須作出一個選擇。 317 第27章 FTP：文件傳送協(xié)議 下載客戶 在終端上的用戶 用戶接口服務器控制連接服務器協(xié)議接口 用戶協(xié)議解釋器 (FTP命令) (FTP應答)用戶數據傳輸功能 服務器數據傳輸功能 文件系統(tǒng)文件系統(tǒng)數據連接圖27

5、-1文件傳輸中的處理過程1. 文件類型 (a) ASCII碼文件類型 （默認選擇）文本文件以NVT ASCII碼形式在數據連接中傳輸。這要求發(fā)方將本地文本文件轉換成NVT ASCII碼形式，而收方則將NVT ASCII碼再還原成本地文本文件。其中，用NVT ASCII碼傳輸的每行都帶有一個回車，而后是一個換行。這意味著收方必須掃描每個字節(jié)，查找CR、LF對（我們在第15.2節(jié)見過的關于TFIP的ASCII碼文件傳輸情況與此相同）。 (b) EBCDIC文件類型 該文本文件傳輸方式要求兩端都是EBCDIC系統(tǒng)。 (c) 圖像文件類型（也稱為二進制文件類型） 用于傳輸二進制文件。 (d) 本地文件

6、類型 該方式在具有不同字節(jié)大小的主機間傳輸二進制文件。每一字節(jié)的比特數由發(fā)方規(guī)定。對使用8 bit字節(jié)的系統(tǒng)來說，本地文件以8 bit字節(jié)傳輸就等同于圖像文件傳輸。 2. 格式控制 該選項只對ASCII和EBCDIC文件類型有效。 (a) 非打印 （默認選擇）文件中不含有垂直格式信息。 (b) 遠程登錄格式控制 文件含有向打印機解釋的遠程登錄垂直格式控制。 (c) Fortran 回車控制 每行首字符是Fortran格式控制符。 3. 結構 （a） 文件結構 （默認選擇）文件被認為是一個連續(xù)的字節(jié)流。不存在內部的文件結構。（b） 記錄結構 該結構只用于文本文件（ ASCII或EBCDIC）。

7、數據發(fā)送呈現為一個連續(xù)的比特流。通常 （c） 頁結構每頁都帶有頁號發(fā)送，以便收方能隨機地存儲各頁。該結構由 TOPS-20操 作系統(tǒng)提供（主機需求RFC不提倡采用該結構）。4. 傳輸方式 它規(guī)定文件在數據連接中如何傳輸。 （a） 流方式（默認選擇）文件以字節(jié)流的形式傳輸。對于文件結構，發(fā)方在文件尾提 示關閉數據連接。對于記錄結構，有專用的兩字節(jié)序列碼標志記錄結束和文件結束。 （b） 塊方式 文件以一系列塊來傳輸，每塊前面都帶有一個或多個首部字節(jié)。 （c） 壓縮方式一個簡單的全長編碼壓縮方法，壓縮連續(xù)出現的相同字節(jié)。在文本文件 318TCP/IP詳解，卷1：協(xié)議 下載中常用來壓縮空白串，在二進制

8、文件中常用來壓縮 0字節(jié)（這種方式很少使用，也不受支持?，F在有一些更好的文件壓縮方法來支持FTP）。 如果算一下所有這些選擇的排列組合數，那么對傳輸和存儲一個文件來說就有 72種不同的方式。幸運的是，其中很多選擇不是廢棄了，就是不為多數實現環(huán)境所支持，所以我們可以忽略掉它們。 通常由Unix實現的FTP 客戶和服務器把我們的選擇限制如下： 類型：ASCII或圖像。 格式控制：只允許非打印。 結構：只允許文件結構。 傳輸方式：只允許流方式。 這就限制我們只能取一、兩種方式： ASCII或圖像（二進制）。 該實現滿足主機需求 RFC的最小需求（該RFC也要求能支持記錄結構，但只有操作系統(tǒng)支持它才行

9、，而Unix不行）。 很多非Unix的實現提供了處理它們自己文件格式的 FTP功能。主機需求RFC指出“ FTP協(xié)議有很多特征，雖然其中一些通常不實現，但對 FTP中的每一個特征來說，都存在著至少一種 實現”。 27.2.2 FTP命令 命令和應答在客戶和服務器的控制連接上以 NVT ASCII碼形式傳送。這就要求在每行結尾都要返回CR、LF對（也就是每個命令或每個應答）。 從客戶發(fā)向服務器的Telnet命令（以IAC打頭）只有中斷進程（ ）和Telnet的同步信號（緊急方式下）。我們將看到這兩條 Telnet命令被用來中止正在進行的文件傳輸，或在傳輸過程中查詢服務器。另外，如果服務器接受了客

10、戶端的一個帶選項的 Telnet命令（WILL，WONT，DO或DONT），它將以DONT 或WONT響應。 這些命令都是3或4個字節(jié)的大寫ASCII字符，其中一些帶選項參數。從客戶向服務器發(fā)送 的FTP命令超過30種。圖27-2給出了一些常用命令，其中大部分將在本章再次遇到。 圖27-2 常用的FTP命令 下節(jié)我們將通過一些例子看到，在用戶交互類型和控制連接上傳送的 FTP命令之間有時是 一對一的。但也有些操作下，一個用戶命令產生控制連接上多個 FTP命令。 命 令 說明 ABORLIST filelistPASS passwordPORT n1,n2,n3,n4,n5,n6 QUITRET

11、R filename STOR filename SYSTTYPE typeUSER username放棄先前的FTP命令和數據傳輸列表顯示文件或目錄 服務器上的口令 客戶端IP地址（n1.n2.n3.n4）和端口（ n5256+n6） 從服務器注銷 檢索（?。┮粋€文件存儲（放）一個文件服務器返回系統(tǒng)類型 說明文件類型： A表示ASCII碼，I表示圖像服務器上用戶名 第27章 FTP：文件傳送協(xié)議319 下載27.2.3 FTP應答 應答都是ASCII碼形式的3位數字，并跟有報文選項。其原因是軟件系統(tǒng)需要根據數字代碼來決定如何應答，而選項串是面向人工處理的。由于客戶通常都要輸出數字應答和報文串

12、，一個可交互的用戶可以通過閱讀報文串（而不必記憶所有數字回答代碼的含義）來確定應答的含義。應答3位碼中每一位數字都有不同的含義（我們將在第 28章看到簡單郵件傳送輸協(xié)議，SMTP，使用相同的命令和應答約定）。 圖27-3給出了應答代碼第1位和第2位的含義。 圖27-3 應答代碼3位數字中第1位和第2位的含義 第3位數字給出差錯報文的附加含義。例如，這里是一些典型的應答，都帶有一個可能的 報文串。 125200214331425452500501502數據連接已經打開；傳輸開始。就緒命令。 幫助報文（面向用戶）。 用戶名就緒，要求輸入口令。不能打開數據連接。 錯寫文件。 語法錯誤（未認可的命令）

13、。語法錯誤（無效參數）。 未實現的MODE(方式命令)類型。 通常每個FTP命令都產生一行回答。例如， QUIT命令可以產生如下應答： 221 Goodbye.如果需要產生一條多行應答，第1行在3位數字應答代碼之后包含一個連字號，而不是空格， 最后一行包含相同的3位數字應答代碼，后跟一個空格符。例如，HELP命令可以產生如下應答： 應答 說明 1yz 2yz 3yz 4yz5yz肯定預備應答。它僅僅是在發(fā)送另一個命令前期待另一個應答時啟動肯定完成應答。一個新命令可以發(fā)送 肯定中介應答。該命令已被接受，但另一個命令必須被發(fā)送 暫態(tài)完成應答。請求的動作沒有發(fā)生，但差錯狀態(tài)是暫時的，所以命令可以過后

14、再發(fā) 永久性完成應答。命令不被接受，并且不再重試 x0z x1z x2z x3z x4z x5z語法錯誤信息 連接。應答指控制或數據連接 鑒別和記帳。應答用于注冊或記帳命令未指明 文件系統(tǒng)狀態(tài) 320TCP/IP詳解，卷1：協(xié)議 下載27.2.4 連接管理 數據連接有以下三大用途： 1) 從客戶向服務器發(fā)送一個文件。 2) 從服務器向客戶發(fā)送一個文件。 3) 從服務器向客戶發(fā)送文件或目錄列表。 FTP服務器把文件列表從數據連接上發(fā)回，而不是控制連接上的多行應答。這就避免了行的有限性對目錄大小的限制，而且更易于客戶將目錄列表以文件形式保存，而不是把列表顯示在終端上。 我們已說過，控制連接一直保持

15、到客戶-服務器連接的全過程，但數據連接可以根據需要隨時來，隨時走。那么需要怎樣為數據連接選端，以及誰來負責主動打開和被動打開？ 首先，我們前面說過通用傳輸方式（ Unix環(huán)境下唯一的傳輸方式）是流方式，并且文件結尾是以關閉數據連接為標志。這意味著對每一個文件傳輸或目錄列表來說都要建立一個全新的數據連接。其一般過程如下： 1) 正由于是客戶發(fā)出命令要求建立數據連接，所以數據連接是在客戶的控制下建立的。 2) 客戶通常在客戶端主機上為所在數據連接端選擇一個臨時端一個被動的打開。 ?？蛻魪脑摱丝诎l(fā)布3) 客戶使用PORT命令從控制連接上把端發(fā)向服務器。 4) 服務器在控制連接上接收端 ，并向客戶端主

16、機上的端口發(fā)布一個主動的打開。服務器的數據連接端一直使用端口 20。 圖27-4給出了第3步執(zhí)行時的連接狀態(tài)。假設客戶用于控制連接的臨時端口是 1173，客戶用于數據連接的臨時端口是 1174?？蛻舭l(fā)出的命令是PORT命令，其參數是6個ASCII中的十進制數字，它們之間由逗點隔開。前面 4個數字指明客戶上的IP地址，服務器將向它發(fā)出主動打開（本例中是4），而后兩位指明16 bit端口地址。由于16 bit端口地址是從這兩個數字中得來，所以其值在本例中就是 4256+150 = 1174。 圖27-5給出了服務器向客戶所在數據連接端發(fā)布主動打開時的連接狀態(tài)。服務器的端點

17、是端口20。 FTP客戶 FTP服務器控制連接端口1173端口1174(被動打開) IP地址 圖27-4端口21在FTP控制連接上通過的PORT命令 FTP服務器控制連接 端口21FTP客戶端口1173 SYN到4, 端口1174端口20(主動打開)端口1174(被動打開) IP地址4圖27-5 主動打開數據連接的FTP服務器 第27章 FTP：文件傳送協(xié)議321 下載服務器總是執(zhí)行數據連接的主動打開。通常服務器也執(zhí)行數據連接的主動關閉，除非當客戶也有可能不發(fā)出PORT命令，而由服務器向正被客戶使用的同一個端發(fā)出主動打開，來結束控制連接。這是可行

18、的，因為服務器面向這兩個連接的端是不同的：一個是20，另一個是21。不過，下節(jié)我們將看到為什么現有實現通常不這樣做。 27.3 FTP的例子 現在看一些使用FTP的例子：它對數據連接的管理，采用NVT ASCII碼的文本文件如何發(fā)送，FTP使用Telnet同步信號來中止進行中的文件傳輸，最后是常用的“ FTP”。 27.3.1 連接管理：臨時數據端口 先看一下FTP的連接管理，它只在服務器上用簡單 FTP會話顯示一個文件。我們用- d標志 （debug）來運行svr4主機上的客戶。這告訴它要打印控制連接上變換的命令和應答。所有前面冠以-的行是從客戶上發(fā)向服務器的，所有以 3位數字開頭的行都是服

19、務器的應答?？蛻舻慕换ヌ崾臼莊tp。 svr4 % ftp -d bsdiConnected to bsdi.-d 選項用作排錯輸出 客戶執(zhí)行控制連接的主動打開 220 bsdi FTP server (Version 5.60) ready 服務器響應就緒 Name (bsdi:rstevens):- USER rstevens331 Password required for rstevens. Password:- PASS XXXXXXXX230 User rstevens logged in. ftpdir hello.c- PORT 140,252,13,34,4,150200 P

20、ORT Command successful.- LIST hello.c客戶提示我們輸入 鍵入RETURN，客戶發(fā)送默認信息 鍵入口令；它不需要回顯客戶以明文發(fā)送它要求列出一個文件的目錄見圖27-4150 Opening ASCII mode dataconnectionfor /bin/ls.17 12 :47 hello. c- rw- r- r- 1 rstevensstaff38 Jul226 Transfer complete. remote: hello.c56 bytes received in 0.03 seconds (1.8 ftpquit- QUIT221 Goodby

21、e客戶輸出Kbytes/s)我們已完成 當FTP客戶提示我們注冊姓名時，它打印了默認值（我們在客戶上的注冊名）。當我們敲 RETURN鍵時，默認值被發(fā)送出去。 對一個文件列出目錄的要求引發(fā)一個數據連接的建立和使用。本例體現了我們在圖 27-4和圖27-5中給出的程序?？蛻粢骉CP為其數據連接的終端提供一個臨時端，并用 PORT命令發(fā)送這個端（ 1174）給服務器。我們也看到一個交互用戶命令（ dir）成為兩個FTP命令（PORT和LIST）。 322TCP/IP詳解，卷1：協(xié)議 下載圖27-6是控制連接上分組交換的時間系列（已除去了控制連接的建立和結束，以及所有窗口大小）。我們關注該圖中數據

22、連接在哪兒開、使用和過后的關閉。 圖27-7是數據連接的時間系列。圖中的起始時間與圖 27-6中的相同。已除去了所有窗口大，但留下服務類型字段，以說明數據連接使用另一個服務類型（最大吞吐量），而不同小于控制連接（最小時延）（服務類型(TOS)值在圖3-2中）。 在時間系列上， FTP服務器執(zhí)行數據連接的主動打開，從端口 20（稱為ftp-data）到來自PORT命令的端（ 1174）。本例中還可以看到服務器在哪兒向數據連接上執(zhí)行寫操作，服務器對數據連接執(zhí)行主動的關閉，這就告訴客戶列表已完成。 鍵入 鍵入口令鍵入打開數據連接使用數據連接，然后關閉鍵入圖27-6 FTP控制連接示例 第27章 FT

23、P：文件傳送協(xié)議323 下載主動打開主動關閉圖27-7 FTP數據連接示例 27.3.2 連接管理：默認數據端口 如果客戶沒有向服務器發(fā)出PORT命令，來指明客戶數據連接端的端，服務器就用與控制連接正在用的相同的端給數據連接。這會給使用流方式（ Unix FTP客戶和服務器一直使用）的客戶帶來一些問題。正如下面所示： Host Requirements RFC建議使用流方式的FTP客戶在每次使用數據連接前發(fā)一個PORT命令來啟用一個非默認的端。 回到先前的例子（圖27-6），如果我們要求在列出第 1個目錄后幾秒鐘再列出另一個目錄，那該怎么辦？客戶將要求其內核選擇另一個臨時端（可能是 1175）

24、，下一個數據連接將建立在svr4端口1175和bsdi端口20之間。但在圖27-7中服務器執(zhí)行數據連接的主動打開，我們在18.6節(jié)說明了服務器將不把端口 20分配給新的數據連接，這是因為本地端接使用，而且還處于2MSL等待狀態(tài)。 已被更早的連服務器通過指明我們在18.6節(jié)中提到的SO_REUSEADDR選項，來解決這個問題。這讓它把端口20分配給新連接，而新連接將從處于 2MSL等待狀態(tài)的端口（ 1174）處得到一個不一樣的外部端（ 1175），這樣一切都解決了。 如果客戶不發(fā)送PORT命令，而在客戶上指明一個臨時端，那么情況將改變。我們可以通過執(zhí)行用戶命令sendport給FTP來使之發(fā)生。

25、Unix FTP客戶用這個命令在每個數據連接使用之前關閉向服務器發(fā)送PORT命令。 圖27-8給出了用于兩個連續(xù)LIST命令的數據連接時間系列?？刂七B接起自主機 svr4上的端口1176，所以在沒有PORT命令的情況下，客戶和服務器給數據連接使用相同的端了窗口和服務類型值）。 序列如下： 1) 控制連接是建立在客戶端口1176到服務器端口21上的（這里我們不展示）。 （除去 324TCP/IP詳解，卷1：協(xié)議 下載主動打開(第1個LIST命令的輸出)主動關閉(所有要打開從bsdi.ftp-data到svr4.1176的TCP連接的嘗試在這里都失敗了)主動打開(第2個LIST命令的輸出)主動關閉

26、圖27-8 兩個連續(xù)LIST命令的數據連接 2) 當客戶為端口1176上的數據連接做被動打開時，由于該端口已被客戶上的控制連接使用，所以必須確定SO_REUSEADDR選項。 3) 服務器給端口20到端口1176的數據連接（報文段1）做主動打開。即便端口1176已在客戶上被使用，客戶仍會接受它（報文段 2），這是因為下面這一對插口是不同的： （在bsdi上的端是不同的）。TCP通過查看源IP地址、源端、目的 IP地址、目的端分用各呼入報文段，只要這 4個元素中的一個不同，就行。 4) 服務器對數據連接（報文段 5）做主動的關閉，即把這對插口置入服務器上的一個2MSL等待。 5) 客戶在控制連接

27、上發(fā)送另一個 LIST命令（這里我們不展示）。在此之前，客戶在端口1176上為其數據連接端做一個被動打開?？蛻舯仨氃僖淮沃该?SO_REUSEADDR，這是因為端1176已在使用。 第27章 FTP：文件傳送協(xié)議325 下載6) 服務器給從端口20到端口1176的數據連接發(fā)出一個主動打開。在此之前，服務器必須指明SO_REUSEADDR，這是因為本地端口（20）與處于2MSL等待狀態(tài)的連接是相關聯的， 但從18.6節(jié)所示可知，該連接將不成功。其原由是這個連接用插口對(socket pair)與步驟4 中的仍處于2MSL等待狀態(tài)的插口對相同。TCP規(guī)定禁止服務器發(fā)送同步信息（ SYN）。 這樣就

28、沒辦法讓服務器跨過插口對的2MSL等待狀態(tài)來重用相同的插口對。 在這一步伯克利軟件分發(fā)（BSD）服務器每隔5秒就重試一次連接請求，直到滿18次，總共90秒。我們看到報文段9將在大約1分鐘后成功（我們在第18章提到過，SVR4使用一個30秒的MSL，以兩個MSL來達到持續(xù)1分鐘的等待）。我們沒看到在這個時間系列上的這些失敗有任何同步（SYN）信息，這是因為主動打開失敗，服務器的TCP不再發(fā)送一個SYN。 Host Requirements RFC建議使用PORT命令的原因是在兩個相繼使用數據連接之間避免出 現這個2MSL。通過不停地改變某一端的端，我們所說的這個問題就不會出現。 27.3.3 文

29、本文件傳輸：NVT ASCII表示還是圖像表示 讓我們查證一下默認的文本文件傳輸使用 NVT ASCII碼。這次不指定-d標志，所以不看客戶命令，但注意到客戶還將打印服務器的響應： sun % ftp bsdiConnected to bsdi.220 bsdi FTP server (Version 5.60) ready.Name (bsdi:retevens);331 Password required for rstevens. Passord :230 User rstevens loggedin.ftp get hello.c鍵入RETURN鍵入口令取一個文件200150226PO

30、RT command successful.Opening ASCII mode data connection for hello.c (38 bytes).Transfer complete.服務器說明文件含有38字節(jié)由客戶輸出 字節(jié)傳過4數2據連接local: hello. c remote: hello. c42 bytes received in 0 . 0037 ftp quit221 Goodbye.seconds(11 Kbytes/ s)Sun % ls -l- rw- rw- r- sun % wc -l4 hello.chello.c1 rstevenshello.c38

31、 Jul1808 : 48 hello .但c 文件還含有38字節(jié)在文件中記行數 因為文件有4行，所以從數據連接上傳輸42個字節(jié)。Unix下的每一新行符（n）被服務器轉換成NVT ASCII碼的2字節(jié)行結尾序列（ rn）來傳輸，然后再由客戶轉換成原先形式來存儲。 新客戶試圖確定服務器是否是相同類型的系統(tǒng)，一旦相同，就可以用二進制碼（圖像文件類型）來傳輸文件，而不是ASCII碼。這可以獲得兩個方面的好處： 1) 發(fā)方和收方不必查看每一字節(jié)（很大的節(jié)約）。 2) 如果主機操作系統(tǒng)使用比2字節(jié)的NVT ASCII碼序列更少的字節(jié)來作行尾，就會傳輸更少的字節(jié)數（很小的節(jié)約）。 我們可以看到使用一個BS

32、D/386客戶和服務器的最優(yōu)效果。啟動排錯（ debug）方式來看 326TCP/IP詳解，卷1：協(xié)議 客戶FTP命令： 下載bsdi & ftp -d slipConnected to slip.220 slip FTP server (Version 5.60) ready. Name (slip:rstevens):- USER rstevns指明 -d來看客戶命令 我們鍵入RETURN331 Password required Password :- PASS XXXXfor rstevens.我們鍵入自己的口令230 User rstevns logged in .- SYST215

33、 UNIX Type: L8 Version : BSD- 199103 Remote system type isUNIX.這由客戶服務器的應答自動發(fā)送 由客戶發(fā)出的信息由客戶發(fā)出的信息取一個文件 由客戶自動發(fā)送 Using binary mode ftp get hello.c- TYPE I200 Type set to I.totransferfiles.- PORT140,252, 13 ,66,4,84 端=4256+84=1108200 PORT command successful.- RETR hello.c150 Opening BINARY mode data conne

34、ction226 Transefer complete .38 bytes received in 0.035 seconds (1.1 ftpquit- QUIT221 Goodbye.for hello. c (38 bytes) .Kbytes /這s )時只有38個字節(jié)注冊到服務器后，客戶FTP自動發(fā)出SYST命令，服務器將用自己的系統(tǒng)類型來響應。如果應答起自字符串“ 215 UNIX Type : L8”，并且如果客戶在每字節(jié)為8 bit的Unix系統(tǒng)上運行，那么二進制方式（圖像）將被所有文件傳輸所使用，除非被用戶改變。 當我們取文件hello.c時，客戶自動發(fā)出命令 TYPE I把

35、文件類型定成圖像。這樣在數據連接上只有38字節(jié)被傳輸。 Host Requirements RFC指出一個FTP服務器必須支持SYST命令（這曾是RFC 959中的一個選項）。但支持它的使用文本的系統(tǒng)（見封 2）僅僅是BSD/386和AIX 3.2.2 。SunOS 4.1.3和Solaris 2.x 用500（不能理解的命令）來應答。SVR4采用極不大眾化的應答行為500，并關閉控制連接！ 27.3.4 異常中止一個文件的傳輸：Telnet 同步信號 現在看一下FTP客戶是怎樣異常中止一個來自服務器的文件傳輸。異常中止從客戶傳向服務器的文件很容易只要客戶停止在數據連接上發(fā)送數據，并發(fā)出 AB

36、OR命令到控制連接上的服務器即可。而異常中止接收就復雜多了，這是因為客戶要告知服務器立即停止發(fā)送數據。我們前面提到要使用Telnet同步信號，下面的例子就是這樣。 我們先發(fā)起一個接收，并在它開始后鍵入中斷鍵。這里是交互會話，其中初始注冊被略 去： 第27章 FTP：文件傳送協(xié)議327 下載ftp get a.out- TYPE I200 Type set toI.- PORT 140 , 252 , 13 , 66 , 4 , 99200 PORT commandsuccessful. - RETR a.out取一個大文件 客戶和服務器都是8 bit字節(jié)的Unix系統(tǒng) 150 Opening

37、BINARY mode data connection for a.out (28672 bytes).?receive abortedwaiting for remote to finish abort426 Transfer aborted. Data connection closed.226 Abort successful鍵入的中斷鍵由客戶輸出 由客戶輸出 1536 bytes received in 1.7 seconds (0.89 Kbytes/s)在我們鍵入中斷鍵之后，客戶立即告知我們它將發(fā)起異常中止，并正在等待服務器完成。服務器發(fā)出兩個應答： 426和226。這兩個應答都是

38、由Unix 服務器在收到來自客戶的緊急數據和ABOR命令時發(fā)出的。 圖27-9和圖27-10展示了會話時間系列。我們已把控制連接（實線）和數據連接（虛線） 合在一起來說明它們之間的關系。 打開數據連接開始傳送數據第1個數據段圖27-9 異常中止一個文件的傳輸（前半部） 圖27-9的前面12個報文段是我們所期望的。通過控制連接的命令和應答建立起文件傳輸， 數據連接開，第1個報文段的數據從服務器發(fā)往客戶。 328TCP/IP詳解，卷1：協(xié)議 下載 鍵入中斷 圖27-10異常中止一個文件的傳輸（后半部）在圖27-10中，報文段13是數據連接上來自服務器的第 6個數據報文段，后跟由我們鍵入的中斷鍵產生

39、的報文段14。客戶發(fā)出10個字節(jié)來異常中止傳輸： 由于20.8節(jié)中詳細討論過這個問題，我們看到有兩個報文段（ 14和15）涉及到TCP的緊急指針（我們在圖26-17中看過對Telnet問題也做相同的處理）。Host Requirements RFC指出緊急指針應指向緊急數據的最后一個字節(jié)，而多數伯克利的派生實現使之指向緊急數據最后一個字節(jié)后面的第一個字節(jié)。了解到緊急指針將（錯誤地）指向下一個要寫的字節(jié)（數據標志， DM。在序號為54處），FTP客戶進程特意寫前 3個字節(jié)作為緊急數據。首先寫下的 3字節(jié)緊急數據與緊急指針一起被立即發(fā)送，緊接著是后面 7個字節(jié)（ BSD FTP 服務器不會出現由客

40、戶使用的緊急指針的解釋問題。當服務器收到控制連接上的緊急數據時，它讀下一個 FTP命令， 尋找ABOR或STAT，忽略嵌入的Telnet命令）。 注意到盡管服務器指出傳輸被異常中止（報文段 18，在控制連接上），客戶進程還要在數 據連接上再接收14個報文段的數據（序列號是 15375120）。這些報文段可能在收到異常中止 關閉數據連接 數據傳送繼續(xù) 第27章 FTP：文件傳送協(xié)議329 下載時，還在服務器上的網絡設備驅動器中排隊，但客戶打印“收到 1536字節(jié)”，意思是在發(fā)出異常中止后（報文段14和15），略去收到的所有數據報文段。 一旦Telnet用戶鍵入中斷鍵，我們在圖 26-17中看到U

41、nix客戶在默認情況下不發(fā)出中斷進程命令作為緊急數據。因為幾乎沒有機會用流控制來中止從客戶進程到服務器進程的數據流， 所以我們說這樣就行了。FTP的客戶進程也通過控制連接發(fā)送一個中斷進程命令，因為兩個連接正在被使用，因此沒有機會用流控制來中止控制連接。為什么 FTP發(fā)送中斷進程命令作為緊急數據而Telnet不呢？答案在于FTP使用兩個連接，而Telnet只使用一個，在某些操作系統(tǒng)上要求一個進程同時監(jiān)控兩個連接的輸入是困難的。 FTP假設這些臨界的操作系統(tǒng)至少提供緊急 數據在控制連接上已到達，而后讓服務器從處理數據連接切換到控制連接上來。 27.3.5FTPFTP的一種形式很常用，我們下面給出它

42、的例子。它被稱為 FTP，當有服務器支持時， 允許任何人注冊并使用FTP來傳輸文件。使用這個技術可以提供大量的自由信息。 怎樣找出你正在搜尋的站點是一個完全不同的問題。我們將在 30.4節(jié)簡要介紹。 我們將把FTP用在站點上（一個常用的FTP站點）來取本書的勘誤表文件。要使用FTP，須使用“ anonymous”（復習數遍就能正確地拼寫）用戶名來注冊。當提示輸入口令時，我們鍵入自己的電子郵箱地址。 sun % ftp Connected to 220 ftp.UU.NET FTP server (Version 2.0WU(13) F

43、ri Apr 9 20:44:32 EDT 1993) ready Name ( ftp. uu. net: rsteve n sa)n:onymous331 Guest login ok, send your complete e-mail addraess as password.Password : 230-230-鍵入；它沒有回顯 Welcome to the UUNETarchive.Falls Church, Virginia 703 204 8000 , or see the230-230-230-A service of UUNET Techno

44、logies Inc, For information about UUNET, call +1in /uunet-infofiles還有一些問候行230 Guest login ok, access restrictions apply. ftp cd published/books250 CWD command successful. ftpbinary換成需要的目錄我們將傳送一個二進制文件 200 Type ftp get200 PORTset toI.stevens.tcpipivl.errata.Z command successful.取文件150 Opening BINARY m

45、ode data connection for stevens.tcpipivl.errata.Z (150 bytes).226 Transfer complete.(你可能得到一個不同的文件大小)local: stevens. tcpipivl. errata. Z remote:stevens.tcpipivl. errata.Z 105 bytes received in 4.1 seconds (0.83 Kbytes/s) ftpquit221 Goodbye.sun % uncompress stevens.tcpipivl.errata.Zsun % more stevens.tcpipivl.errata