客户端访问ES集群会出现Connection reset by peer 或者 listener timeout after waiting for 30000 ms
(centos7)的tcp keepalive配置 net.ipv4.tcp_keepalive_time = 7200
也就是说如果一条tcp连接超过2小时没有流量的话，系统就会主动去探测该条连接进行保活，但是保活的请求直接发送到网关，网关是不会直接回复的，所以可以抓到上面的在连续发送了9次探活报文没有得到响应后直接回复了RST报文给网关，从而断掉了tcp连接。
es的High Level Rest Client的代码，该客户端会使用到client连接池，默认有30个实例，每个client持有一个http连接，并且开启http的keep-alive策略复用连接。但是问题是该客户端是不会对连接进行探测保活的，也就是连接池里可能会存在2小时没有流量的连接；并且客户端也不会主动剔除连接池里实际已经不可用的连接，例如本例中出现的被服务端主动回复RST断掉的连接，因此在客户端如果使用了连接池里已经不可用的连接的时候，会出现connection reset by peer的报错。
实际上是需要客户端主动的开启tcp keepalive, 进行连接保活，使得连接池里的不会出现超过2小时没有流量的连接，也使得服务端不会再显式的对与网关之间的tcp请求进行探测保活。而经过google发现es开源社区也有针对类似问题的讨论：在经过网关或者负载均衡器访问集群时，会偶现SocketTimeoutException或者connection reset by peer (https://github.com/elastic/elasticsearch/issues/59261), 而经过讨论后，社区里的研发决定给es的High Level Rest client默认开启tcp keepalive策略来解决这类问题(https://github.com/elastic/elasticsearch/issues/65213)，而在实现这个功能之前，临时的解决办法是：
第一步，在客户端代码中显式的开启tcp keepalive选项: setSoKeepAlive(true)
第二步，设置系统层面的tcp keepalive探测保活时间为300s, 也就是每隔5分钟发送一次探活报文，因为默认的7200s时间太长了，有可能会被网关主动断掉连接。
注意：本文归作者所有，未经作者允许，不得转载
