[[338985]]

本文轉載自微信公眾號「搬運工來架構」，作者cocodroid。轉載本文請聯(lián)系搬運工來架構公眾號。

前言

從HTTP請求超時、重試機制、操作系統(tǒng)網絡等層面剖析了事故的原因，最終解決業(yè)務問題。

這里先拋兩個問題：

1)你遭遇過由于網絡連接或請求超時造成的生產事故嗎?

2)你知道操作系統(tǒng)默認的網絡連接超時是多少秒?

先思考下，可以將你的答案寫在評論區(qū)哦。

問題背景

最近同事出現(xiàn)這么一個問題，簡單業(yè)務場景：

 

服務A使用HTTP請求服務B接口m。服務A起了一個定時任務Task：

從db查詢數(shù)據總共有1200+條，每條記錄對應一次請求，循環(huán)調用m接口。服務B收到請求會使用TCP連接其它服務器機器，進行命令的交互。注意這里并不是異步并發(fā)去請求接口，因為如果異步并發(fā)請求，可能就造成服務B的處理線程很快用光，從而造成不會再很好的處理更多請求，甚至會造成大面積請求超時或服務宕機等等問題。

此時定時任務到時間跑起來了，過不了多久，服務A出現(xiàn)向B請求Hand住，最終出現(xiàn)超時。

 

如下超時日志Read timed out：

 

雖然服務A自身查詢DB等服務是正常的，但是服務A和服務B之間的交互也很重要，如果兩者之間出現(xiàn)問題，必然會對業(yè)務處理或者系統(tǒng)等方面造成影響。

所以到底是為什么，這里涉及了什么問題呢?

問題解決

1、重試機制加快問題出現(xiàn)

此時在服務A上進行排查，通過elk日志發(fā)現(xiàn)異常日志，異常日志數(shù)量激增。如下截圖：

 

異常日志明細：

 

org.apache.http.impl.execchain.RetryExec，由此可知應該跟http重試機制相關。

 

由RetryExec源碼可知，當http執(zhí)行請求時，如果正常請求則立即返回;否則IOException異常時，則進入重試環(huán)節(jié)。

這里要注意下，for循環(huán)進行重試是死循環(huán)的方式，這里的重試次數(shù)由實現(xiàn)者控制，如果無需重試，默認則不會進行重試，而是直接拋出異常。

查看RetryHandler的自定義實現(xiàn)源碼：

@Component 
public class HttpRequestRetryHandlerServer implements HttpRequestRetryHandler { 
   protected static final Logger LOG = LoggerFactory.getLogger(HttpRequestRetryHandlerServer.class); 
   @Override 
   public boolean retryRequest(IOException e, int retryCount, HttpContext httpCtx) { 
      if (retryCount >= 3) { 
         LOG.warn("Maximum tries reached, exception would be thrown to outer block"); 
         return false; 
      } 
      if (e instanceof org.apache.http.NoHttpResponseException) { 
         LOG.warn("No response from server on {} call", retryCount); 
         return true; 
      } 
      return false; 
   } 
} 

從源碼知道，重試次數(shù)最多3次，并且只針對這種異常NoHttpResponseException，從命名知道這是HTTP無響應異常(源碼注釋是：Signals that the target server failed to respond with a valid HTTP response.)。

那么服務A為什么會進入重試流程呢?

由上面的異常知道，可以排除是由于網絡連接超時出現(xiàn)的異常，而是正常請求，但是由于可能某種原因，遲遲沒有得到正常響應結果。由前面的異常Read timed out知道是出現(xiàn)讀超時異常，這里就考慮到可能是跟網絡數(shù)據傳輸?shù)葏?shù)相關。

查看默認配置：

 

由此可知，6秒是數(shù)據傳輸?shù)淖铋L時間(讀超時)。http請求時等待數(shù)據結果如果超過6秒，就會中斷當前的請求，拋出Read timed out異常。所以基本上就可以知道這個異常的原由了。

2、重試機制加快問題-解決方法：

分析當前場景，于是做下調整：

1)由于此場景http請求無需進行重試，則將其關閉：

@Bean 
public CloseableHttpClient noRetryHttpClient(HttpClientBuilder clientBuilder) { 
    // 重試次數(shù)為0，不進行重試 
    clientBuilder.setRetryHandler(new DefaultHttpRequestRetryHandler(0, false)); 
    return clientBuilder.build(); 
} 

2)由于此業(yè)務請求，服務B可能出現(xiàn)超過6秒的處理時長，則socketTimeout調整為15秒：

# http pool config 
http: 
  maxTotal: 500 
  defaultMaxPerRoute: 100 
  connectTimeout: 5000 
  connectionRequestTimeout: 3000 
  socketTimeout: 15000 
  maxIdleTime: 1 
  keepAliveTimeOut: 65 

3、機器連接超時的鍋

 

接下來再排查服務B到底是怎么了?也就是上圖的右側“閃電”。為什么需要這么長的處理時間。

服務A發(fā)起Http請求時，服務B接收請求后進行跟服務器進行連接后交互數(shù)據。服務B與服務機器通信只要是使用Tcp ssh的方式，也就是會進行網絡通信。

經過排查服務B的日志：

 

可知，進行連接服務器時出現(xiàn)異常。注意這個連接耗時時長為：63秒左右。并且確認排查目標服務器確實沒有正常工作，而是已經停機許久。

由于進行的是Unix平臺的網絡連接，當前的操作系統(tǒng)是Linux CentOS。那么為什么這個超時時間是63秒，而不是5秒、15秒、60秒等比較規(guī)整的數(shù)據呢?

此時查看網絡連接的代碼：

connection.connect(); 

可知這里并沒有指定連接超時等參數(shù)，那么應該是使用了操作系統(tǒng)內核的默認參數(shù)了。

Linux 系統(tǒng)默認的建立 TCP 連接的超時時間為 127 秒。這個對于客戶端一般都是比較長了，更多的業(yè)務場景基本不會使用默認值，而是根據業(yè)務場景進行設置合理的連接超時時間。那么這個時間是怎么來的?為什么是127?

其實這個時間參數(shù)是由：net.ipv4.tcp_syn_retries配置的等級來確定的。

net.ipv4.tcp_syn_retries 的設置,表示應用程序進行connect()系統(tǒng)調用時，在對方不返回SYN + ACK的情況下(也就是超時的情況下)，第一次發(fā)送之后，內核最多重試幾次發(fā)送SYN包;并且決定了等待時間。

Linux上的默認值是 net.ipv4.tcp_syn_retries = 6 ,也就是說如果是本機主動發(fā)起連接,(即主動開啟TCP三次握手中的第一個SYN包),如果一直收不到對方返回SYN + ACK ,那么應用程序最大的超時時間就是127秒。

第 1 次發(fā)送 SYN 報文后等待 1s(2 的 0 次冪)，如果超時，則重試;

第 2 次發(fā)送后等待 2s(2 的 1 次冪)，如果超時，則重試;

第 3 次發(fā)送后等待 4s(2 的 2 次冪)，如果超時，則重試;

第 4 次發(fā)送后等待 8s(2 的 3 次冪)，如果超時，則重試;

第 5 次發(fā)送后等待 16s(2 的 4 次冪)，如果超時，則重試;

第 6 次發(fā)送后等待 32s(2 的 5 次冪)，如果超時，則重試;

第 7 次發(fā)送后等待 64s(2 的 6 次冪)，如果超時，則超時失敗。

接下來查看我們的機器上的tcp syn 參數(shù)：

 

而我們的服務器設置的tcp_syn_retries為5，即默認超時為=1+2+4+8+16+32=63秒。剛好與當前問題完美符合，這就是為什么出現(xiàn)63秒超時原由了。

4、那么在Windows平臺，又是怎么樣的呢?

(本來這部分不準備闡述的，希望讀者自行查閱資料，但是還是做個完整的吧。)

因為我是用Windows10作為開發(fā)機器的，所以順便想了解下在Windows平臺下，它的超時時間是多少。寫了個測試用例，一測，竟然是21秒左右。這又是什么原理??

查閱相關資料：

TcpMaxConnectRetransmissions

Determines how many times TCP retransmits an unanswered request for a new connection. TCP retransmits new connection requests until they are answered, or until this value expires.

TCP/IP adjusts the frequency of retransmissions over time. The delay between the original transmission and the first retransmissions for each interface is determined by the value of TcpInitialRTT (by default, it is 3 seconds). This delay is doubled after each attempt. After the final attempt, TCP/IP waits for an interval equal to double the last delay and then abandons the connection request.

TcpInitialRTT

Determines how quickly TCP retransmits a connection request if it doesn't receive a response to the original request for a new connection.

By default, the retransmission timer is initialized to 3 seconds, and the request (SYN) is sent twice, as specified in the value of TcpMaxConnectRetransmissions.

由資料可知，在Windows平臺上是由此參數(shù)：TcpMaxConnectRetransmissions和TcpInitialRTT控制，TcpMaxConnectRetransmissions默認值一般為2，TcpInitialRTT默認是3秒。

也就是會進行2次重試，每次是上次的2倍時間，即21秒為：3+3*2+(3*2)*2=3+6+12=21秒。

通過命令查詢Windows參數(shù)：

netsh interface tcp show global 

 

這個最大SYN重新傳輸次數(shù)我的公司開發(fā)機器是2，但是我的個人機器卻為4(那么默認連接超時時長為：3+6+12+24+48=93秒)，雖然都是Windows10系統(tǒng)，但是為什么不同這個就不得而知了。

5、機器連接超時的鍋-解決方法：

服務B網絡連接服務器時設置連接超時時間為5秒：

connection.connect(null, 5000, kexTimout); 

這樣只要超過5秒還沒能連接上，就做超時異常處理，及早釋放資源，不再阻塞當前處理線程。

6、結果：

通過相關的調整優(yōu)化，重新發(fā)布服務驗證，最終服務穩(wěn)定運行，不會再出現(xiàn)異常等情況。

perfect!

總結

1)雖然這次事故造成的罪魁禍首不是服務A的HTTP重試機制，但是也是它加快了問題的出現(xiàn)速度。

所以我們要清楚是否需要重試機制，如果不需要就不要設置，不然非常浪費資源，甚至會壓垮服務提供方系統(tǒng)等問題。

2)網絡連接一般有TCP和HTTP等，防止超時時間太久影響業(yè)務、甚至造成服務宕機等嚴重問題，一般都要設置合理的超時時間(連接超時時間和數(shù)據傳輸時間等)。

因為操作系統(tǒng)設置的是比較通用的默認參數(shù)，并不會考慮具體的業(yè)務場景。

網絡數(shù)據傳輸時間：具體的業(yè)務場景是非常不同的，比如默認6秒的數(shù)據傳輸時間，在實際的場景下并不一定合理，此時需要根據實際進行調整，比如我這邊的情況是調整為15秒。

網絡連接超時：比如Windows平臺網絡連接超時默認一般是21秒，Linux(Centos)有默認階梯超時機制，默認127秒，而在我這臺機器上則是63秒。

 

3)學習操作系統(tǒng)超時機制。比如Linux或Windows，在連接超時時可以在前面的超時時間增加倍數(shù)，可以學以致用到我們的業(yè)務開發(fā)中去。