錯(cuò)誤提示

上傳文件程序會(huì)有一定的概率提示錯(cuò)誤，錯(cuò)誤率大概在1%以下，錯(cuò)誤信息是：

org.apache.http.NoHttpResponseException , s3-us-west-1.amazonaws.com:80 failed to respond

看著是上傳到S3的過程中發(fā)送了網(wǎng)絡(luò)錯(cuò)誤？

通過查閱資料，發(fā)現(xiàn)了一篇比較好的文章：一次NoHttpResponseException問題分析解決。這個(gè)文章的觀點(diǎn)是會(huì)發(fā)生這個(gè)錯(cuò)誤的原因是服務(wù)端關(guān)閉了連接，而客戶端還在使用該連接，導(dǎo)致服務(wù)端響應(yīng)RST報(bào)文，客戶端收到RST報(bào)NoHttpResponseException異常。

Keepalive機(jī)制

為了說明這個(gè)場(chǎng)景，就要提一下Keepalive機(jī)制。Keepalive是HTTP的連接復(fù)用機(jī)制，在HTTP1.0時(shí)代，每個(gè)請(qǐng)求經(jīng)過三次握手后，只會(huì)傳輸一次HTTP請(qǐng)求和響應(yīng)報(bào)文后，就進(jìn)入四次揮手關(guān)閉連接了。而TCP建立連接和關(guān)閉連接的代價(jià)是比較大的，導(dǎo)致HTTP1.0的通道利用率較低，時(shí)延較高。針對(duì)這個(gè)問題，退出了Keepalive機(jī)制，一個(gè)TCP連接建立后，可以在上面發(fā)送多個(gè)HTTP報(bào)文，只有這個(gè)TCP連接的空閑時(shí)間達(dá)到超時(shí)時(shí)間，才會(huì)被關(guān)閉。HTTP1.1默認(rèn)開啟Keepalive。這里的關(guān)閉行為可能發(fā)生在客戶端和服務(wù)端，比如客戶端的Keepalive超時(shí)時(shí)間更短，則客戶端就會(huì)先關(guān)閉連接，如果服務(wù)端配置的Keepalive超時(shí)時(shí)間更短，則服務(wù)端就會(huì)先關(guān)閉連接。

乍看起來無論那一邊關(guān)閉連接都沒什么問題，但是還是有細(xì)節(jié)需要注意。比如服務(wù)端關(guān)閉連接，發(fā)送FIN包，在這個(gè)FIN包發(fā)送但是還未到達(dá)客戶端期間，客戶端如果繼續(xù)復(fù)用這個(gè)TCP連接，發(fā)送HTTP請(qǐng)求報(bào)文的話，服務(wù)端會(huì)因?yàn)樵谒拇螕]手期間不接收?qǐng)?bào)文而發(fā)送RST報(bào)文給客戶端，客戶端收到RST報(bào)文就會(huì)提示異常。

根據(jù)上面的理論知識(shí)，可以推測(cè)org.apache.http.NoHttpResponseException , s3-us-west-1.amazonaws.com:80 failed to respond這個(gè)錯(cuò)誤發(fā)生的原因是因?yàn)槲业某绦虻腍ttpClient的Keepalive時(shí)間大于S3服務(wù)器的，導(dǎo)致S3服務(wù)端關(guān)閉連接時(shí)，可能發(fā)生異常。我們做個(gè)試驗(yàn)看看。

觀察AWS S3服務(wù)端的Keepalive時(shí)間

首先寫一個(gè)簡(jiǎn)單程序觀察一下AWS S3服務(wù)端的Keepalive時(shí)間

String url = "一個(gè)可以訪問的S3下載地址";
CloseableHttpClient httpClient = HttpClients.createDefault();
HttpGet request = new HttpGet(url);
httpClient.execute(request, response -> {
    String content = EntityUtils.toString(response.getEntity());
    System.out.println(content);
    return content;
});
Thread.sleep(99999);

Wireshark抓包觀察HTTP響應(yīng)報(bào)文后，經(jīng)過多久進(jìn)入四次揮手：

可以看出服務(wù)端發(fā)送FIN包距離上一個(gè)請(qǐng)求的時(shí)間大概是23秒，也就是AWS S3服務(wù)端的Keepalive時(shí)間大致為23秒。

接著我們模擬客戶端在服務(wù)端關(guān)閉連接的同時(shí)發(fā)送請(qǐng)求的場(chǎng)景，看看能否復(fù)現(xiàn)NoHttpResponseException錯(cuò)誤：

String url = "http://s3-us-west-1.amazonaws.com/sdpcs-prod-awsca/88ea9001-bad0-4b46-86e5-e6bc518c9fdc?Expires=1718171230&response-content-type=image/jpeg&response-cache-control=max-age%3D157680000&AWSAccessKeyId=AKIAI7P7PYLVYWVVYTLQ&Signature=iCeE6%2FIHtxmOarOc3Q1hUowWqDc%3D";
CloseableHttpClient httpClient = HttpClients.createDefault();
HttpGet request = new HttpGet(url);
for (int i = 0; i < 100000; i++) {
    httpClient.execute(request, response -> {
        String content = EntityUtils.toString(response.getEntity());
        System.out.println(content);
        return content;
    });
    Thread.sleep(23000);
}

多執(zhí)行幾次，就能復(fù)現(xiàn)出NoHttpResponseException錯(cuò)誤：

六月 14, 2019 2:09:14 下午 org.apache.http.impl.execchain.RetryExec execute
信息: I/O exception (org.apache.http.NoHttpResponseException) caught when processing request to {}->http://s3-us-west-1.amazonaws.com:80: The target server failed to respond
六月 14, 2019 2:09:14 下午 org.apache.http.impl.execchain.RetryExec execute
信息: Retrying request to {}->http://s3-us-west-1.amazonaws.com:80

分析抓包

可以看到2400號(hào)請(qǐng)求距離上一個(gè)請(qǐng)求23秒，然后在服務(wù)端還未收到2400號(hào)請(qǐng)求時(shí)，客戶端就收到了服務(wù)端發(fā)來的FIN請(qǐng)求，進(jìn)入了四次揮手流程。然后當(dāng)服務(wù)端收到2400號(hào)請(qǐng)求后，響應(yīng)RST請(qǐng)求，導(dǎo)致客戶端提示錯(cuò)誤。

HttpClient提供了關(guān)閉空閑連接的功能

CloseableHttpClient httpClient = HttpClients.custom()
                .evictIdleConnections(5, TimeUnit.SECONDS)
                .build();

我們?cè)O(shè)置一個(gè)低于S3 Keepalive的時(shí)間再次執(zhí)行，就不會(huì)出現(xiàn)NoHttpResponseException錯(cuò)誤了。

除了在客戶端設(shè)置小于服務(wù)端的Keepalive時(shí)間，還有一種做法是在出現(xiàn)NoHttpResponseException時(shí)進(jìn)行重試，也是可以的，還可以減少TIME_WAIT數(shù)量。

以上就是NoHttpResponseException問題排查解決記錄分析的詳細(xì)內(nèi)容，更多關(guān)于NoHttpResponseException問題排查的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章！

最新評(píng)論