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