前言
最近因項目需要，需要把一定數量的中等文件從開發板上傳到電腦上，分別選擇了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)、更多的數量等等，因時間有限不做測試了。不過通過上面的分析，考慮各個因素對速度的影響，也大概可以選擇出比較優的方案。如有機會再測試分析。
歡迎各位評論，指出不足之處。