流模式下FTP文件傳輸效率分析及改進(jìn)

張欣艷

（江西財(cái)經(jīng)大學(xué)網(wǎng)絡(luò)信息管理中心，南昌330013）

0 引 言

文件傳輸協(xié)議（File Transfer Protocol，F(xiàn)TP）可通過計(jì)算機(jī)網(wǎng)絡(luò)進(jìn)行計(jì)算機(jī)系統(tǒng)之間的文件傳送?；贔TP協(xié)議進(jìn)行的網(wǎng)絡(luò)文件傳輸服務(wù)簡稱FTP服務(wù)。目前網(wǎng)絡(luò)上大量共享資源的發(fā)布仍然基于FTP服務(wù)實(shí)現(xiàn)。企事業(yè)單位內(nèi)部也常利用FTP服務(wù)來完成文件的備份或共享。FTP會話中用于文件傳輸?shù)臄?shù)據(jù)連接與用于交互的控制連接獨(dú)立，需要傳送文件時，通常每個文件的傳送都要經(jīng)歷一次數(shù)據(jù)連接的建立、使用和釋放過程，這種工作機(jī)制在特定場景下會帶來效率問題。本文將分析這種特定場景及其效率低下的原因，并著重提出一種新的FTP文件傳輸模式來解決這一問題。

1 FTP服務(wù)實(shí)現(xiàn)基本原理

在TCP／IP協(xié)議族中，F(xiàn)TP是應(yīng)用層協(xié)議之一。FTP協(xié)議最早提出是在RFC 114文檔中，現(xiàn)行標(biāo)準(zhǔn)是基于1985年的RFC 959［1］。FTP設(shè)計(jì)的目標(biāo)是：在同構(gòu)或異構(gòu)遠(yuǎn)程計(jì)算機(jī)系統(tǒng)之間提供非直接、可靠的透明傳輸服務(wù)，以促進(jìn)資源共享。如圖1所示，F(xiàn)TP是基于客戶端／服務(wù)端架構(gòu)（簡稱C／S模型）設(shè)計(jì)?？蛻舳伺c服務(wù)端之間需要2種通信鏈路來組建相應(yīng)的服務(wù)，即：控制連接與數(shù)據(jù)連接。其中，控制連接用于傳輸客戶端發(fā)送的用戶信息、控制命令及服務(wù)器反饋的應(yīng)答等交互信息。數(shù)據(jù)連接用于傳輸數(shù)據(jù)，即主要針對客戶端與服務(wù)端之間的目錄信息及文件數(shù)據(jù)的傳輸。為了保證數(shù)據(jù)傳輸?shù)目煽啃?，控制連接和數(shù)據(jù)連接都是基于TCP協(xié)議實(shí)現(xiàn)。

圖1 FTP使用模型Fig.1 FTP usage model

客戶端與服務(wù)端的一次會話是從建立一條控制連接開始，并伴隨該條控制連接的釋放而結(jié)束。FTP服務(wù)開始時，雙方首先要建立控制連接，控制連接在整個會話期間都保持打開，此后在控制連接上就是雙方彼此間的交互，并以命令請求與應(yīng)答方式完成登錄、目錄管理、文件管理、文件上傳（客戶端向服務(wù)端傳輸文件）或下載（服務(wù)端向客戶端傳輸文件）等各種操作。會話期間有目錄信息或文件傳輸需要時，雙方才建立數(shù)據(jù)鏈路，進(jìn)行指定內(nèi)容的傳輸。根據(jù)數(shù)據(jù)鏈路的建立方式，F(xiàn)TP服務(wù)的工作模式可分為主動方式和被動方式。這2種方式的主要區(qū)別在于數(shù)據(jù)連接建立過程中，主動發(fā)起一方是哪一端。主動方式下由服務(wù)端先向客戶端指定端口發(fā)起相應(yīng)的連接建立過程，而被動方式下由客戶端先向服務(wù)端指定端口發(fā)起數(shù)據(jù)連接的建立過程。

2 FTP協(xié)議傳輸效率分析

在文件傳輸模式上，F(xiàn)TP標(biāo)準(zhǔn)提出了流模式、塊模式及壓縮模式三種。簡言之，第一種實(shí)現(xiàn)簡單，后兩種較為復(fù)雜。目前所有FTP實(shí)現(xiàn)都支持流模式，對其余2種模式則幾乎都未給予支持。流模式下數(shù)據(jù)連接按需創(chuàng)建，用完釋放，連接釋放即表示文件傳輸結(jié)束?？蛻舳撕头?wù)端在一次會話期間每當(dāng)需要傳輸一個文件時，雙方將啟動3次握手過程建立新的數(shù)據(jù)連接，之后才轉(zhuǎn)入數(shù)據(jù)傳輸，而數(shù)據(jù)傳輸后通過釋放連接就表示文件傳輸結(jié)束［2-3］。研究可知，在流模式和主動方式下從服務(wù)端下載一份文件時的協(xié)議工作流程詳見圖2。當(dāng)有多個文件需要傳輸時，就需要不斷重復(fù)該流程，每個文件重復(fù)一次。

圖2 流模式下的一次數(shù)據(jù)傳輸過程Fig.2 A data transfer process in streaming mode

設(shè)每次傳輸?shù)奈募笮∑骄鶠閍字節(jié)、攜帶命令消息的報文平均大小為b字節(jié)。在網(wǎng)絡(luò)無差錯時，TCP連接傳輸a字節(jié)大小的文件可視為整體一次性發(fā)出、一次性接收、一次性確認(rèn)，所以一個文件數(shù)據(jù)的平均傳輸時間的計(jì)算可使用如下公式：

同樣道理，在TCP連接下發(fā)送一條命令或命令響應(yīng)消息的平均傳輸時間的計(jì)算可使用如下公式：

一般地，當(dāng)網(wǎng)絡(luò)穩(wěn)定時，RTT值穩(wěn)定不變。

由圖2可知，一次文件傳輸過程包含了依序進(jìn)行的13條命令或響應(yīng)消息的傳輸（稱為協(xié)議處理部分）和文件本身數(shù)據(jù)的一次傳輸（稱為數(shù)據(jù)傳輸部分）。這里，把鏈路利用率u定義為數(shù)據(jù)傳輸部分所用時間在一次文件傳輸過程中的占比，即流模式下u的計(jì)算可參考如下公式：

其中，d1，d2的計(jì)算見式（2）、式（3）。

為了能直觀刻畫參數(shù)u與a之間的關(guān)系，需先確定公式（4）中其它參數(shù)取值。用ping命令分別測試了3種典型網(wǎng)絡(luò)場景下的RTT值，對此闡述如下。

（1）單位校園網(wǎng)內(nèi)部計(jì)算機(jī)之間的RTT＝1 ms。

（2）單位內(nèi)部計(jì)算機(jī)與百度門戶網(wǎng)站（www.baidu.com）之間的RTT＝36 ms。

女秘書將劉麗芳領(lǐng)進(jìn)彭偉民辦公室，轉(zhuǎn)身就出去了，出去時輕輕帶上了門。彭偉民只瞟了劉麗芳一眼，目光迅速抽回電腦網(wǎng)頁，態(tài)度十分冷淡。

（3）單位內(nèi)部計(jì)算機(jī)與國外斯坦福大學(xué)官方網(wǎng)站之間的RTT＝239 ms。

通過抓包軟件分析可得，一般FTP命令及響應(yīng)消息的報文平均大小為80字節(jié)，不妨固定下來，選取b＝80字節(jié)；目前，國內(nèi)計(jì)算機(jī)網(wǎng)絡(luò)端口已普及到百兆速率，根據(jù)實(shí)際線路狀況可取典型值e＝70 Mbps。根據(jù)以上參數(shù)值，就可繪出u隨文件大小a的變化曲線，具體如圖3所示。

由圖3可知，在近距離（RTT＝1 ms）場景下，傳輸較小文件（例如超過64 KB）時，傳輸所用時間的實(shí)際利用率不超過40%，也就是60%的時間用于傳輸協(xié)議本身的開銷；一般場景（RTT＝36 ms）下，即使是傳輸常見大小文件（例如4 MB大?。?，F(xiàn)TP鏈路利用效率也僅在50%左右；如果是長遠(yuǎn)距離場景或網(wǎng)絡(luò)擁擠時，隨著RTT值急劇增大（例如RTT＝239 ms），即使傳輸較大文件（例如64 M），鏈路利用效率也僅為70%左右。綜上3種場景下的對比分析結(jié)果表明，流傳輸模式下傳輸多個文件時線路利用效率與文件大小成正比，與RTT成反比。由此即可推出，F(xiàn)TP流模式在一次會話中，批量傳輸多個中小文件時效率將非常低下，隨著未來傳輸帶寬的提高，這一問題也將變得更為突出。

圖3 鏈路利用率與文件大小及RTT的關(guān)系Fig.3 Link utilization versus file size and RTT

3 基于打包的文件傳輸模式

目前，已有FTP實(shí)現(xiàn)已在致力于如何提高客戶計(jì)算機(jī)與服務(wù)端計(jì)算機(jī)之間的總吞吐速率，常用方法有2種，即：通過并發(fā)連接進(jìn)行并行傳輸［4］；在數(shù)據(jù)連接上實(shí)時解壓縮數(shù)據(jù)［5］。這些方法卻仍未能解決前文提出的一次會話期間批量傳輸多個文件時鏈路利用率低下的問題。

要提高一次會話中客戶端和服務(wù)端之間的鏈路利用效率，可嘗試在同一條數(shù)據(jù)連接上持續(xù)傳輸多個文件，以節(jié)約協(xié)議處理部分所占用的時間。RFC 959中特別指出：塊模式或壓縮模式應(yīng)通過專門的結(jié)束標(biāo)識符通知接收方，此次文件傳輸結(jié)束，而不需要立即結(jié)束當(dāng)前連接，從而可以做到數(shù)據(jù)連接的重復(fù)利用。但目前已有的FTP實(shí)現(xiàn)中尚未發(fā)現(xiàn)利用同一數(shù)據(jù)連接傳輸不同文件的應(yīng)用實(shí)例。

針對客戶端和服務(wù)端會話期間批量傳輸文件的需求，本文提出基于打包的文件傳輸模式，如圖4所示。打包文件傳輸模式在系統(tǒng)中增加了2個命令，分別是：批量上傳（MSTOR）和批量下載（MRETR）。無論上傳、還是下載，批量文件傳輸總是由客戶端發(fā)起。批量上傳時的處理步驟可分述如下。

（1）本地打包。將用戶指定的多個文件封裝為一個包文件，包文件大小等于原文件大小之和。

（2）向服務(wù)端傳輸包文件。

（3）服務(wù)端接收包文件并在當(dāng)前位置釋放出原有文件。

接下來，批量下載時的處理步驟可分述如下。

（1）客戶端向服務(wù)端傳送用戶要下載的所有文件信息。

（2）服務(wù)端在本地將客戶指定下載的文件封裝為一個包文件。

（3）服務(wù)端向客戶端傳輸包文件。

（4）客戶端接收包文件并在當(dāng)前位置釋放出原有文件。

圖4 基于打包的文件傳輸模式Fig.4 Packed file transfer mode

由于只會經(jīng)歷一個文件傳輸過程，批量上傳（MSTOR）命令協(xié)議處理部分的時間開銷，將與執(zhí)行一次傳統(tǒng)FTP命令STOR一致；穩(wěn)定帶寬下，包文件數(shù)據(jù)部分的傳輸時間與所有原文件數(shù)據(jù)部分傳輸時間的總和接近，故而MSTOR命令將使得多個文件傳輸僅調(diào)用了一次協(xié)議處理流程，從而提高了效率。

批量下載（MRETR）命令啟動后，客戶端首先向服務(wù)端傳輸“客戶指定了哪些文件”的信息，為此需要一次額外的數(shù)據(jù)傳輸服務(wù)，后續(xù)步驟則與批量上傳類似，也就是服務(wù)端打包—傳輸文件—用戶端解包三個步驟，協(xié)議處理流程如同執(zhí)行了一次傳統(tǒng)的FTP命令RETR，因此總體上批量下載（MRETR）命令最多需要2次協(xié)議處理時間開銷，即可完成多個文件下載任務(wù)，從而提高了效率。

4 實(shí)驗(yàn)驗(yàn)證

為了驗(yàn)證打包式批量傳輸模式的有效性，實(shí)現(xiàn)了一個面向Windows平臺的實(shí)驗(yàn)性FTP服務(wù)系統(tǒng)。系統(tǒng)由客戶端軟件和服務(wù)端軟件兩部分組成。總地來說，服務(wù)器端采用多線程并發(fā)服務(wù)架構(gòu)，基于Windows下的Socket編程技術(shù)和MFC類庫開發(fā)，具有用戶管理、服務(wù)配置、目錄操作、文件上傳與下載等基本功能?？蛻舳瞬捎肳inINET API開發(fā)，具有遠(yuǎn)程連接、文件瀏覽及選擇、上傳或下載指定文件等基本功能。

實(shí)驗(yàn)系統(tǒng)在設(shè)計(jì)時修改了FTP協(xié)議標(biāo)準(zhǔn)的文件上傳處理流程，以達(dá)到打包批量傳輸目的。當(dāng)用戶在客戶端選擇多個文件進(jìn)行上傳時，客戶端將在本地自動把所選文件打包為一個名為test.zip的zip格式包文件，向服務(wù)端傳送，服務(wù)端接收到文件test.zip后，在當(dāng)前位置進(jìn)行解包，釋放出原有文件。系統(tǒng)中打包和解包操作是通過調(diào)用開源的zip／unzip工具包及對應(yīng)類庫來實(shí)現(xiàn)的，打包操作中將壓縮級別設(shè)為0，即不壓縮僅進(jìn)行封裝，使得打包和解包用時極少。

在不同物理位置選擇了2臺主機(jī)，分別安裝客戶端和服務(wù)端軟件?？蛻舳吮镜販?zhǔn)備了大小分別為1 KB、2 KB、100 KB及1 MB的4類文件各100個，4類文件分別存放到4個不同文件夾中，作為上傳測試數(shù)據(jù)。同時選擇在深夜網(wǎng)絡(luò)負(fù)載極低的時間段進(jìn)行測試，先用ping命令測得主機(jī)之間RTT＝28 ms，然后分別進(jìn)入各文件夾，選中文件夾下所有文件向服務(wù)端事先準(zhǔn)備好的對應(yīng)文件夾進(jìn)行批量上傳操作，記錄下上傳該類所有文件總共所用時間（單位：秒），測試過程中客戶端與服務(wù)端之間帶寬約為1.78 Mbps。另外，選擇了一個標(biāo)準(zhǔn)FTP系統(tǒng)與本文實(shí)驗(yàn)系統(tǒng)進(jìn)行對比實(shí)驗(yàn)，測試結(jié)果見表1。由表1可知，與標(biāo)準(zhǔn)FTP系統(tǒng)對比，實(shí)驗(yàn)系統(tǒng)完成同樣的任務(wù)所用時間明顯減少，這表明基于打包的文件傳輸模式在實(shí)現(xiàn)批量傳輸時的高效性，而且當(dāng)文件越小時，效率提升越明顯。

表1 批量上傳服務(wù)所用時間對比Tab.1 Time comparison of bulk upload services s

5 結(jié)束語

現(xiàn)今，因特網(wǎng)上人們還在頻繁使用FTP服務(wù)或協(xié)議進(jìn)行資源的共享。本文提出的基于打包的批量文件傳輸模式，能有效減少一次FTP會話期間需要連續(xù)傳送多個文件時的總體所用時間，所以在網(wǎng)絡(luò)延遲相對發(fā)送時間比值大的場合，具有一定的應(yīng)用價值。例如，在需要傳輸大量小文件或網(wǎng)絡(luò)延遲大、帶寬高的情況下使用此方法，效果則尤其顯著。在FTP協(xié)議實(shí)際應(yīng)用開發(fā)中，研發(fā)打包傳輸模式時還可利用流技術(shù)在內(nèi)存中實(shí)現(xiàn)文件打包成流、流數(shù)據(jù)發(fā)送與接收、在內(nèi)存中將流解包為文件的管道作業(yè)方式，從而最大化節(jié)約打包和解包操作額外帶來的時間和空間消耗。