前言

最近因專案需要，需要把一定數量的中等檔案從開發板上傳到電腦上，分別選擇了FTP和TCP自定義協議兩種方式進行傳輸，進行了簡單的對比測試，故做如下記錄。

測試環境

開發板：Linux，ARMv7 單核，記憶體512M

PC：winodw， i7，8G記憶體，SSD

網路：100M，區域網

檔案：大小4.06M，數量50個

四種方案簡述

1、FTP上傳，短連線，單執行緒

2、FTP上傳，長連線，單執行緒

3、TCP上傳，短連線，單執行緒

4、TCP上傳，短連線，多執行緒

5、TCP上傳，長連線，單執行緒

說明

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

2、短連線是指每上傳一個檔案就連線一次，傳完後就關閉連線。

3、長連線是指先連線，再上傳多個檔案，到退出程式時再關閉連線。

4、單執行緒是指所有檔案的連線、傳送、關閉都是在一個執行緒內完成。

5、多執行緒是指一個檔案對應一個執行緒，多個檔案同時使用多個執行緒傳送。

自定義檔案傳輸協議

自定義檔案協議設計得非常簡單。

客戶端傳送資料包 = 128B檔名 + 4B檔案長度 + 檔案資料

服務端響應資料包 = “OK”

之所以如此設計，列如下幾點原因：

1、固定檔名長度，方便處理，也方便定位到檔案長度欄位。

2、4位元組檔案長度剛好和整型相等，在兩個32位小端機器上直接拷貝傳送，程式碼簡單。

3、檔案長度欄位可以方便檢查資料是否接收完全，解決粘包問題。

4、區域網內網路相對比較好，所以沒帶檔案校驗。

測試結果

方案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)、更多的數量等等，因時間有限不做測試了。不過通過上面的分析，考慮各個因素對速度的影響，也大概可以選擇出比較優的方案。如有機會再測試分析。

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