欧美成人精品手机在线观看_69视频国产_动漫精品第一页_日韩中文字幕网 - 日本欧美一区二区

背景：買了一個阿里云的云虛擬機(jī)用來搭建網(wǎng)站（起初不了解云虛擬主機(jī)和云服務(wù)器的區(qū)別，以為都是有SSH功能的，后來發(fā)現(xiàn)不是這樣樣子啊，云虛擬機(jī)就是FTP上傳網(wǎng)頁+MySQL存儲數(shù)據(jù)，對于只做網(wǎng)站來說還行，但是想做一些擴(kuò)展或高級功能就不行了，強(qiáng)烈建議還是買云服務(wù)器ECS）。

使用的時候遇到一個非常奇怪的現(xiàn)象。在家里的網(wǎng)絡(luò)環(huán)境下（使用DLink做路由器），連接FTP服務(wù)器和下載文件都沒有問題，但是上傳文件總是到100%然后卡住很久，然后出現(xiàn)Timeout，服務(wù)器上的文件被覆蓋，但字節(jié)為0。一開始以為是FileZilla設(shè)置的問題，于是在主動被動模式，字符集這些調(diào)了半天，還是不行；后面更換了Transmit，Mac終端的ftp，Windows虛擬機(jī)里面的Explorer，CuteFtp，F(xiàn)lashFXP這些進(jìn)行測試，發(fā)現(xiàn)還是一樣的結(jié)果。但是后面我在公司網(wǎng)絡(luò)環(huán)境下使用任何一個客戶端進(jìn)行上傳都沒有出現(xiàn)問題。

我懷疑是阿里云的云虛擬機(jī)FTP有限制，我在阿里云工單系統(tǒng)提交了一個工單要求解決兩個問題：

發(fā)送超時問題：
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.

但通過討論發(fā)現(xiàn)第二個問題應(yīng)該是我在上傳超時時多次斷開和連接造成的，容易解決。問題在于上傳超時問題，售后認(rèn)為可能是IP遭到屏蔽，但查詢后并沒有。沒有更好的思路解決問題，只好在家里各種測試，多次測試后發(fā)現(xiàn)只要是一個比較"小"的文件（小于1KB），上傳成功；但是“大”一點(diǎn)的文件（比如2KB以上），就總是上傳失敗。跟文件的類型無關(guān)。反饋給售后后認(rèn)為是我本地的網(wǎng)絡(luò)環(huán)境不穩(wěn)定導(dǎo)致的，但是我用的是以太網(wǎng)，使用的過程中HTTP下載、QQ微信登錄都沒有問題，玩DOTA2也沒有出現(xiàn)掉線情況，應(yīng)該不會“不穩(wěn)定”到2KB的文件都上傳不上去。最終我測試得出文件<=1432B都能上傳，>1432B就上傳不了了，更排出了“不穩(wěn)定”的問題，因?yàn)椴环€(wěn)定的話上傳失敗不可能一直處于1433B這個臨界值。

在Google上搜索相關(guān)中文網(wǎng)頁，但很少有相關(guān)的信息，不過有一些引導(dǎo)我向防火墻、路由器這些方面思考，反饋給售后那邊卻表示沒有更多辦法幫忙了。Mac的防火墻我都是關(guān)閉的；路由器防火墻管理方面只能自己動手把功能都試一下。但是DMZ，防火墻規(guī)則，端口轉(zhuǎn)發(fā)這些設(shè)置弄了遍也沒有解決問題。

還是回到Google，在更換了多次英文關(guān)鍵詞后，終于找到了一些跟我同病相憐的人。其中最為有用的是https://trac.filezilla-project.org/ticket/5533#no1，通讀了一遍終于找到了問題所在。大意就是FTP使用兩個TCP連接來通信，一條控制連接(control connection)用來提交命令和接受回復(fù)；一條數(shù)據(jù)連接(data connection)來處理實(shí)際的文件傳輸。在文件傳輸過程中，控制連接是很容易進(jìn)入空閑狀態(tài)的，TCP標(biāo)準(zhǔn)也沒有規(guī)定一個連接的最大空閑時間。但是路由器和防火墻經(jīng)常會把空閑的連接給關(guān)閉掉，并且不通知雙方，就造成了傳輸100%但最后還是超時的現(xiàn)象。后面的評論就是解決問題的關(guān)鍵了：TCP傳輸過程中有最大的包上限MTU(Maximum Transmission Unit，不超過1500)，超過這個大小的傳輸就要拆成多個包(packet)。所以比較“小”的文件不用拆包，一次就傳輸完了；“大”的文件需要拆包，分多次發(fā)送，就出現(xiàn)超時的問題。對于不同的ISP提供商來說，不同的MTU存在最優(yōu)值。于是在路由器管理頁面找到MTU設(shè)置，發(fā)現(xiàn)原來是1492，隨手用網(wǎng)上找的值1472填進(jìn)去，重啟路由器，It works!!