现象

通过日志查看，存在两种异常情况。
第一种：开始的时候HTTP请求会报超时异常。

第二种：突然没有新的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的超时情况

默认重试次数为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。

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

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

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

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

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

依然通过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等抓包工具进行问题验证。

参考文档

【1】一文说清楚 Linux TCP 内核参数_linux tcp参数_DBA大董的博客-CSDN博客
【2】服务端挂了，客户端的 TCP 连接还在吗？
【3】JAVA socket keep alive 说明https://docs.oracle.com/javase/8/docs/api/java/net/StandardSocketOptions.html#SO_KEEPALIVE