一，簡(jiǎn)介
一個(gè)歷史項(xiàng)目里面用了c# .net 2.0的FtpWebRequest進(jìn)行文件上傳；ftp server在各現(xiàn)場(chǎng)用的應(yīng)該都是Filezilla。
因業(yè)務(wù)發(fā)展，需要上傳大文件（500M以上吧），某現(xiàn)場(chǎng)就出現(xiàn)了上傳失敗的情況。
二，網(wǎng)絡(luò)問題
最開始的代碼里面并沒有記錄上傳失敗的具體原因，或者說log記錄沒能準(zhǔn)確定位問題。
代碼修改后還是沒能準(zhǔn)確定位問題。
但從log判斷，似乎是網(wǎng)絡(luò)斷開造成的。
這想到可能現(xiàn)場(chǎng)網(wǎng)絡(luò)不穩(wěn)定，有瞬斷情況。
三，斷點(diǎn)續(xù)傳
聽過斷點(diǎn)續(xù)傳，在百度找了些代碼，修改一下封裝好嵌到項(xiàng)目里面。
當(dāng)時(shí)只在網(wǎng)絡(luò)暢通的情況下測(cè)試過，代碼也沒還checkin，發(fā)現(xiàn)場(chǎng)用戶也試試。
反饋還是不行。
看log更加迷糊了，堆棧顯示在FtpWebRequest.GetRequestStream.Close里面拋出來的異常。
想不明白啊。
四，重現(xiàn)爛網(wǎng)絡(luò)
去過現(xiàn)場(chǎng)出差的同事反應(yīng)，現(xiàn)場(chǎng)的網(wǎng)絡(luò)真的好爛。
這想到怎么去模擬一個(gè)爛網(wǎng)絡(luò)出來。
設(shè)置延時(shí)50ms，50%的丟包率，丫的那個(gè)異常堆棧重現(xiàn)出來了。
異常信息如下：
這應(yīng)該說的，連接已經(jīng)斷開了，再關(guān)的話就報(bào)錯(cuò)了。
程序調(diào)試進(jìn)去發(fā)現(xiàn)，最早引發(fā)異常的是FtpWebRequest.GetRequestStream.Write，程序里面是有catch，但只是記錄了失敗的位置偏移以便下次重傳，也沒有去記錄失敗原因。
當(dāng)時(shí)close的調(diào)用是放在finally塊里面的，這個(gè)close引發(fā)的異常導(dǎo)致續(xù)傳沒能繼續(xù)執(zhí)行，log記錄的堆棧也就是從這里開始。
五，重現(xiàn)了也沒個(gè)屁用啊
既然close不掉，那就直接跳到FtpWebRequest.GetResponse.Close好了。
還真不報(bào)異常了，GetResponse就直接阻塞了，一直塞到ftp server都超時(shí)斷開了，還沒返回。
看了一下msdn，說好的FtpWebRequest.Timeout咋的沒生效呢？FtpWebRequest.ReadWriteTimeout可是好好的呢。
google+stackoverflow也沒找到解決，倒是找到一些吐槽FtpWebRequest和Ftp庫推薦的。
莫非還真得換庫或者直接調(diào)些ftp命令？
同時(shí)stackoverflow發(fā)了第一個(gè)問題，我只想知道為什么不超時(shí)也不返回，因?yàn)槲疫BGetResponse.Close都不調(diào)用就直接開始下一次重傳的話，會(huì)報(bào)另一個(gè)異常如下：
不造是否英語太爛，或者是問題沒到點(diǎn)子上，問題沉了。
6，似乎只能傻逼了
下班路上想到，出現(xiàn)異常的時(shí)候，一個(gè)close也不調(diào)用，無論是否重新連接，因?yàn)榫W(wǎng)絡(luò)已經(jīng)不通了，server應(yīng)該還hold住一個(gè)連接，把文件鎖住了。
這應(yīng)該就是上面異常的情況，文件被鎖了，新連接就沒法操作這個(gè)文件，看server log，確實(shí)有這個(gè)cann't access file的記錄。
那很好，client出異常了，等一個(gè)足夠長的時(shí)間，等到server將連接斷開就好了，close也就不管了。
但想想這也太傻逼了啊，這得等到什么時(shí)候啊。
7，也算徹底解決了，反正可以交貨了
試了一下filezilla client，有斷點(diǎn)續(xù)傳功能，發(fā)現(xiàn)網(wǎng)絡(luò)異常斷開，開始續(xù)傳連接開始之前，server那個(gè)連接總會(huì)很快斷開。
這又是怎么解析呢，不是說網(wǎng)絡(luò)都不通了，server那個(gè)連接是怎么放掉的呢？
google一下，stackoverflow上看到FtpWebRequest有個(gè)Abort函數(shù)，說是斷開一個(gè)異步請(qǐng)求。
一試，我同步連接也能斷開啊，網(wǎng)絡(luò)異常，啥都不close，直接abort，server那個(gè)連接就斷了，很快也就可以重傳了呢。
8，來都來了
這個(gè)abort做了什么鬼呢，想用wireshark抓個(gè)包看看，無奈不懂，十來分鐘連個(gè)filter都沒寫好。
難道是50%的丟包不夠強(qiáng)悍，abort還是有數(shù)據(jù)逃出去了？
后來百度知道wireshark在windows下要做特殊處理才能抓取本地?cái)?shù)據(jù)包。
無奈增加本機(jī)路由后filezilla server連不上了，最后下了個(gè)手機(jī)ftp server。
發(fā)現(xiàn)abort也沒什么特殊的地方，只是通知ftp釋放控制連接和數(shù)據(jù)連接然后馬上返回，連接能不能斷掉就聽天由命了。
100%丟包率的時(shí)候，filezilla還真有連接會(huì)鎖死文件。