Connection reset

在使用HttpClient調用後臺resetful服務時，「Connection reset」是一個比較常見的問題，有同窗跟我私信說被這個問題困擾好久了，今天就來分析下，但願能幫到你們。例如咱們線上的網關日誌就會拋該錯誤：

 

從日誌中能夠看到是Socket套接字在read數據時拋出了該錯誤。

 

致使「Connection reset」的緣由是服務器端由於某種緣由關閉了Connection，而客戶端依然在讀寫數據，此時服務器會返回復位標誌「RST」，而後此時客戶端就會提示「java.net.SocketException: Connection reset」。

可能有同窗對復位標誌「RST」還不太瞭解，這裏簡單解釋一下：

TCP創建鏈接時須要三次握手，在釋放鏈接須要四次揮手；例如三次握手的過程以下：

1. 第一次握手：客戶端發送syn包（syn=j）到服務器，並進入SYN_SENT狀態，等待服務器確認；

2. 第二次握手：服務器收到syn包，並會確認客戶的SYN（ack=j+1），同時本身也發送一個SYN包（syn=k），即SYN+ACK包，此時服務器進入SYN_RECV狀態；

3. 第三次握手：客戶端收到服務器的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），源碼以下：

1 2	httpGet.setProtocolVersion(HttpVersion.HTTP_1_0); httpGet.addHeader(HTTP.CONN_DIRECTIVE, HTTP.CONN_CLOSE);

 

最後再補充幾句，雖然對於每次請求TCP長鏈接只能節約大約1ms的時間，可是具體是使用長鏈接仍是短鏈接仍是要衡量下，好比你的服務天天的pv是1億，那麼使用長鏈接節約的總時間爲：

1	1億*1ms=10^8*1ms=10^5*1s=10^5*1h/3600≈27.78h

神奇的是，億萬級pv的服務使用長鏈接一天內節約的總時間爲27.78小時（居然大於一天）。

因此使用長鏈接仍是短鏈接你們須要根據本身的服務訪問量、擴展性等因素衡量下。可是必定要注意：服務器和客戶端的鏈接必定要保持一致，要麼都是長鏈接，要麼都是短鏈接。