導致“Connection reset”的原因是服務器端因為某種原因關閉了Connection，而客戶端依然在讀寫數據，此時服務器會返回復位標志“RST”，然后此時客戶端就會提示“java.net.SocketException: Connection reset”。
可能有同學對復位標志“RST”還不太了解，這里簡單解釋一下：
TCP建立連接時需要三次握手，在釋放連接需要四次揮手；例如三次握手的過程如下：
第一次握手：客戶端發送syn包（syn=j）到服務器，並進入SYN_SENT狀態，等待服務器確認；
第二次握手：服務器收到syn包，並會確認客戶的SYN（ack=j+1），同時自己也發送一個SYN包（syn=k），即SYN+ACK包，此時服務器進入SYN_RECV狀態；
第三次握手：客戶端收到服務器的SYN+ACK包，向服務器發送確認包ACK(ack=k+1），此包發送完畢，客戶端和服務器進入ESTABLISHED（TCP連接成功）狀態，完成三次握手。
可以看到握手時會在客戶端和服務器之間傳遞一些TCP頭信息，比如ACK標志、SYN標志以及揮手時的FIN標志等。
除了以上這些常見的標志頭信息，還有另外一些標志頭信息，比如推標志PSH、復位標志RST等。其中復位標志RST的作用就是“復位相應的TCP連接”。
TCP連接和釋放時還有許多細節，比如半連接狀態、半關閉狀態等。詳情請參考這方面的巨著《TCP/IP詳解》和《UNIX網絡編程》。
前面說到出現“Connection reset”的原因是服務器關閉了Connection[調用了Socket.close()方法]。大家可能有疑問了：服務器關閉了Connection為什么會返回“RST”而不是返回“FIN”標志。原因在於Socket.close()方法的語義和TCP的“FIN”標志語義不一樣：發送TCP的“FIN”標志表示我不再發送數據了，而Socket.close()表示我不在發送也不接受數據了。問題就出在“我不接受數據” 上，如果此時客戶端還往服務器發送數據，服務器內核接收到數據，但是發現此時Socket已經close了，則會返回“RST”標志給客戶端。當然，此時客戶端就會提示：“Connection reset”。詳細說明可以參考oracle的有關文檔：http://docs.oracle.com/javase/1.5.0/docs/guide/net/articles/connection_release.html。
另一個可能導致的“Connection reset”的原因是服務器設置了Socket.setLinger (true, 0)。但我檢查過線上的tomcat配置，是沒有使用該設置的，而且線上的服務器都使用了nginx進行反向代理，所以並不是該原因導致的。關於該原因上面的oracle文檔也談到了並給出了解釋。
此外啰嗦一下，另外還有一種比較常見的錯誤“Connection reset by peer”，該錯誤和“Connection reset”是有區別的：
服務器返回了“RST”時，如果此時客戶端正在從Socket套接字的輸出流中讀數據則會提示Connection reset”；
服務器返回了“RST”時，如果此時客戶端正在往Socket套接字的輸入流中寫數據則會提示“Connection reset by peer”。
“Connection reset by peer”如下圖所示：
前面談到了導致“Connection reset”的原因，而具體的解決方案有如下幾種：
出錯了重試；
客戶端和服務器統一使用TCP長連接；
客戶端和服務器統一使用TCP短連接。
首先是出錯了重試：這種方案可以簡單防止“Connection reset”錯誤，然后如果服務不是“冪等”的則不能使用該方法；比如提交訂單操作就不是冪等的，如果使用重試則可能造成重復提單。
然后是客戶端和服務器統一使用TCP長連接：客戶端使用TCP長連接很容易配置（直接設置HttpClient就好），而服務器配置長連接就比較麻煩了，就拿tomcat來說，需要設置tomcat的maxKeepAliveRequests、connectionTimeout等參數。另外如果使用了nginx進行反向代理或負載均衡，此時也需要配置nginx以支持長連接（nginx默認是對客戶端使用長連接，對服務器使用短連接）。
使用長連接可以避免每次建立TCP連接的三次握手而節約一定的時間，但是我這邊由於是內網，客戶端和服務器的3次握手很快，大約只需1ms。ping一下大約0.93ms（一次往返）；三次握手也是一次往返（第三次握手不用返回）。根據80/20原理，1ms可以忽略不計；又考慮到長連接的擴展性不如短連接好、修改nginx和tomcat的配置代價很大（所有后台服務都需要修改）；所以這里並沒有使用長連接。
正常情況tcp四層握手關閉連接，rst基本都是異常情況，整理如下：
0.使用 ping 可以看到丟包情況
1. GFW
2. 對方端口未打開，發生在連接建立
如果對方sync_backlog滿了的話，sync簡單被丟棄，表現為超時，而不會rst
3. close Socket 時recv buffer 不為空
例如，客戶端發了兩個請求，服務器只從buffer 讀取第一個請求處理完就關閉連接，tcp層認為數據沒有正確提交到應用，使用rst關閉連接。
3. 移動鏈路
移動網絡下，國內是有5分鍾后就回收信令，也就是IM產品，如果心跳>5分鍾后服務器再給客戶端發消息，就會收到rst。也要查移動網絡下IM 保持<5min 心跳。
4. 負載等設備
負載設備需要維護連接轉發策略，長時間無流量，連接也會被清除，而且很多都不告訴兩層機器，新的包過來時才通告rst。
Apple push 服務也有這個問題，而且是不可預期的偶發性連接被rst；rst 前第一個消息write 是成功的，而第二條寫才會告訴你連接被重置，
曾經被它折騰沒轍，因此打開每2秒一次tcp keepalive，固定5分鍾tcp連接回收，而且發現連接出錯時，重發之前10s內消息。
5. SO_LINGER 應用強制使用rst 關閉
該選項會直接丟棄未發送完畢的send buffer，可能造成業務錯誤，慎用； 當然內網服務間http client 在收到應該時主動關閉，使用改選項，會節省資源。
好像曾經測試過haproxy 某種配置下，會使用rst關閉連接，少了網絡交互而且沒有TIME_WAIT 問題
6. 超過超時重傳次數、網絡暫時不可達
7. TIME_WAIT 狀態
tw_recycle = 1 時，sync timestamps 比上次小時，會被rst
7. 設置 connect_timeout
應用設置了連接超時，sync 未完成時超時了，會發送rst終止連接。
8. 非正常包
連接已經關閉，seq 不正確等
9. keepalive 超時
公網服務tcp keepalive 最好別打開；移動網絡下會增加網絡負擔，切容易掉線；非移動網絡核心ISP設備也不一定都支持keepalive，曾經也發現過廣州那邊有個核心節點就不支持。
10. 數據錯誤，不是按照既定序列號發送數據
11.在一個已關閉的socket上接收數據
12.服務器關閉或異常終止了連接，由於網絡問題，客戶端沒有收到服務器的關閉請求，這稱為TCP半打開連接。就算重啟服務器，也沒有連接信息。如果客戶端向提其寫入數據，對方就會回應一個RST報文段。
參考：
轉自:http://www.cnblogs.com/lulu/p/4149562.html