從HTTP請求超時、重試機制、作業系統網路等層面剖析了事故的原因，最終解決業務問題，
這里先拋兩個問題：
1）你遭遇過由于網路連接或請求超時造成的生產事故嗎？
2）你知道作業系統默認的網路連接超時是多少秒？
問題背景
最近同事出現這么一個問題，簡單業務場景：
服務A使用HTTP請求服務B介面m，服務A起了一個定時任務Task：
從db查詢資料總共有1200+條，每條記錄對應一次請求，回圈呼叫m介面，服務B收到請求會使用TCP連接其它服務器機器，進行命令的互動，注意這里并不是異步并發去請求介面，因為如果異步并發請求，可能就造成服務B的處理執行緒很快用光，從而造成不會再很好的處理更多請求，甚至會造成大面積請求超時或服務宕機等等問題，
此時定時任務到時間跑起來了，過不了多久，服務A出現向B請求Hand住，最終出現超時，
如下超時日志Read timed out：
雖然服務A自身查詢DB等服務是正常的，但是服務A和服務B之間的互動也很重要，如果兩者之間出現問題，必然會對業務處理或者系統等方面造成影響，
所以到底是為什么，這里涉及了什么問題呢？
問題解決
1、重試機制加快問題出現
此時在服務A上進行排查，通過elk日志發現例外日志，例外日志數量激增，如下截圖：
例外日志明細：
org.apache.http.impl.execchain.RetryExec，由此可知應該跟http重試機制相關，
由RetryExec原始碼可知，當http執行請求時，如果正常請求則立即回傳；否則IOException例外時，則進入重試環節，
這里要注意下，for回圈進行重試是死回圈的方式，這里的重試次數由實作者控制，如果無需重試，默認則不會進行重試，而是直接拋出例外，
查看RetryHandler的自定義實作原始碼：
@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;
}
}
從原始碼知道，重試次數最多3次，并且只針對這種例外NoHttpResponseException，從命名知道這是HTTP無回應例外（原始碼注釋是：Signals that the target server failed to respond with a valid HTTP response.），
那么服務A為什么會進入重試流程呢？
由上面的例外知道，可以排除是由于網路連接超時出現的例外，而是正常請求，但是由于可能某種原因，遲遲沒有得到正常回應結果，由前面的例外Read timed out知道是出現讀超時例外，這里就考慮到可能是跟網路資料傳輸等引數相關，
查看默認配置：
由此可知，6秒是資料傳輸的最長時間（讀超時），http請求時等待資料結果如果超過6秒，就會中斷當前的請求，拋出Read timed out例外，所以基本上就可以知道這個例外的原由了，
2、重試機制加快問題-解決方法：
分析當前場景，于是做下調整：
1）由于此場景http請求無需進行重試，則將其關閉：
@Bean
public CloseableHttpClient noRetryHttpClient(HttpClientBuilder clientBuilder) {
// 重試次數為0，不進行重試
clientBuilder.setRetryHandler(new DefaultHttpRequestRetryHandler(0, false));
return clientBuilder.build();
}
2）由于此業務請求，服務B可能出現超過6秒的處理時長，則socketTimeout調整為15秒：
# http pool config
http:
maxTotal: 500
defaultMaxPerRoute: 100
connectTimeout: 5000
connectionRequestTimeout: 3000
socketTimeout: 15000
maxIdleTime: 1
keepAliveTimeOut: 65
3、機器連接超時的鍋
接下來再排查服務B到底是怎么了？也就是上圖的右側“閃電”，為什么需要這么長的處理時間，
服務A發起Http請求時，服務B接收請求后進行跟服務器進行連接后互動資料，服務B與服務機器通信只要是使用Tcp ssh的方式，也就是會進行網路通信，
經過排查服務B的日志：
可知，進行連接服務器時出現例外，注意這個連接耗時時長為：63秒左右，并且確認排查目標服務器確實沒有正常作業，而是已經停機許久，
由于進行的是Unix平臺的網路連接，當前的作業系統是Linux CentOS，那么為什么這個超時時間是63秒，而不是5秒、15秒、60秒等比較規整的資料呢？
此時查看網路連接的代碼：
connection.connect();
可知這里并沒有指定連接超時等引數，那么應該是使用了作業系統內核的默認引數了，
Linux 系統默認的建立 TCP 連接的超時時間為 127 秒，這個對于客戶端一般都是比較長了，更多的業務場景基本不會使用默認值，而是根據業務場景進行設定合理的連接超時時間，那么這個時間是怎么來的？為什么是127？
其實這個時間引數是由：net.ipv4.tcp_syn_retries配置的等級來確定的，
net.ipv4.tcp_syn_retries 的設定,表示應用程式進行connect()系統呼叫時，在對方不回傳SYN + ACK的情況下(也就是超時的情況下)，第一次發送之后，內核最多重試幾次發送SYN包;并且決定了等待時間，
Linux上的默認值是 net.ipv4.tcp_syn_retries = 6 ,也就是說如果是本機主動發起連接,(即主動開啟TCP三次握手中的第一個SYN包),如果一直收不到對方回傳SYN + ACK ,那么應用程式最大的超時時間就是127秒，
第 1 次發送 SYN 報文后等待 1s（2 的 0 次冪），如果超時，則重試；
第 2 次發送后等待 2s（2 的 1 次冪），如果超時，則重試；
第 3 次發送后等待 4s（2 的 2 次冪），如果超時，則重試；
第 4 次發送后等待 8s（2 的 3 次冪），如果超時，則重試；
第 5 次發送后等待 16s（2 的 4 次冪），如果超時，則重試；
第 6 次發送后等待 32s（2 的 5 次冪），如果超時，則重試；
第 7 次發送后等待 64s（2 的 6 次冪），如果超時，則超時失敗，
接下來查看我們的機器上的tcp syn 引數：
而我們的服務器設定的tcp_syn_retries為5，即默認超時為=1+2+4+8+16+32=63秒，剛好與當前問題完美符合，這就是為什么出現63秒超時原由了，
4、那么在Windows平臺，又是怎么樣的呢？
（本來這部分不準備闡述的，希望讀者自行查閱資料，但是還是做個完整的吧，）
因為我是用Windows10作為開發機器的，所以順便想了解下在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平臺上是由此引數：TcpMaxConnectRetransmissions和TcpInitialRTT控制，TcpMaxConnectRetransmissions默認值一般為2，TcpInitialRTT默認是3秒，
也就是會進行2次重試，每次是上次的2倍時間，即21秒為：3+32+(32)*2=3+6+12=21秒，
通過命令查詢Windows引數：
netsh interface tcp show global
這個最大SYN重新傳輸次數我的公司開發機器是2，但是我的個人機器卻為4(那么默認連接超時時長為：3+6+12+24+48=93秒)，雖然都是Windows10系統，但是為什么不同這個就不得而知了，
5、機器連接超時的鍋-解決方法：
服務B網路連接服務器時設定連接超時時間為5秒：
connection.connect(null, 5000, kexTimout);
這樣只要超過5秒還沒能連接上，就做超時例外處理，及早釋放資源，不再阻塞當前處理執行緒，
6、結果：
通過相關的調整優化，重新發布服務驗證，最終服務穩定運行，不會再出現例外等情況，
perfect!
總結
1）雖然這次事故造成的罪魁禍首不是服務A的HTTP重試機制，但是也是它加快了問題的出現速度，
所以我們要清楚是否需要重試機制，如果不需要就不要設定，不然非常浪費資源，甚至會壓垮服務提供方系統等問題，
2）網路連接一般有TCP和HTTP等，防止超時時間太久影響業務、甚至造成服務宕機等嚴重問題，一般都要設定合理的超時時間（連接超時時間和資料傳輸時間等），
因為作業系統設定的是比較通用的默認引數，并不會考慮具體的業務場景，
網路資料傳輸時間：具體的業務場景是非常不同的，比如默認6秒的資料傳輸時間，在實際的場景下并不一定合理，此時需要根據實際進行調整，比如我這邊的情況是調整為15秒，
網路連接超時：比如Windows平臺網路連接超時默認一般是21秒，Linux(Centos)有默認階梯超時機制，默認127秒，而在我這臺機器上則是63秒，
3）學習作業系統超時機制，比如Linux或Windows，在連接超時時可以在前面的超時時間增加倍數，可以學以致用到我們的業務開發中去，
看完三件事??
如果你覺得這篇內容對你還蠻有幫助，我想邀請你幫我三個小忙：
-
點贊，轉發，有你們的 『點贊和評論』，才是我創造的動力，
-
關注公眾號 『 java爛豬皮 』，不定期分享原創知識，
-
同時可以期待后續文章ing??
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/236348.html
標籤：Java
上一篇：原來只想簡單看一下String原始碼，沒想到整理了這么多知識點
下一篇：精盡Spring MVC原始碼分析 - HandlerAdapter 組件（一）之 HandlerAdapter