FTP和TCP的文件傳輸效率對比測試分析

前言

最近因項目須要，須要把必定數量的中等文件從開發板上傳到電腦上，分別選擇了FTP和TCP自定義協議兩種方式進行傳輸，進行了簡單的對比測試，故作以下記錄。

測試環境

開發板：Linux，ARMv7 單核，內存512M

PC：winodw， i7，8G內存，SSD

網絡：100M，局域網

文件：大小4.06M，數量50個

 

四種方案簡述

一、FTP上傳，短鏈接，單線程

二、FTP上傳，長鏈接，單線程

三、TCP上傳，短鏈接，單線程

四、TCP上傳，短鏈接，多線程

五、TCP上傳，長鏈接，單線程

 

說明

一、這裏提的TCP上傳，是指使用自定義協議TCP方式上傳。

二、短鏈接是指每上傳一個文件就鏈接一次，傳完後就關閉鏈接。

三、長鏈接是指先鏈接，再上傳多個文件，到退出程序時再關閉鏈接。

四、單線程是指全部文件的鏈接、發送、關閉都是在一個線程內完成。

五、多線程是指一個文件對應一個線程，多個文件同時使用多個線程發送。

 

自定義文件傳輸協議

自定義文件協議設計得很是簡單。

客戶端發送數據包 = 128B文件名 + 4B文件長度 + 文件數據

服務端響應數據包 = 「OK」

 

之因此如此設計，列以下幾點緣由：

一、固定文件名長度，方便處理，也方便定位到文件長度字段。

二、4字節文件長度恰好和整型相等，在兩個32位小端機器上直接拷貝發送，代碼簡單。

三、文件長度字段能夠方便檢查數據是否接收徹底，解決粘包問題。

四、局域網內網絡相對比較好，因此沒帶文件校驗。

 

測試結果

方案1，2分鐘

方案2，45秒

方案3，20秒

方案4，20秒

方案5，20秒

 

結果分析

分析以前，先計算一下理論的傳輸速度應該是多少，文件總大小約爲203M，按100M網絡計算，速度應該是203/(100/8) = 16秒。因此說20秒是一個比較不錯的速度了，畢竟還有一些文件操做等操做，須要佔用一些時間。

 

方案1和方案2比較

FTP創建鏈接相對複雜，不斷的鏈接和斷開確定消耗很多時間，因此長鏈接比短鏈接傳輸速度快也是應該的。

 

FTP方案和TCP方案比較

FTP方案總體上比TCP方案慢得多，畢竟FTP協議確定比自定義的文件傳輸協議要複雜得多，交互指令越多，速度越慢。

 

方案3和方案4比較

兩個方案的差異在因而否使用多線程發送。從結果來看，速度相差不大。由於網絡的極限速度就是100M，同時發送再多的數據也沒有用，都會阻塞在網絡上。即便發送的速度可能快一點點，但開啓多個線程、線程同步鎖等也須要時間，可能相抵消了。

 

方案3和方案5比較

兩個方案的差異在因而否使用長鏈接。從結果來看，速度相關不大。和上面分析同樣，網絡的極限速度是100M，而TCP在局域網內創建鏈接（三次握手）、關閉都很是快。對於發送大量數據的狀況，是否使用長鏈接影響都不大。

 

從上面的測試和分析結果來看，在本項目中使用方案3或5（TCP上傳，單線程），是比較合適的。首先傳輸速度上表現不錯，並且避免使用多線程，不須要線程同步，代碼設計更簡單，越簡單越容易作得更可靠。

固然上面的測試是不充分的，對於其餘狀況沒有進行測試分析。例如，使用FTP多線程發送、更小的文件(小於1k)、更大的文件(大幾百M)、更多的數量等等，因時間有限不作測試了。不過經過上面的分析，考慮各個因素對速度的影響，也大概能夠選擇出比較優的方案。若有機會再測試分析。

歡迎各位評論，指出不足之處。