ftpjava超時時間

『壹』 java程序可以成功連接ftp伺服器，但無法上傳文件，怎麼回事，報錯如下，（已設置連接超時時間200s）

我感覺有倆問題，1、連接地址和帳號不是一回事，你最好不要用域名做連接地址，可以用IP地址；2、你是在不行通過空間服務商進入線上後台，如果還不行就聯系空間商，可能是他們的問題.果是VPS的話好像要開通ftp某些許可權才可以，你只是開通了帳號，能連接，並沒有給ftp上傳下載的許可權，這個我在空間商裡面看過教程的，在這沒網路不讓發連接，你可以在網路搜一下試試，希望能幫助你。

『貳』 ftp上傳文件的時候老是連接超時。

出現此問題的原因：傳輸模式錯誤。

解決的方法和操作步驟如下：

准備工具：FlashFXP5。

1、首先，在桌面上找到「
FlashFXP5」，然後雙擊以打開FTP軟體，如下圖所示，然後進入下一步。

『叄』 java ftpclient可以重置超時時間嗎

你可以調用

org.apache.commons.net.ftp.FTPClient.setDataTimeout(int)

單位 毫秒

『肆』 ftp伺服器 如何設置文件超過規定時間自動清除

絕大部分FTP伺服器都有超時設置，當你連接上又不做操作，超過一定時間就拆線。避免客戶端長期占線影響SERVER 效率。
解決方法：
在沒有傳輸數據時，定時發送NOOP指令，該指令是為了維護連接，目的就是不讓FTP SERVER斷線，FTP SERVER 接收後不做任何操作。只是返回：
200 Ok. Parameter was ''.

『伍』 如何解決FTP連接超時問題

絡連接超時可能原因: 1.網路斷開，不過經常顯示無法連接 3.網路不穩定，網路無法完整傳送伺服器信息 4.系統：系統資源過低，無法為程序提供足夠的資源處理伺服器信息 5.網路不穩定 比如網線松動、介面沒插好等等 6.注冊時系統繁忙 無法回應 7.網速過慢，如 使用BT 多線程下載等 在線收看視頻等大量佔用帶寬的軟體 ，若使用共享帶寬還要防範他人惡意佔用帶寬 8.中病毒 木馬等 解決辦法: 1； 檢查網線 更換介面 2； 在早上過上網人數少的時候注冊

『陸』 ftp上傳超時的一種解決方案

最近有個同時的ftp總是上傳文件失敗，更換過各種ftp客戶端和賬號都沒有問題，之後又懷疑是win10的問題，但是另外一個同事也是win10，同樣的軟體，同樣的賬號都沒問題。後來也關過系統防火牆，windows denfender之類的，均告失敗。正當准備放棄的時候，突然看到一篇文章(原文連接： https://trac.filezilla-project.org/ticket/5533#no1 )是和同事的情況類似，因為他也是很小的文件可以上傳，但是大於幾kb之後就不能上傳了，而導致這個問題的原因是和 MTU 有關。

具體來說，FTP使用兩個TCP連接來通信，一條控制連接(control connection)用來提交命令和接受回復；一條數據連接(data connection)來處理實際的文件傳輸。在文件傳輸過程中，控制連接是很容易進入空閑狀態的，TCP標准也沒有規定一個連接的最大空閑時間。但是路由器和防火牆經常會把空閑的連接給關閉掉，並且不通知雙方，就造成了傳輸100%但最後還是超時的現象。後面的評論就是解決問題的關鍵了：TCP傳輸過程中有最大的包上限MTU(Maximum Transmission Unit，不超過1500)，超過這個大小的傳輸就要拆成多個包(packet)。所以比較「小」的文件不用拆包，一次就傳輸完了；「大」的文件需要拆包，分多次發送，就出現超時的問題。

好了既然找出始作俑者了，那麼如何修改呢？

通過上面的設置修改，發現果然ftp上傳沒問題了。

抱著好奇的態度，我又去看了下另外一個同事的電腦發現，他的 MTU也是默認的1500，為什麼他可以？？？

後來又查詢資料發現，原來MTU和ISP有關系，後來我又對比了下他們電腦上的dns，發現果真不一樣。好吧，又學習到了不少知識。

『柒』 ftp上傳文件時中斷或超時怎麼解決

實驗分析：
第一次，上傳了39.9M共計4330個文件，用了半小時，中間出現多次傳輸失敗。

第二次，上傳了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上傳中斷的問題，那麼最好的解決辦法就是將數據打包壓縮之後再上傳，這樣就不會出現上傳中斷了，切記，千萬不要一次上傳太多的文件，一定要打包壓縮上傳。