What is the meaning of the "connection reset by peer" error on a TCP connection? Is it a fatal error or just a notification?
It's pretty fatal. The remote server has sent you a RST packet, which indicates an immediate dropping of the connection, rather than the usual handshake. This bypasses the normal half-closed state transition. I like this description:
"Connection reset by peer" is the TCP/IP equivalent of slamming the phone back on the hook. It's more polite than merely not replying, leaving one hanging. But it's not the FIN-ACK expected of the truly polite TCP/IP converseur.
This means that a TCP RST was received and the connection is now closed. This occurs when a packet is sent from your end of the connection but the other end does not recognize the connection; it will send back a packet with the RST bit set in order to forcibly close the connection. This can happen if the other side crashes and then comes back up, or if it calls close() on the socket while there is data from you in transit, and is an indication to you that some of the data that you previously sent may not have been received. It is up to you whether that is an error; if the information you were sending was only for the benefit of the remote client then it may not matter that any final data may have been lost. However you should close the socket and free up any other resources associated with the connection.
異常內容：
org.springframework.web.client.ResourceAccessException: I/O error on GET request for "http://news.panguso.com/subapi!addsub.htm?uid=2746&cid=855":Connection reset; nested exception is java.net.SocketException: Connection reset
找遍了中英文的一些網站，搜遍了能找的每個角落，發現了出現這種狀況的原理，該java異常在客戶端和服務器端都有可能發生，引起該異常的原因有兩個：
1，如果一端的Socket被關閉（或主動關閉，或因爲異常退出而 引起的關閉），另一端仍發送數據，發送的第一個數據包引發該異常(Connect reset by peer)。
2，一端退出，但退出時並未關閉該連接，另一端如果在從連接中讀數據則拋出該異常（Connection reset）。
簡單的說就是在連接斷開後的讀和寫操作引起的。
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（軟件原因導致連接中斷）