最近观察到日志上偶现一个错误：
feign.RetryableException: connect timed out executing POST http://service_name/a/b
java.net.SocketTimeoutException: connect timed out
该问题很清晰，就是发起http请求时，构建TCP连接时发生了超时问题。
由于是偶现的，频率不高所以一开始没有足够重视，直到上了k8s之后频率颇高。一开始没有把这个问题聚焦到配置ribbon.ConnectionTimeout参数上，因为默认使用的统一配置，没成想居然这里有个小坑。
为了排查该问题，我找到运维同学在生产环境低峰期通过tcpdump命令进行抓包，参考命令如下：tcpdump -i eth0 dst host \( ....(IP地址).. \) and port 5000 -w /root/connect_timeout.cap &，由于是偶现的问题，所以抓包过程时间较长，所幸在低峰期出现了一次。在几百兆的里找哪些有问题的包，确实不好找。
好在我们异常调用栈了打印了案发现场的时间：2021-07-05 09:20:35.954 ERROR 1 --- [nio-5000-exec-3]
使用wireshake前，我调整了两个配置项：
1、修改View -> Time Diaplay Formate，选择Date and Time of Day
2、修改Preferences -> Protocols -> TCP，去掉Relative sequence number
通过时间找到了两个非常可疑的包，如下：
为何说这两个包可疑：
1、它的时间跟异常调用栈的时间很接近，一秒左右的时间。
2、它只有SYN包，其他包没有，一个正常的http请求必须是完整的三次握手在前。
3、它向服务方发送了RST包。
胡思乱想：
1、在34秒的时候发出SYN包，之后等待服务端响应ACK包
2、在1秒后由于没有收到ACK包，所以响应了ConnectinTimeout超时？要满足这里，应用程序需要将ConnectinTimeout设置为1秒
3、在超时异常后，客户端终止了本次TCP连接的建立，但是此时收到了服务端的ACK包。（由于运维同学的命令写的有问题，导致没有把服务端的ACK包抓下来，去掉dst即可）
4、客户端收到这个包之后，由TCP协议栈回复了服务端一个RST包终止连接的建立。
那么ConnectinTimeout导致配置了多少？程序上找了半天也没有找到相关的配置，只找到一个配置项如下ribbon.ReadTimeout: 2000，那么默认的ConnectinTimeout是多少？没成想居然真的是1s，如下图：
猜测
将ConnectinTimeout上调5s将会出现什么情况？ 理论上在建立TCP连接时发送SYN将会由于超时而重复发送，重试次数配置参数为net.ipv4.tcp_syn_retries，我们的机器默认是6，而重试的是具备时间间隔的，大致为【1,3,7,15,31,63】,间隔为s。
- 所以如果
SYN持续丢包，最多将会见到6个TCP Retransmission - 综合当前的情况来看，可能会在1s, 之后收到来自服务端的
ACK包，此时即可完成连接的建立， - 如果未收到则大概会在第二次发出重复
SYN包后超时，之后再收到服务端ACK将会回复RST包
最终我将
ConnectiTimeout调整为3s，这两天抓包观察，偶尔可以看到一个重发的syn包，与猜测基本一致。
