Connection reset by peer的常見原因

Connection reset by peer的常見原因：
1）伺服器的並發串連數超過了其承載量，伺服器會將其中一些串連關閉；
   如果知道實際串連伺服器的並發客戶數沒有超過伺服器的承載量，則有可能是中了病毒或者木馬，引起網路流量異常。可以使用netstat -an查看網路連接情況。
2）客戶關掉了瀏覽器，而伺服器還在給用戶端發送資料；
3）瀏覽器端按了Stop；
   這兩種情況一般不會影響伺服器。但是如果對異常資訊沒有特別處理，有可能在伺服器的記錄檔中，重複出現該異常，造成伺服器記錄檔過大，影響伺服器的運行。可以對引起異常的部分，使用try...catch捕獲該異常，然後不輸出或者只輸出一句提示資訊，避免使用e.printStackTrace();輸出全部異常資訊。
4）防火牆的問題；
   如果網路連接通過防火牆，而防火牆一般都會有逾時的機制，在網路連接長時間不傳輸資料時，會關閉這個TCP的會話，關閉後在讀寫，就會導致異常。如果關閉防火牆，解決了問題，需要重新設定防火牆，或者自己編寫程式實現TCP的長串連。實現TCP的長串連，需要自己定義心跳協議，每隔一段時間，發送一次心跳協議，雙方維持串連。
5）JSP的buffer問題。
   JSP頁面預設緩衝為8k，當JSP頁面資料比較大的時候，有可能JSP沒有完全傳遞給瀏覽器。這時可以適當調整buffer的大小。 <%@ page buffer="100k"%>

常見網路異常（轉自http://www.cnblogs.com/kaixin110/archive/2008/04/11/1148671.html）：
第1個異常是java.net.BindException:Address already in use: JVM_Bind。該異常發生在伺服器端進行new ServerSocket

(port)（port是一個0，65536的整型值）操作時。異常的原因是以為與port一樣的一個連接埠已經被啟動，並進行監聽。此時用

netstat –an命令，可以看到一個Listending狀態的連接埠。只需要找一個沒有被佔用的連接埠就能解決這個問題。


第2個異常是java.net.ConnectException: Connection refused: connect。該異常發生在用戶端進行 new Socket(ip, port)

操作時，該異常發生的原因是或者具有ip地址的機器不能找到（也就是說從當前機器不存在到指定ip路由），或者是該ip存在

，但找不到指定的連接埠進行監聽。出現該問題，首先檢查用戶端的ip和port是否寫錯了，如果正確則從用戶端ping一下伺服器

看是否能 ping通，如果能ping通（服務伺服器端把ping禁掉則需要另外的辦法），則看在伺服器端的監聽指定連接埠的程式是否

啟動，這個肯定能解決這個問題。


第3個異常是java.net.SocketException: Socket is closed，該異常在用戶端和伺服器均可能發生。異常的原因是己方主動關

閉了串連後（調用了Socket的close方法）再對網路連接進行讀寫操作。


第4個異常是java.net.SocketException: （Connection reset或者 Connect reset by peer:Socket write error）。該異常

在用戶端和伺服器端均有可能發生，引起該異常的原因有兩個，第一個就是如果一端的Socket被關閉（或主動關閉或者因為異

常退出而引起的關閉），另一端仍發送資料，發送的第一個資料包引發該異常 (Connect reset by peer)。另一個是一端退出

，但退出時並未關閉該串連，另一端如果在從串連中讀資料則拋出該異常（Connection reset）。簡單的說就是在串連斷開後

的讀和寫操作引起的。


第5個異常是java.net.SocketException: Broken pipe。該異常在用戶端和伺服器均有可能發生。在第4個異常的第一種情況中

（也就是拋出SocketExcepton:Connect reset by peer:Socket write error後），如果再繼續寫資料則拋出該異常。前兩個異

常的解決方案是首先確保程式退出前關閉所有的網路連接，其次是要檢測對方的關閉串連操作，發現對方關閉串連後自己也要

關閉該串連。

  用戶端錯誤碼10053 Software caused connection abort（軟體原因導致串連中斷）