记一次Apache HTTP Client问题排查

现象

通过日志查看，存在两种异常情况。

第一种：开始的时候HTTP请求会报超时异常。

❝

762663363 [2023-07-21 06:04:25] [executor-64] ERROR - com.xxl.CucmTool - CucmTool|sendRisPortSoap error,url:https://10.65.0.173:8443/realtimeservice/services/RisPortorg.apache.http.conn.HttpHostConnectException: Connect to xxx [/xxx] failed: 连接超时

❞

第二种：突然没有新的HTTP请求日志了，现象就是HTTP请求后，一直卡主，等待响应。

HTTP Client代码

先查看一下HTTP的请求代码。

HTTP Client设置。

private static CloseableHttpClient getHttpClient() {
    SSLContextBuilder builder = new SSLContextBuilder();
    CloseableHttpClient httpClient = null;
    try {
        builder.loadTrustMaterial(null, new TrustStrategy() {
            @Override
            public boolean isTrusted(X509Certificate[] chain, String authType) throws CertificateException {
                return true;
            }
        });
        SSLConnectionSocketFactory sslsf = new SSLConnectionSocketFactory(builder.build(),
            SSLConnectionSocketFactory.ALLOW_ALL_HOSTNAME_VERIFIER);
        httpClient = HttpClients.custom().setSSLSocketFactory(sslsf).build();
    } catch (Exception e) {
        log.error("getHttpClient error:{}", e.getMessage(), e);
    }
    return httpClient;
}

「请求方式（未设置http connection timeout 和 socket timeout)」

HttpPost httpPost = new HttpPost(url);
try(CloseableHttpResponse response = getHttpClient().execute(httpPost)) {
    HttpEntity httpEntity = response.getEntity();
    if (httpEntity != null) {
        System.out.println(EntityUtils.toString(httpEntity, "UTF-8"));
    }
} catch (Exception e) {
    log.error("test,url:" + url, e);
}

进一步分析。

连接超时

通过本地debug先找到了socket连接处的代码，如下所示。

socket连接请求在java.net.Socket#connect(java.net.SocketAddress, int)这里。

可以看到如果不设置connect timeout，在java层面默认是无限超时，那实际是要受系统层面影响的。我们都知道TCP建立连接的第一步是发送syn，实际这一步系统层面会有一些控制。

Linux环境

linux下通过net.ipv4.tcp_syn_retries控制sync的超时情况

❝

Number of times initial SYNs for an active TCP connection attempt will be retransmitted. Should not be higher than 127. Default value is 6, which corresponds to 63seconds till the last retransmission with the current initial RTO of 1second. With this the final timeout for an active TCP connection attempt will happen after 127seconds.

❞

默认重试次数为6次，重试的间隔时间从1s开始每次都翻倍，6次的重试时间间隔为1s, 2s, 4s, 8s, 16s，32s, 总共63s，第6次发出后还要等64s都知道第6次也超时了，所以，总共需要 1s + 2s + 4s+ 8s+ 16s + 32s + 64 = 127 s，TCP才会把断开这个连接。
第 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 次幂），如果超时，则断开这个连接。

mac环境

mac场景下是通过net.inet.tcp.keepinit参数控制syn超时（默认是75s)。
可以通过下面的命令查看

sysctl -A |grep net.inet.tcp.keepinit

net.inet.tcp.keepinit: 75000。

通过telnet验证，确实是75s超时。

tcpdump抓包也可以看到一直进行syn重试。

读取超时

Apache Http Client 默认的socket read timeout 是0。

通过代码注释可以看到，如果soTimeout是0的话，就意味着读取超时不受限制，但是实际上这里也会有系统层面的控制，下面从HTTP层面和TCP层面做一下分析。

HTTP Keep-alive

首先，Apache httpClient 4.3版本中，如果请求中未做制定，那么默认会使用HTTP 1.1，代码如下。

public static ProtocolVersion getVersion(HttpParams params) {
    Args.notNull(params, "HTTP parameters");
    Object param = params.getParameter("http.protocol.version");
    return (ProtocolVersion)(param == null ? HttpVersion.HTTP_1_1 : (ProtocolVersion)param);
}

对于HTTP 1.1版本来说，默认会开启Keep-alive，并使用默认的keep-alive策略。

public class DefaultConnectionKeepAliveStrategy implements ConnectionKeepAliveStrategy {

    public static final DefaultConnectionKeepAliveStrategy INSTANCE = new DefaultConnectionKeepAliveStrategy();

    public long getKeepAliveDuration(final HttpResponse response, final HttpContext context) {
        Args.notNull(response, "HTTP response");
        final HeaderElementIterator it = new BasicHeaderElementIterator(
            response.headerIterator(HTTP.CONN_KEEP_ALIVE));
        while (it.hasNext()) {
            final HeaderElement he = it.nextElement();
            final String param = he.getName();
            final String value = he.getValue();
            if (value != null && param.equalsIgnoreCase("timeout")) {
                try {
                    return Long.parseLong(value) * 1000;
                } catch(final NumberFormatException ignore) {
                }
            }
        }
        return -1;
    }

}

其基本原理就是HTTP场景下，当客户端与服务端建立TCP连接以后，Httpd守护进程会通过keep-alive timeout时间设置参数，一个http产生的tcp连接在传送完最后一个响应后，如果守护进程在这个keepalive_timeout里，一直没有收到浏览器发过来http请求，则关闭这个http连接。
这里有两点要注意：

• 可以看到keep-alive的超时时间是服务端返回时，http client在响应头中解析到的。如果一直未收到服务端响应，那么客户端会认为keep-alive一直有效；-1的返回值也是如此。
• 如果服务端有响应，如果服务端有响应，那么就会按照服务端的返回设置keep-alive的timeout，当timeout到期后，就会从http client pool中移除，服务端关闭该TCP连接。

下面是一个成功的HTTP client响应信息，可以看到服务端给出的keep-alive时间是60s。

后续对于这个连接不做任何处理，可以看到60s以后断开了连接。

TCP下的keep-alive机制

TCP连接建立之后，如果某一方一直不发送数据，或者隔很长时间才发送一次数据，当连接很久没有数据报文传输时如何去确定对方还在线，到底是掉线了还是确实没有数据传输，连接还需不需要保持，这种情况在TCP协议设计中keep-alive的目的。
TCP协议中，当超过一段时间之后，TCP自动发送一个数据为空的报文（侦测包）给对方，如果对方回应了这个报文，说明对方还在线，连接可以继续保持，如果对方没有报文返回，并且重试了多次之后则认为连接丢失，没有必要保持连接。
在Linux系统中有以下配置用于TCP的keep-alive。

❝

tcp_keepalive_time=7200：表示保活时间是 7200 秒（2小时），也就 2 小时内如果没有任何连接相关的活动，则会启动保活机制
tcp_keepalive_intvl=75：表示每次检测间隔 75 秒；
tcp_keepalive_probes=9：表示检测 9 次无响应，认为对方是不可达的，从而中断本次的连接。
也就是说在 Linux 系统中，最少需要经过 2 小时 11 分 15 秒才可以发现一个「死亡」连接。

❞

在MAC下对应的配置如下(单位为ms)

❝

net.inet.tcp.keepidle: 7200000
net.inet.tcp.keepintvl: 75000
net.inet.tcp.keepcnt: 3

❞

也就是说在Mac系统中，最少经过2小时3分钟45秒才可以发现一个「死亡」连接。

对于TCP的keep-alive是默认关闭的，可以通过应用层面打开。
对于Java应用程序，默认是关闭的，后面我们模拟在客户端开启该配置。

❝

public static final SocketOption SO_KEEPALIVE Keep connection alive. The value of this socket option is a Boolean that represents whether the option is enabled or disabled. When the SO_KEEPALIVE option is enabled the operating system may use a keep-alive mechanism to periodically probe the other end of a connection when the connection is otherwise idle. The exact semantics of the keep alive mechanism is system dependent and therefore unspecified. The initial value of this socket option is FALSE. The socket option may be enabled or disabled at any time.

❞

首先，修改mac的keep-alive设置，将时间调短一些。

sysctl -w net.inet.tcp.keepidle=60000 net.inet.tcp.keepcnt=3 net.inet.tcp.keepintvl=10000 

❝

net.inet.tcp.keepidle: 60000
net.inet.tcp.keepintvl: 10000
net.inet.tcp.keepcnt: 3

❞

依然通过HTTP Client开启keep alive配置

SocketConfig socketConfig = SocketConfig.DEFAULT;
SocketConfig keepAliveConfig = SocketConfig.copy(socketConfig).setSoKeepAlive(true).build();
httpClient = HttpClients.custom().setSSLSocketFactory(sslsf).setDefaultSocketConfig(keepAliveConfig).build();

通过HTTP Client请求服务端一个耗时很长的接口，并通过TCP抓包可以看到以下内容
每隔60s，客户端会向服务端发送保活的连接。

再来验证一下，如果服务端此时不可用的情况。

使用pfctl工具，模拟服务端不可达。

可以看到客户端每隔10s，累计尝试3次，然后就会关闭该连接。

回归问题

连接超时问题

此时服务器因为个别原因，无法正常连接。
由于HTTP Client未设置对应的超时时间，所以会依据系统的net.ipv4.tcp_syn_retries进行重试。
该异常客户端可以感知到。

请求卡主问题

当某个时间HTTP Client与服务器建立的正常的TCP连接后，服务器发生了异常，此时由于以下原因叠加

• HTTP Client未设置socket读取超时时间
• HTTP keep-alive也由于服务端未响应默认不受限制
• 另外TCP层面的keep alive也没有手动开启

所以此时客户端会一直持有该TCP连接等待服务器响应。对应到下图的话，也就是橙色部分。

当然最直接的解决方案就是设置socket read timeout时间即可。

RequestConfig requestConfig = RequestConfig.custom()
    .setConnectionRequestTimeout(1000)
    .setSocketTimeout(1000)
    .setConnectTimeout(1000).build();
httpPost.setConfig(requestConfig);

当时间到了会报read timeout 异常。

总结

• 当我们使用HTTP Client的时候，需要结合业务需要合理设置connect timeout和 socket timeout参数。
• 当进行问题追踪时，需要利用HTTP和TCP的一些知识，以及tcpdump等抓包工具进行问题验证。