第壹次上傳4330個39.9M***的文件，用了半個小時，中間多次傳輸失敗。
第二次上傳壹個12.9M的壓縮包文件，耗時6秒，沒有傳輸失敗。
第三次上傳壹個117M的壓縮包文件，用時17秒，中間沒有傳輸失敗。
細心的人不難看出，上傳的數據在上傳中斷的實驗中有壹個明顯的特點:文件數量特別多。兩次成功上傳中只上傳了壹個文件。
這樣看來，FTP上傳中斷應該與要上傳的文件數量有關。
專業解釋如下:
FTP是應用層協議，基於傳輸層，為用戶服務。他們負責傳輸文件。FTP是壹種8位的客戶端-服務器協議，它可以操作任何類型的文件，而無需進壹步處理，就像MIME或Unicode壹樣。但是FTP的延遲非常高，這意味著從開始請求到第壹次收到所需數據的時間會非常長，需要時不時的進行壹些冗長的登錄過程。
FTP服務通常運行在端口20和21上。端口20用於客戶端和服務器之間傳輸數據流，端口21用於傳輸控制流，是命令進入ftp服務器的入口。當數據通過數據流傳輸時，控制流處於空閑狀態。當控制流長時間空閑時，客戶端的防火墻會將其會話設置為超時，這在大量數據通過防火墻時會產生壹些問題。此時，雖然可以成功傳輸文件，但是因為控制會話會被防火墻斷開，所以傳輸會產生壹些錯誤。
說的這麽專業，很多非計算機專業的童鞋可能會比較朦朧，那我們就來解釋壹下為什麽FTP在有大量文件上傳的情況下會很慢，經常中斷。
我們把服務器比作壹個城市，我們上傳的文件是想去城市的人。FTP協議是他們要進城必須遵守的規則，而傳輸數據的端口就是城門，每個文件都被視為壹個人。
當我們使用FTP客戶端向服務器上傳大量文件時，可以看作是壹群人開著車通過門戶進入服務器城。
但因為進城必須遵守壹定的規則(FTP協議)，即必須先去指揮口申報我要進城再通過數據口進去，每次只能有壹輛車進入。比如上圖中的5輛車，要排隊等5次開關城門(數據口)，每次開關城門都要花很長時間。最重要的是，聲明命令端口後並不總是有效。但是過了壹定時間就會關閉。壹旦命令端口關閉，數據端口也將關閉。這時候因為開關門要花很多時間，所以並不是所有等待進城的車都要進去。這時候就需要重新聲明命令端口，這也是上傳數據突然中斷的原因。因為命令端口的開放時間到了，必須重新申報。
然後把大量數據壓縮成壓縮包上傳。這時候就可以看做是壹群人坐公交車進城。
此時因為只有壹輛車進城，所以這輛車已經在指揮口開放的時間內進城了，不會有中斷。
在這壹點上，我們要明白，如果要解決FTP上傳中斷的問題，那麽最好的解決方案就是在上傳之前對數據進行打包壓縮，這樣就不會出現上傳中斷的情況。記住，千萬不要壹次上傳太多文件，要打包壓縮。