tcpip詳解卷1協(xié)議擴(kuò)展資料tcpip詳解卷1協(xié)議27_W_第1頁(yè)
tcpip詳解卷1協(xié)議擴(kuò)展資料tcpip詳解卷1協(xié)議27_W_第2頁(yè)
tcpip詳解卷1協(xié)議擴(kuò)展資料tcpip詳解卷1協(xié)議27_W_第3頁(yè)
tcpip詳解卷1協(xié)議擴(kuò)展資料tcpip詳解卷1協(xié)議27_W_第4頁(yè)
tcpip詳解卷1協(xié)議擴(kuò)展資料tcpip詳解卷1協(xié)議27_W_第5頁(yè)
已閱讀5頁(yè),還剩11頁(yè)未讀, 繼續(xù)免費(fèi)閱讀

下載本文檔

版權(quán)說(shuō)明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請(qǐng)進(jìn)行舉報(bào)或認(rèn)領(lǐng)

文檔簡(jiǎn)介

1、 下載第27章FTP:文件傳送協(xié)議27.1引言 FTP是另一個(gè)常見的應(yīng)用程序。它是用于文件傳輸?shù)?Internet標(biāo)準(zhǔn)。我們必須分清文件傳送( file transfer )和文件存取 (file access) 之間的區(qū)別,前者是 FTP提供的,后者是如 NFS(Sun的網(wǎng)絡(luò)文件系統(tǒng),第 29章)等應(yīng)用系統(tǒng)提供的。由 FTP提供的文件傳送是將一個(gè)完整的文件從一個(gè)系統(tǒng)復(fù)制到另一個(gè)系統(tǒng)中。要使用 FTP,就需要有登錄服務(wù)器的注冊(cè)帳號(hào),或者通過(guò)允許 FTP的服務(wù)器來(lái)使用(本章我們將給出這樣的一個(gè)例子)。 與Telnet類似,F(xiàn)TP最早的設(shè)計(jì)是用于兩臺(tái)不同的主機(jī),這兩個(gè)主機(jī)可能運(yùn)行在不同的操作系統(tǒng)下

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

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

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

5、-1文件傳輸中的處理過(guò)程1. 文件類型 (a) ASCII碼文件類型 (默認(rèn)選擇)文本文件以NVT ASCII碼形式在數(shù)據(jù)連接中傳輸。這要求發(fā)方將本地文本文件轉(zhuǎn)換成NVT ASCII碼形式,而收方則將NVT ASCII碼再還原成本地文本文件。其中,用NVT ASCII碼傳輸?shù)拿啃卸紟в幸粋€(gè)回車,而后是一個(gè)換行。這意味著收方必須掃描每個(gè)字節(jié),查找CR、LF對(duì)(我們?cè)诘?5.2節(jié)見過(guò)的關(guān)于TFIP的ASCII碼文件傳輸情況與此相同)。 (b) EBCDIC文件類型 該文本文件傳輸方式要求兩端都是EBCDIC系統(tǒng)。 (c) 圖像文件類型(也稱為二進(jìn)制文件類型) 用于傳輸二進(jìn)制文件。 (d) 本地文件

6、類型 該方式在具有不同字節(jié)大小的主機(jī)間傳輸二進(jìn)制文件。每一字節(jié)的比特?cái)?shù)由發(fā)方規(guī)定。對(duì)使用8 bit字節(jié)的系統(tǒng)來(lái)說(shuō),本地文件以8 bit字節(jié)傳輸就等同于圖像文件傳輸。 2. 格式控制 該選項(xiàng)只對(duì)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)為是一個(gè)連續(xù)的字節(jié)流。不存在內(nèi)部的文件結(jié)構(gòu)。(b) 記錄結(jié)構(gòu) 該結(jié)構(gòu)只用于文本文件( ASCII或EBCDIC)。

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

8、文件中常用來(lái)壓縮 0字節(jié)(這種方式很少使用,也不受支持。現(xiàn)在有一些更好的文件壓縮方法來(lái)支持FTP)。 如果算一下所有這些選擇的排列組合數(shù),那么對(duì)傳輸和存儲(chǔ)一個(gè)文件來(lái)說(shuō)就有 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)支持它才行

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

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

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

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

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

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

15、到客戶-服務(wù)器連接的全過(guò)程,但數(shù)據(jù)連接可以根據(jù)需要隨時(shí)來(lái),隨時(shí)走。那么需要怎樣為數(shù)據(jù)連接選端,以及誰(shuí)來(lái)負(fù)責(zé)主動(dòng)打開和被動(dòng)打開? 首先,我們前面說(shuō)過(guò)通用傳輸方式( Unix環(huán)境下唯一的傳輸方式)是流方式,并且文件結(jié)尾是以關(guān)閉數(shù)據(jù)連接為標(biāo)志。這意味著對(duì)每一個(gè)文件傳輸或目錄列表來(lái)說(shuō)都要建立一個(gè)全新的數(shù)據(jù)連接。其一般過(guò)程如下: 1) 正由于是客戶發(fā)出命令要求建立數(shù)據(jù)連接,所以數(shù)據(jù)連接是在客戶的控制下建立的。 2) 客戶通常在客戶端主機(jī)上為所在數(shù)據(jù)連接端選擇一個(gè)臨時(shí)端一個(gè)被動(dòng)的打開。 。客戶從該端口發(fā)布3) 客戶使用PORT命令從控制連接上把端發(fā)向服務(wù)器。 4) 服務(wù)器在控制連接上接收端 ,并向客戶端主

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

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

18、的,因?yàn)榉?wù)器面向這兩個(gè)連接的端是不同的:一個(gè)是20,另一個(gè)是21。不過(guò),下節(jié)我們將看到為什么現(xiàn)有實(shí)現(xiàn)通常不這樣做。 27.3 FTP的例子 現(xiàn)在看一些使用FTP的例子:它對(duì)數(shù)據(jù)連接的管理,采用NVT ASCII碼的文本文件如何發(fā)送,F(xiàn)TP使用Telnet同步信號(hào)來(lái)中止進(jìn)行中的文件傳輸,最后是常用的“ FTP”。 27.3.1 連接管理:臨時(shí)數(shù)據(jù)端口 先看一下FTP的連接管理,它只在服務(wù)器上用簡(jiǎn)單 FTP會(huì)話顯示一個(gè)文件。我們用- d標(biāo)志 (debug)來(lái)運(yùn)行svr4主機(jī)上的客戶。這告訴它要打印控制連接上變換的命令和應(yīng)答。所有前面冠以-的行是從客戶上發(fā)向服務(wù)器的,所有以 3位數(shù)字開頭的行都是服

19、務(wù)器的應(yīng)答??蛻舻慕换ヌ崾臼莊tp。 svr4 % ftp -d bsdiConnected to bsdi.-d 選項(xiàng)用作排錯(cuò)輸出 客戶執(zhí)行控制連接的主動(dòng)打開 220 bsdi FTP server (Version 5.60) ready 服務(wù)器響應(yīng)就緒 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ā)送默認(rèn)信息 鍵入口令;它不需要回顯客戶以明文發(fā)送它要求列出一個(gè)文件的目錄見圖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)我們已完成 當(dāng)FTP客戶提示我們注冊(cè)姓名時(shí),它打印了默認(rèn)值(我們?cè)诳蛻羯系淖?cè)名)。當(dāng)我們敲 RETURN鍵時(shí),默認(rèn)值被發(fā)送出去。 對(duì)一個(gè)文件列出目錄的要求引發(fā)一個(gè)數(shù)據(jù)連接的建立和使用。本例體現(xiàn)了我們?cè)趫D 27-4和圖27-5中給出的程序??蛻粢骉CP為其數(shù)據(jù)連接的終端提供一個(gè)臨時(shí)端,并用 PORT命令發(fā)送這個(gè)端( 1174)給服務(wù)器。我們也看到一個(gè)交互用戶命令( dir)成為兩個(gè)FTP命令(PORT和LIST)。 322TCP/IP詳解,卷1:協(xié)議 下載圖27-6是控制連接上分組交換的時(shí)間系列(已除去了控制連接的建立和結(jié)束,以及所有窗口大小)。我們關(guān)注該圖中數(shù)據(jù)

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

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

24、,下一個(gè)數(shù)據(jù)連接將建立在svr4端口1175和bsdi端口20之間。但在圖27-7中服務(wù)器執(zhí)行數(shù)據(jù)連接的主動(dòng)打開,我們?cè)?8.6節(jié)說(shuō)明了服務(wù)器將不把端口 20分配給新的數(shù)據(jù)連接,這是因?yàn)楸镜囟私邮褂茫疫€處于2MSL等待狀態(tài)。 已被更早的連服務(wù)器通過(guò)指明我們?cè)?8.6節(jié)中提到的SO_REUSEADDR選項(xiàng),來(lái)解決這個(gè)問題。這讓它把端口20分配給新連接,而新連接將從處于 2MSL等待狀態(tài)的端口( 1174)處得到一個(gè)不一樣的外部端( 1175),這樣一切都解決了。 如果客戶不發(fā)送PORT命令,而在客戶上指明一個(gè)臨時(shí)端,那么情況將改變。我們可以通過(guò)執(zhí)行用戶命令sendport給FTP來(lái)使之發(fā)生。

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

26、圖27-8 兩個(gè)連續(xù)LIST命令的數(shù)據(jù)連接 2) 當(dāng)客戶為端口1176上的數(shù)據(jù)連接做被動(dòng)打開時(shí),由于該端口已被客戶上的控制連接使用,所以必須確定SO_REUSEADDR選項(xiàng)。 3) 服務(wù)器給端口20到端口1176的數(shù)據(jù)連接(報(bào)文段1)做主動(dòng)打開。即便端口1176已在客戶上被使用,客戶仍會(huì)接受它(報(bào)文段 2),這是因?yàn)橄旅孢@一對(duì)插口是不同的: (在bsdi上的端是不同的)。TCP通過(guò)查看源IP地址、源端、目的 IP地址、目的端分用各呼入報(bào)文段,只要這 4個(gè)元素中的一個(gè)不同,就行。 4) 服務(wù)器對(duì)數(shù)據(jù)連接(報(bào)文段 5)做主動(dòng)的關(guān)閉,即把這對(duì)插口置入服務(wù)器上的一個(gè)2MSL等待。 5) 客戶在控制連接

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

28、沒辦法讓服務(wù)器跨過(guò)插口對(duì)的2MSL等待狀態(tài)來(lái)重用相同的插口對(duì)。 在這一步伯克利軟件分發(fā)(BSD)服務(wù)器每隔5秒就重試一次連接請(qǐng)求,直到滿18次,總共90秒。我們看到報(bào)文段9將在大約1分鐘后成功(我們?cè)诘?8章提到過(guò),SVR4使用一個(gè)30秒的MSL,以兩個(gè)MSL來(lái)達(dá)到持續(xù)1分鐘的等待)。我們沒看到在這個(gè)時(shí)間系列上的這些失敗有任何同步(SYN)信息,這是因?yàn)橹鲃?dòng)打開失敗,服務(wù)器的TCP不再發(fā)送一個(gè)SYN。 Host Requirements RFC建議使用PORT命令的原因是在兩個(gè)相繼使用數(shù)據(jù)連接之間避免出 現(xiàn)這個(gè)2MSL。通過(guò)不停地改變某一端的端,我們所說(shuō)的這個(gè)問題就不會(huì)出現(xiàn)。 27.3.3 文

29、本文件傳輸:NVT ASCII表示還是圖像表示 讓我們查證一下默認(rèn)的文本文件傳輸使用 NVT ASCII碼。這次不指定-d標(biāo)志,所以不看客戶命令,但注意到客戶還將打印服務(wù)器的響應(yīng): 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鍵入口令取一個(gè)文件200150226PO

30、RT command successful.Opening ASCII mode data connection for hello.c (38 bytes).Transfer complete.服務(wù)器說(shuō)明文件含有38字節(jié)由客戶輸出 字節(jié)傳過(guò)4數(shù)2據(jù)連接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é)在文件中記行數(shù) 因?yàn)槲募?行,所以從數(shù)據(jù)連接上傳輸42個(gè)字節(jié)。Unix下的每一新行符(n)被服務(wù)器轉(zhuǎn)換成NVT ASCII碼的2字節(jié)行結(jié)尾序列( rn)來(lái)傳輸,然后再由客戶轉(zhuǎn)換成原先形式來(lái)存儲(chǔ)。 新客戶試圖確定服務(wù)器是否是相同類型的系統(tǒng),一旦相同,就可以用二進(jìn)制碼(圖像文件類型)來(lái)傳輸文件,而不是ASCII碼。這可以獲得兩個(gè)方面的好處: 1) 發(fā)方和收方不必查看每一字節(jié)(很大的節(jié)約)。 2) 如果主機(jī)操作系統(tǒng)使用比2字節(jié)的NVT ASCII碼序列更少的字節(jié)來(lái)作行尾,就會(huì)傳輸更少的字節(jié)數(shù)(很小的節(jié)約)。 我們可以看到使用一個(gè)BS

32、D/386客戶和服務(wù)器的最優(yōu)效果。啟動(dòng)排錯(cuò)( debug)方式來(lái)看 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來(lái)看客戶命令 我們鍵入RETURN331 Password required Password :- PASS XXXXfor rstevens.我們鍵入自己的口令230 User rstevns logged in .- SYST215

33、 UNIX Type: L8 Version : BSD- 199103 Remote system type isUNIX.這由客戶服務(wù)器的應(yīng)答自動(dòng)發(fā)送 由客戶發(fā)出的信息由客戶發(fā)出的信息取一個(gè)文件 由客戶自動(dòng)發(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 )時(shí)只有38個(gè)字節(jié)注冊(cè)到服務(wù)器后,客戶FTP自動(dòng)發(fā)出SYST命令,服務(wù)器將用自己的系統(tǒng)類型來(lái)響應(yīng)。如果應(yīng)答起自字符串“ 215 UNIX Type : L8”,并且如果客戶在每字節(jié)為8 bit的Unix系統(tǒng)上運(yùn)行,那么二進(jìn)制方式(圖像)將被所有文件傳輸所使用,除非被用戶改變。 當(dāng)我們?nèi)∥募ello.c時(shí),客戶自動(dòng)發(fā)出命令 TYPE I把

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

36、OR命令到控制連接上的服務(wù)器即可。而異常中止接收就復(fù)雜多了,這是因?yàn)榭蛻粢嬷?wù)器立即停止發(fā)送數(shù)據(jù)。我們前面提到要使用Telnet同步信號(hào),下面的例子就是這樣。 我們先發(fā)起一個(gè)接收,并在它開始后鍵入中斷鍵。這里是交互會(huì)話,其中初始注冊(cè)被略 去: 第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取一個(gè)大文件 客戶和服務(wù)器都是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ā)起異常中止,并正在等待服務(wù)器完成。服務(wù)器發(fā)出兩個(gè)應(yīng)答: 426和226。這兩個(gè)應(yīng)答都是

38、由Unix 服務(wù)器在收到來(lái)自客戶的緊急數(shù)據(jù)和ABOR命令時(shí)發(fā)出的。 圖27-9和圖27-10展示了會(huì)話時(shí)間系列。我們已把控制連接(實(shí)線)和數(shù)據(jù)連接(虛線) 合在一起來(lái)說(shuō)明它們之間的關(guān)系。 打開數(shù)據(jù)連接開始傳送數(shù)據(jù)第1個(gè)數(shù)據(jù)段圖27-9 異常中止一個(gè)文件的傳輸(前半部) 圖27-9的前面12個(gè)報(bào)文段是我們所期望的。通過(guò)控制連接的命令和應(yīng)答建立起文件傳輸, 數(shù)據(jù)連接開,第1個(gè)報(bào)文段的數(shù)據(jù)從服務(wù)器發(fā)往客戶。 328TCP/IP詳解,卷1:協(xié)議 下載 鍵入中斷 圖27-10異常中止一個(gè)文件的傳輸(后半部)在圖27-10中,報(bào)文段13是數(shù)據(jù)連接上來(lái)自服務(wù)器的第 6個(gè)數(shù)據(jù)報(bào)文段,后跟由我們鍵入的中斷鍵產(chǎn)生

39、的報(bào)文段14??蛻舭l(fā)出10個(gè)字節(jié)來(lái)異常中止傳輸: 由于20.8節(jié)中詳細(xì)討論過(guò)這個(gè)問題,我們看到有兩個(gè)報(bào)文段( 14和15)涉及到TCP的緊急指針(我們?cè)趫D26-17中看過(guò)對(duì)Telnet問題也做相同的處理)。Host Requirements RFC指出緊急指針應(yīng)指向緊急數(shù)據(jù)的最后一個(gè)字節(jié),而多數(shù)伯克利的派生實(shí)現(xiàn)使之指向緊急數(shù)據(jù)最后一個(gè)字節(jié)后面的第一個(gè)字節(jié)。了解到緊急指針將(錯(cuò)誤地)指向下一個(gè)要寫的字節(jié)(數(shù)據(jù)標(biāo)志, DM。在序號(hào)為54處),F(xiàn)TP客戶進(jìn)程特意寫前 3個(gè)字節(jié)作為緊急數(shù)據(jù)。首先寫下的 3字節(jié)緊急數(shù)據(jù)與緊急指針一起被立即發(fā)送,緊接著是后面 7個(gè)字節(jié)( BSD FTP 服務(wù)器不會(huì)出現(xiàn)由客

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

41、nix客戶在默認(rèn)情況下不發(fā)出中斷進(jìn)程命令作為緊急數(shù)據(jù)。因?yàn)閹缀鯖]有機(jī)會(huì)用流控制來(lái)中止從客戶進(jìn)程到服務(wù)器進(jìn)程的數(shù)據(jù)流, 所以我們說(shuō)這樣就行了。FTP的客戶進(jìn)程也通過(guò)控制連接發(fā)送一個(gè)中斷進(jìn)程命令,因?yàn)閮蓚€(gè)連接正在被使用,因此沒有機(jī)會(huì)用流控制來(lái)中止控制連接。為什么 FTP發(fā)送中斷進(jìn)程命令作為緊急數(shù)據(jù)而Telnet不呢?答案在于FTP使用兩個(gè)連接,而Telnet只使用一個(gè),在某些操作系統(tǒng)上要求一個(gè)進(jìn)程同時(shí)監(jiān)控兩個(gè)連接的輸入是困難的。 FTP假設(shè)這些臨界的操作系統(tǒng)至少提供緊急 數(shù)據(jù)在控制連接上已到達(dá),而后讓服務(wù)器從處理數(shù)據(jù)連接切換到控制連接上來(lái)。 27.3.5FTPFTP的一種形式很常用,我們下面給出它

42、的例子。它被稱為 FTP,當(dāng)有服務(wù)器支持時(shí), 允許任何人注冊(cè)并使用FTP來(lái)傳輸文件。使用這個(gè)技術(shù)可以提供大量的自由信息。 怎樣找出你正在搜尋的站點(diǎn)是一個(gè)完全不同的問題。我們將在 30.4節(jié)簡(jiǎn)要介紹。 我們將把FTP用在站點(diǎn)上(一個(gè)常用的FTP站點(diǎn))來(lái)取本書的勘誤表文件。要使用FTP,須使用“ anonymous”(復(fù)習(xí)數(shù)遍就能正確地拼寫)用戶名來(lái)注冊(cè)。當(dāng)提示輸入口令時(shí),我們鍵入自己的電子郵箱地址。 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換成需要的目錄我們將傳送一個(gè)二進(jìn)制文件 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.(你可能得到一個(gè)不同的文件大小)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

溫馨提示

  • 1. 本站所有資源如無(wú)特殊說(shuō)明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請(qǐng)下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請(qǐng)聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁(yè)內(nèi)容里面會(huì)有圖紙預(yù)覽,若沒有圖紙預(yù)覽就沒有圖紙。
  • 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫(kù)網(wǎng)僅提供信息存儲(chǔ)空間,僅對(duì)用戶上傳內(nèi)容的表現(xiàn)方式做保護(hù)處理,對(duì)用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對(duì)任何下載內(nèi)容負(fù)責(zé)。
  • 6. 下載文件中如有侵權(quán)或不適當(dāng)內(nèi)容,請(qǐng)與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準(zhǔn)確性、安全性和完整性, 同時(shí)也不承擔(dān)用戶因使用這些下載資源對(duì)自己和他人造成任何形式的傷害或損失。

評(píng)論

0/150

提交評(píng)論