記一次FTP上傳文件老是超時的解決過程

很久沒寫博，仍是重拾記錄一下吧。

背景：買了一個阿里雲的雲虛擬機用來搭建網站（起初不瞭解雲虛擬主機和雲服務器的區別，覺得都是有SSH功能的，後來發現不是這樣樣子啊，雲虛擬機就是FTP上傳網頁+MySQL存儲數據，對於只作網站來講還行，可是想作一些擴展或高級功能就不行了，強烈建議仍是買雲服務器ECS）。

使用的時候遇到一個很是奇怪的現象。在家裏的網絡環境下（使用DLink作路由器），鏈接FTP服務器和下載文件都沒有問題，可是上傳文件老是到100%而後卡住好久，而後出現Timeout，服務器上的文件被覆蓋，但字節爲0。一開始覺得是FileZilla設置的問題，因而在主動被動模式，字符集這些調了半天，仍是不行；後面更換了Transmit，Mac終端的ftp，Windows虛擬機裏面的Explorer，CuteFtp，FlashFXP這些進行測試，發現仍是同樣的結果。可是後面我在公司網絡環境下使用任何一個客戶端進行上傳都沒有出現問題。

我懷疑是阿里雲的雲虛擬機FTP有限制，我在阿里雲工單系統提交了一個工單要求解決兩個問題：

發送超時問題：
ftp> put ~/common.css /htdocs/common.css
229 Entering Extended Passive Mode (|||40019|).
150 Ok to send data.
100% |***********************************| 16335       21.08 MiB/s    00:00 ETA
426 Failure reading network stream.
16335 bytes sent in 00:56 (0.28 KiB/s)

登陸失敗問題：
421 There are too many connections from your internet address.

但經過討論發現第二個問題應該是我在上傳超時時屢次斷開和鏈接形成的，容易解決。問題在於上傳超時問題，售後認爲多是IP遭到屏蔽，但查詢後並無。沒有更好的思路解決問題，只好在家裏各類測試，屢次測試後發現只要是一個比較"小"的文件（小於1KB），上傳成功；可是「大」一點的文件（好比2KB以上），就老是上傳失敗。跟文件的類型無關。反饋給售後後認爲是我本地的網絡環境不穩定致使的，可是我用的是以太網，使用的過程當中HTTP下載、QQ微信登陸都沒有問題，玩DOTA2也沒有出現掉線狀況，應該不會「不穩定」到2KB的文件都上傳不上去。最終我測試得出文件<=1432B都能上傳，>1432B就上傳不了了，更排出了「不穩定」的問題，由於不穩定的話上傳失敗不可能一直處於1433B這個臨界值。

在Google上搜索相關中文網頁，但不多有相關的信息，不過有一些引導我向防火牆、路由器這些方面思考，反饋給售後那邊卻表示沒有更多辦法幫忙了。Mac的防火牆我都是關閉的；路由器防火牆管理方面只能本身動手把功能都試一下。可是DMZ，防火牆規則，端口轉發這些設置弄了遍也沒有解決問題。

仍是回到Google，在更換了屢次英文關鍵詞後，終於找到了一些跟我同病相憐的人。其中最爲有用的是https://trac.filezilla-project.org/ticket/5533#no1，通讀了一遍終於找到了問題所在。大意就是FTP使用兩個TCP鏈接來通訊，一條控制鏈接(control connection)用來提交命令和接受回覆；一條數據鏈接(data connection)來處理實際的文件傳輸。在文件傳輸過程當中，控制鏈接是很容易進入空閒狀態的，TCP標準也沒有規定一個鏈接的最大空閒時間。可是路由器和防火牆常常會把空閒的鏈接給關閉掉，而且不通知雙方，就形成了傳輸100%但最後仍是超時的現象。後面的評論就是解決問題的關鍵了：TCP傳輸過程當中有最大的包上限MTU(Maximum Transmission Unit，不超過1500)，超過這個大小的傳輸就要拆成多個包(packet)。因此比較「小」的文件不用拆包，一次就傳輸完了；「大」的文件須要拆包，分屢次發送，就出現超時的問題。對於不一樣的ISP提供商來講，不一樣的MTU存在最優值。因而在路由器管理頁面找到MTU設置，發現原來是1492，隨手用網上找的值1472填進去，重啓路由器，It works!!