Connection reset具體的解決方案有如下幾種：

1、出錯了重試；

2、客戶端和服務(wù)器統(tǒng)一使用TCP長連接；

3、客戶端和服務(wù)器統(tǒng)一使用TCP短連接。

首先是出錯了重試：這種方案可以簡單防止“Connection reset”錯誤，然后如果服務(wù)不是“冪等”的則不能使用該方法；比如提交訂單操作就不是冪等的，如果使用重試則可能造成重復(fù)提單。然后是客戶端和服務(wù)器統(tǒng)一使用TCP長連接：客戶端使用TCP長連接很容易配置（直接設(shè)置HttpClient就好），而服務(wù)器配置長連接就比較麻煩了，就拿tomcat來說，需要設(shè)置tomcat的maxKeepAliveRequests、connectionTimeout等參數(shù)。另外如果使用了nginx進行反向代理或負(fù)載均衡，此時也需要配置nginx以支持長連接（nginx默認(rèn)是對客戶端使用長連接，對服務(wù)器使用短連接）。

使用長連接可以避免每次建立TCP連接的三次握手而節(jié)約一定的時間，但是我這邊由于是內(nèi)網(wǎng)，客戶端和服務(wù)器的3次握手很快，大約只需1ms。

ping一下大約0.93ms（一次往返）；三次握手也是一次往返（第三次握手不用返回）。根據(jù)80/20原理，1ms可以忽略不計；又考慮到長連接的擴展性不如短連接好、修改nginx和tomcat的配置代價很大（所有后臺服務(wù)都需要修改）；所以這里并沒有使用長連接。最后的解決方案是客戶端和服務(wù)器統(tǒng)一使用TCP短連接：我這邊正是這么干的，而使用短連接既不用改nginx配置，也不用改tomcat配置，只需在使用HttpClient時使用http1.0協(xié)議并增加http請求的header信息（Connection: Close），源碼如下：

httpGet.setProtocolVersion(HttpVersion.HTTP_1_0);

httpGet.addHeader(HTTP.CONN_DIRECTIVE, HTTP.CONN_CLOSE);

最后再補充幾句，雖然對于每次請求TCP長連接只能節(jié)約大約1ms的時間，但是具體是使用長連接還是短連接還是要衡量下，比如你的服務(wù)每天的pv是1億，那么使用長連接節(jié)約的總時間為：1億*1ms=10^8*1ms=10^5*1s=27.78h

神奇的是，億萬級pv的服務(wù)使用長連接一天內(nèi)節(jié)約的總時間為27.78小時（竟然大于一天），所以使用長連接還是短連接大家需要根據(jù)自己的服務(wù)訪問量、擴展性等因素衡量下。但是一定要注意：服務(wù)器和客戶端的連接一定要保持一致，要么都是長連接，要么都是短連接。

擴展資料：

引起connection reset該異常的原因有兩個：1，如果一端的Socket被關(guān)閉（或主動關(guān)閉，或因為異常退出而 引起的關(guān)閉），另一端仍發(fā)送數(shù)據(jù)，發(fā)送的第一個數(shù)據(jù)包引發(fā)該異常(Connect reset by peer)。

2，一端退出，但退出時并未關(guān)閉該連接，另一端如果在從連接中讀數(shù)據(jù)則拋出該異常（Connection reset）。簡單的說就是在連接斷開后的讀和寫操作引起的。

還有一種比較常見的錯誤“Connection reset by peer”，該錯誤和“Connection reset”是有區(qū)別的：服務(wù)器返回了“RST”時，如果此時客戶端正在從Socket套接字的輸出流中讀數(shù)據(jù)則會提示Connection reset”；服務(wù)器返回了“RST”時，如果此時客戶端正在往Socket套接字的輸入流中寫數(shù)據(jù)則會提示“Connection reset by peer”。