文章轉自：https://my.oschina.net/xionghui/blog/508758
在使用HttpClient調用后台resetful服務時，“Connection reset”是一個比較常見的問題，有同學跟我私信說被這個問題困擾很久了，今天就來分析下，希望能幫到大家。例如我們線上的網關日志就會拋該錯誤：
從日志中可以看到是Socket套接字在read數據時拋出了該錯誤。
導致“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的配置代價很大（所有后台服務都需要修改）；所以這里並沒有使用長連接。ping服務器的時間如下圖：
最后的解決方案是客戶端和服務器統一使用TCP短連接：我這邊正是這么干的，而使用短連接既不用改nginx配置，也不用改tomcat配置，只需在使用HttpClient時使用http1.0協議並增加http請求的header信息（Connection: Close），源碼如下：
-
httpGet.setProtocolVersion(HttpVersion.HTTP_1_0);
-
httpGet.addHeader(HTTP.CONN_DIRECTIVE, HTTP.CONN_CLOSE);
最后再補充幾句，雖然對於每次請求TCP長連接只能節約大約1ms的時間，但是具體是使用長連接還是短連接還是要衡量下，比如你的服務每天的pv是1億，那么使用長連接節約的總時間為：
1億*1ms=10^8*1ms=10^5*1s=27.78h
神奇的是，億萬級pv的服務使用長連接一天內節約的總時間為27.78小時（竟然大於一天），所以使用長連接還是短連接大家需要根據自己的服務訪問量、擴展性等因素衡量下。但是一定要注意：服務器和客戶端的連接一定要保持一致，要么都是長連接，要么都是短連接。