前段时间和其它系统做联调测试，对方系统采用的是负载均衡模式。调试时采用的是多台手机作为客户端发送到对方负载均衡服务器，然后再把报文转发送到我这边的服务端。在测试的时候，对方测试人员说有的手机客户端会偶尔出现报文发不过来的情况。

故事有点长，先发一张tcp三次握手的过程图镇楼~

1 自己服务端的socket监听出现问题

一开始认为可能是自己作为服务端的监听有问题，因为后面排查监听端口的时候发现了close_wait的情况。当时没多想，认为对方负载均衡不会出错（先前跟其它系统联调过了），就急着解决close_wait的问题去了。

可是后面测试的时候，尽管服务端监听没有任何异常，但是手机APP还是有发包失败的情况，而且怪异的是服务端日志也没打印请求包内容。

2 防火墙只收到对方系统的一个IP记录

折腾了很久还是没找到原因所在，后面联系了对方系统测试人员得到回复说他们的日志报错：

java.net.SocketTimeoutException: SocketTimeoutException invoking https://123.123.123.214:7070: connect timed out

于是联系网络管理员，看防火墙是否拒掉了对方请求报文。结果网管回复防火墙正常，但是只收到对方的一台IP记录，另一IP没有发送过报文。

立即反映给对方开发人员，结果对方发现是负载均衡系统的一台服务器连接我这边系统的网络有问题。

3 问题的总结

到这里问题已经解决了，但是自己对于tcp出现Connection timed out的错误认识不足，只想到是自己服务端close_wait引起的问题。下面是自己对tcp握手过程中出现Connection refused和Connection timed out的总结。

3.1 Connection refused

使用telnet来检查tcp链路时，如果遇到"Connection refused"的错误，那么表示从本地客户端到目标IP地址的路由是正常的，但是该目标端口没有进程在监听，然后服务端拒绝掉了连接。

一个成功的tcp链接将会看到Syn，Syn-Ack，Ack，这也就是我们预期的TCP三次握手。当使用tcpdump或wireshark抓包工具来探测发送过来的请求报文包时，Connection refused将会看到Syn,Rst。

3.2 Connection timed out

如果telnet的时候，TCP路由不正常，那么会得到一个Connection timed out的错误。"Couldn't connect"原因有很多，可能是服务器无法ping通，可能是服务器（防火墙等）丢弃了该请求报文包，也可能是服务器应答太慢，又或者存在间歇性的问题（这种情况很难从日志文件中排查问题）。

下面演示“Connection timed out”的情况：

# 先打开一个ssh会话，telnet任意一个不存在IP
[root@typecodes ~]# telnet 10.10.223.123 9010
Trying 10.10.223.123...

# 然后打开另一个ssh会话，netstat服务器上tcp连接状况
[root@typecodes ~]# netstat -anpt
tcp        0      1 10.169.218.97:53794     10.10.223.123:9010      SYN_SENT    4271/telnet

由下图可知，telnet进程作为客户端发送SYN包后，进入SYN_SENT状态，等待服务端应答。

但是由于客户端和目标IP的路由无法建立（也就是BZ遇到的情况），所以在3分钟后该tcp链路显示Connection timed out。