最近工作上遇到过几次因 http client 没有配置超时相关参数，导致线程数占满或应用卡住的情况，出问题时线程的堆栈大致是这样的：
1"qtp325266363-35729" #35729 prio=5 os_prio=0 tid=0x00007f5154033000 nid=0x1cf8f runnable [0x00007f4f7f511000]
2 java.lang.Thread.State: RUNNABLE
3 at java.net.SocketInputStream.socketRead0(Native Method)
4 at java.net.SocketInputStream.socketRead(SocketInputStream.java:116)
5 at java.net.SocketInputStream.read(SocketInputStream.java:171)
6 at java.net.SocketInputStream.read(SocketInputStream.java:141)
7 at sun.security.ssl.InputRecord.readFully(InputRecord.java:465)
8 at sun.security.ssl.InputRecord.read(InputRecord.java:503)
9 at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:983)
10 - locked <0x00000006e1494d68> (a java.lang.Object)
11 at sun.security.ssl.SSLSocketImpl.readDataRecord(SSLSocketImpl.java:940)
12 at sun.security.ssl.AppInputStream.read(AppInputStream.java:105)
13 - locked <0x00000006e1496d88> (a sun.security.ssl.AppInputStream)
14 at org.apache.http.impl.conn.LoggingInputStream.read(LoggingInputStream.java:84)
15 at org.apache.http.impl.io.SessionInputBufferImpl.streamRead(SessionInputBufferImpl.java:137)
16 at org.apache.http.impl.io.SessionInputBufferImpl.fillBuffer(SessionInputBufferImpl.java:153)
17 at org.apache.http.impl.io.SessionInputBufferImpl.readLine(SessionInputBufferImpl.java:282)
18 at org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:138)
19 at org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:56)
20 at org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:259)
21 at org.apache.http.impl.DefaultBHttpClientConnection.receiveResponseHeader(DefaultBHttpClientConnection.java:163)
程序卡在了 socketRead0 上，我们线上版本用的是 httpclient 4.4.5，配置下面参数即可：
1int timeout = 5;
2RequestConfig config = RequestConfig.custom()
3 .setConnectTimeout(timeout * 1000)
4 .setConnectionRequestTimeout(timeout * 1000)
5 .setSocketTimeout(timeout * 1000).build();
6CloseableHttpClient client =
7 HttpClientBuilder.create().setDefaultRequestConfig(config).build();
上面设置了三个超时时间，含义分别是
- Connection Timeout，表示与远端服务期建立连接的超时
- Socket Timeout，表示连接上两个 packet 之间的超时，当空闲时间超过这个后该连接就会自动断开
- Connection Manager Timeout，表示从连接池申请连接时的超时
好了，其实这不是这篇文章的重点，重点是在 debug 这个问题时，发现的一个有趣现象，为了阐述该现象，需要先回顾下 socket 编程的基本知识。
Socket 定义
计算机领域里的 socket ，表示可以进行通讯的两个程序，一般称为 endpoint，如果是同一台机器上，则对应 Unix domain socket，如果是不同机器，则为 network socket，一方称为 client，另一方称为 server。
对于 TCP socket 来说，使用流程如下：
连接建立后，可以通过 ss 命令查看到
1# 3000 端口为一 Java 写的 HTTP Server，35050 为 curl 访问时随机选择的本地端口
2$ ss -np | grep 3000
3Netid State Recv-Q Send-Q Local Address:Port Peer Address:Port
4tcp ESTAB 0 0 127.0.0.1:35050 127.0.0.1:3000 users:(("curl",12436,3))
5tcp ESTAB 0 0 127.0.0.1:3000 127.0.0.1:35050 users:(("java",12279,82))
由于 socket 涉及两端，每一端用 ip + port 去标示，再加上通讯协议，所以需要用五个字段来标示，一般表述为
1# protocol 一般为 tcp/udp
2(protocol, src_ip:src_port, dst_ip:dst_port)
形单影只的 socket
经过上面的介绍，往往会以为 TCP socket 都是成对出现的，毕竟有两方参与。这也符合 99.99% 的场景，但是 TCP 协议在定义时，并没有严格要通讯双方必须为不同的程序，也就是说只要符合 TCP 状态机的模型，就可以做到自己与自己通讯（即 ESTABLISHED 状态）。通过下面一示例可以证明：
1$ while true; do nc -v localhost 11111; done
2...
3...
4nc: connect to localhost port 11111 (tcp) failed: Connection refused
5nc: connect to localhost port 11111 (tcp) failed: Connection refused
6nc: connect to localhost port 11111 (tcp) failed: Connection refused
7nc: connect to localhost port 11111 (tcp) failed: Connection refused
8Connection to localhost 11111 port [tcp/*] succeeded!
上面示例在开始运行时一直失败，说明 11111 端口没有被 LISTEN，所以连接一直失败，但是在某一时刻突然就连上了！还是请出我们的老朋友 ss 看看怎么回事
1$ ss -np | grep 11111
2tcp ESTAB 0 0 127.0.0.1:11111 127.0.0.1:11111 users:(("nc",8419,3))
额，竟然只有一个 socket！这时的 nc 命令同时兼具了 server 与 client 两个角色，这时其实是个 echo server，输入什么，就会输出什么。
这看上去有些不可思议，为了弄清问题，可以通过 tcpdump 来分析连接是怎么建立的。
1$ sudo tcpdump -i any port 11111 -Snw /tmp/debug.pcap -vvv
2
3# 新开另一个窗口，输入
4$ nc -vp 11111 localhost 11111
5Connection to localhost 11111 port [tcp/*] succeeded!
6# 这里通过 -p 选项制定了 client 的端口号，方便快速浮现问题
然后通过 Wireshark 打开得到的 pcap 文件，发现了著名的「三次握手」
虽然第二个 packet 显示为 out of order，但是并没有影响该 socket TCP 状态的转移！
这里需要再复习下 TCP 状态转移过程：
当处于 close 状态的 socket 发出 SYN 包后，会处于 SYN_SENT 状态，这时如果收到 SYN,ACK 并回复 ACK 包后，就会处于 ESTABLISHED。
可以看到，一个 socket 竟然就可以完成上述步骤。
那么能不能复现「四次挥手」呢？直接 Ctrl+C 结束上面的 nc 进程，然后再通过 tcpdump+wireshark 可以得到下面的结果：
通过 ss 命令也没找到处于 TIME-WAIT 状态的 11111，说明进行的是「被动关闭」（状态转移图右下角）流程。
结论
看完本文的一点“实用”干货可能是解释为什么不要去 LISTEN 比较高的端口，但是更希望大家能多去动手，发现隐藏在表象下的根源，这其实和脱单是一个道理 -:)
最后，留个“动手”问题给大家思考：
如何找出一个已经 ESTABLISHED 的 TCP 连接建立时间与最后一次通讯（即有数据传输）的时间？
在这里 提供一种解决思路。