2018-03-15更新：弄明白connection reset產生的原因，見重新分析connection reset by peer, socket write error錯誤原因
在開發文件上傳功能時遇到了connection reset by peer, socket write error的錯誤，排查廢了一番功夫，記錄一下。
在網上搜索了一下，得到的原因有這些：
- 服務器的並發連接數超過了其承載量，服務器會將其中一些連接Down掉；
- 客戶關掉了瀏覽器，而服務器還在給客戶端發送數據；
- 瀏覽器端按了Stop；
但是看了服務器，不太可能；網絡狀況了也挺好（測試環境而已）。
跟瀏覽器也沒關系，因為這里上傳文件使用的是apache httpclient在上傳文件，而且timeout都設置比較長。
最后分析到的問題原因，出在服務端上。服務端是這么處理的：上傳文件時在header里含有了文件信息，上傳文件成功，記錄文件相關信息在DB；如果再次上傳這個文件，根據header的文件信息在DB判斷是否已經上傳，如果確認是重復文件，則直接返回“文件重復”。（這個業務設計有點bug，暫時忽略）
但是現在卻遇到重復上傳時，客戶端httpclient報了“connection reset by peer, socket write error”的錯誤。
是由於在重復上傳時，服務端只取了header就判斷了文件重復直接response了，這個時候客戶端還在“歡快”的傳輸文件呢，而服務端直接response把連接關閉了，所以客戶端就懵逼了，報了錯誤。
這個問題暫時還沒有找到技術上如何解決（如果找到，后面再補充），所以在業務上進行解決的。在客戶端遇到SocketException時，嘗試重新上傳前，先查詢服務端是否已經完成了此文件的上傳，如果已經存在，則不用重復上傳了，也就可以避免因為重復上傳導致的問題，畢竟重復上傳也是為了保證在網絡不佳時能補償。