摘要:
這篇文章是建立在"Java FTP Client Libraries Reviewed"上的，是用于研究JAVA平臺上對FTP的支持。在性能方面，對大文件的傳輸結果比較相似。對于小文件傳輸測試，EnterpriseDT's edtFTPj, Calvin Tai's FtpBean,和Glub Tech's Secure FTP Bean是最好的選擇，然而SUN的JDK需要解決下載數不能超過200個文件的BUG.
正如我以前在JavaWorld上發表的文章Java FTP Client Libraries Reviewed中討論的一樣（2003年4月），JDK對FTP的支持并不完全的符合FTP規范。（FTP規范了959條項目）比如JDK不允許在服務器端創建文件夾或者FTP連接對同一個文件打開兩個相同的連接。所以當和RFC959比較時，證明JDK并不是完全令人滿意的。而且，當使用JDK所支持的FTP時，FTP服務器端返回的是無格式的字符串，而不是方便的java對象。為了完全的獲得RFC959的支持和提供方便的方法，java開發者們必須求助于市面上的第三方庫
許多的JAVA FTP庫都可以在網上找到，他們有：
--JScape's Secure FTP Factory
--Enterprise Distributed Technologies' FTPj
--JFtp
--Jakarta Commons/Net
--Sun JDK
--Florent Cueto's JavaFTP API
--Bea Petrovicova's jvFTP
--The Globus Alliance's Java CoG Kit
--Glub Tech's Secure FTP Bean
--Calvin Tai's FtpBean這個列表非常的長，所以對這些庫進行比較非常的不直觀。甚至這些庫都實現各自不同的特性，不同的價格，而且水平的質量和使用條款也不同。所以選擇一個和具體需求細節有關的庫文件非常的麻煩。為了幫助決策者選擇一個適合他們需求的庫，這篇文章對這些庫進行比較和評價。
版權聲明：任何獲得Matrix授權的網站，轉載時請務必保留以下作者信息和鏈接作者:Jean-Pierre Norguet ;
tain198127(作者的blog:
http://blog.matrix.org.cn/page/tain198127)
原文:
http://www.javaworld.com/javaworld/jw-03-2006/jw-0306-ftp.htmlMatrix:
http://www.matrix.org.cn/resource/article/44/44480_Java+FTP+libraries.html關鍵字:Java;FTP;libraries
這些比較采用了一系列的標準，包括所支持的特性，提供者的商業方面，還有文件傳輸性能。我采用了一些Java FTP Client Libraries Reviewed中的標準。請查閱該文章進行回顧。為了進行評估而建立的新標準是“安全支持標準”還有“文件傳輸性能標準”。“安全支持標準”指明這些庫是否實現了FTP的延伸安全性。“文件傳輸性能標準”是比較這些庫的傳輸速度
關于FTP的“安全支持標準”在Internet Engineering Task Force's reference document RFC2228中有定義。根據建議FTP“安全支持標準”主要是兩種類型。隱式的和顯式的。隱式的FTP“安全支持標準”實際就是在建立在安全傳輸層的FTP協議，采用直接的SSL連接，默認通過990端口。顯式FTP“安全支持標準”，是建立在SSL上的FTP，但是用隱降牧猶媧酥苯擁腟SL連接，它是先采用普通的FTP協議連接到服務器，然后再用AUTHSSL 或者AUTH TLS命令轉換到SSL安全連接來轉換到SSL安全模式的。顯式SSL和隱式SSL都是典型的提交到FTPS的。FTP“安全支持標準”還可以實現SSH子協議的方式實現（SSH是安全外殼）。這種實現是提交到SFTP的。盡管協議的名字和功能類似，但是他和前面提到的模式是完全不一樣的。Java FTP Client Libraries Reviewed中比較明確指出了每個庫文件支持的FTP標準到底是SFTP還是FTPS。
庫的“文件傳輸性能標準”比較表是基于兩種傳輸標準的。第一種標準描述的是傳輸一個大型文件的速度并標明數據通過網絡傳輸到對方的時間。第二種標準用來測量傳輸許多小型文件的速度，并指明該庫用于連接服務端的時間。在根據具體的應用程序選擇最合適的文件時，這兩種標準會起到幫助。例如：在為視頻傳輸的應用中應以該庫的傳輸大數據的得分為標準，而為那些用戶和FTP服務器進行許多交互的應用上，就該以其傳輸許多小數據的得分為標準。
試驗試驗常用的測量方法列在后面：在FTP服務器端創建一個大文件和許多小文件，這些文件（大文件和小文件）是用來分別測量服務器傳輸大文件和小文件的速度的。這些數據的數量和大小被設計成相同的數據量。而且是采用兩臺相似的機器通過TCP/IP網絡協議進行測試的。為了保證測試數據的正確性，在測試過程中任何其他的網絡傳輸都被排斥在外了。而且，為了保證所測數據均勻分布，我做了10次測量，再取其平均值。
試驗的設置如下：傳輸數據量是10MB。所以，大文件大小就是10MB。小文件大小是1K，數量是10000。網絡測量單位是10 Mbits/s Ethernet network。客戶端是IBM的VisualAge for Java4.0，系統是windows xp. 服務器端是RedHat Linux Fedora Core 2.服務器軟件是vsFTDd for Linux。結果，其測試代碼Java FTP Client Libraries Reviewed內有詳細描述，也可以到Resources進行下載。
為了重現試驗，你可以根據以下操作進行測試：從Resources下載測試代碼，Benchmark.java。測試代碼實現了Benchmark 類，這個類中包含了許多的內部類。每個內部類都為各個庫實現了文件傳輸操作。可以通過編譯運行該程序來測試放在classpath下的庫。可執行程序只接受一個參數：工作空間地址的路徑。這個地址必須包含一個main.config文件，這個文件中包含了配置參數。一個簡單的配置文件main.config可以從Resources下載。執行之后，會產生出一個測量結果文件，其中的測量結果用逗號分隔。該文件可以在工作空間中找到。這個文件可以用電子表格軟件來打開，比如微軟的Excel。
結果根據試驗協議和設定，我得到了分別針對大文件和小文件傳輸的兩組測量數據。每組測量都顯式為獨立的圖表。所有的庫都在左邊，他們傳輸速度以單杠形式顯式在右邊。為了提供絕對比例的測量，傳輸速度是用傳輸時間的倒數乘以最短的傳輸時間。（就是一個百分比，最短傳輸時間/測量的傳輸時間，這樣最快的就是100，其他的依此類推，有點類似于高考中的標準分的概念）。這樣得到100分的就是最快的庫，我也顯示了WIN XP FTP命令行的FTP測量速度。
在大文件傳輸測試圖中（圖1），你可以發現許多的庫都擁有比較高的速度，他們之間的差距比較小。所以，大部分的庫比較適合傳輸大型數據文件。這些庫的記錄工作沒有任何的優化。許多庫的傳輸速度也許得益于優化的操作。最典型的優化方法是：設置通訊連接input/output 數組的長度。因此，最佳優化后的庫可以在相同的速度下傳輸大塊的數據。（也就是說，通過優化，設置input,output的數組長度——也就是緩沖區，那么即使是相同的速度下，可以傳輸大數據，即這樣優化后對傳輸大數據有利）
Figure 1. Large-file transfer speed
小文件傳輸測試圖（圖2）顯示EnterpriseDT's edtFTPj, Calvin Tai's FtpBean, and Glub Tech's Secure FTP Bean的性能比其他庫更優越，甚至比WIN XP FTP命令行的速度還高。在SUN 的JDK中有一個明顯的BUG，就是在下載了200個文件之后，JDK拒絕傳輸，提示內存錯誤。在圖表中，我只對前200個傳輸進行了統計。而分數最低的原因是因為每個download操作都需要新建一個新的connection來進行打開和關閉操作。這種引入連接方式是針對單個文件傳輸的。總之，JDK架設的FTP只適合下載文件數量較少的情況。
Figure 2. Small-file transfer speed
回顧一下每個庫的特性，點擊here可以得到比較的列表。庫的名字顯示在最上面，標準出現在左邊，每個單元的的縮寫在每個表格中的關鍵字中有解釋。
總結這篇文章是建立于我以前在JavaWorld發表的文章"Java FTP Client Libraries Reviewed"上的，并且是用于研究JAVA平臺上對FTP的支持。在性能方面，對大文件的傳輸結果比較相似。對于小文件傳輸測試，EnterpriseDT's edtFTPj, Calvin Tai's FtpBean,和Glub Tech's Secure FTP Bean是最好的選擇，然而SUN的JDK需要解決下載數不能超過200個文件的BUG。關于其他方面的測試，可以查閱測試比較列表。
由于很多的第三方庫都支持FTP RFC959，開發者可以根據自己的需求選擇最有效率的庫了。然而，使用第三方庫會增加程序的復雜度。例如一個APPLET被配置在客戶端，可能需要下載到服務器端。如果JDK完全的支持FTP的話，那么就不會出現這種隱藏的復雜度問題了。
為了使JDK完全的支持FTP，一個RFE已經被提交到了Sun Developer Network Bug Database了，在一個不斷成長的社區30個月持續不斷的支持下，為該REF投票的人數已經從最初的8個人增長到88個人，使得這個RFE成了最高的25個RFE之一。然而，直到我寫這篇文章的時候，SUN的工程師還沒有解決該RFE，也沒有公布該RFE的解決時刻表。
同時，Java FTP API標準化項目組織也支持FTP RFE，這個項目組織的目標是將支持該RFE的社區的成員集合起來，從而提供在JAVA平臺上可用資源。這個項目也努力的召集一個專家組向JCP提交相關的JSR。這個JSR將會以JAVA平臺標準實現RFC959協議，從而實現對FTP的完全支持。然而，這個專家組還沒有成型，而且提交該JSR成為標準的時間還沒有確定。總之，讓JAVA平臺支持FTP的特性是有好處的。
資源Matrix:
http://www.matrix.org.cnJavaworld:
http://www.javaworld.com