形单影只的 Socket

最近工作上遇到过几次因 http client 没有配置相关超时参数，导致线程数占满或应用卡住的情况，出问题时线程的堆栈大致是这样的：

程序卡在了 上，我们线上版本用的是 httpclient 4.4.5，配置下面参数即可：

上面设置了三个超时时间，含义分别是

Connection Timeout，表示与远端服务期建立连接的超时

Socket Timeout，表示连接上两个 packet 之间的超时，当空闲时间超过这个后该连接就会自动断开

Connection Manager Timeout，表达从连接池申请连接时的超时

好了，其实这不是这篇文章的重点，重点时在 debug 这个问题时，发现的一个有趣现象，为了弄清问题缘由，需要先回顾下 socket 编程的基本知识。

Socket 定义

计算机领域里的 socket ，表示可以进行通讯的两个程序，一般称为 endpoint，如果是同一台机器上，则对应 Unix domain socket，如果是不同机器，则为 network socket，一方称为 client，另一方称为 server。

对于 TCP socket 来说，使用流程如下：

连接建立后，可以通过 ss 命令查看到

由于 socket 涉及两端，每一端用 ip + port 去标示，再加上两端通讯的协议，所以需要用五个字段来区分，在一般表述为

形单影只的 socket

经过上面的介绍，往往会以为 TCP socket 都是成对出现的，毕竟有两方参与，这也符合 99.99% 的场景，但是 TCP 协议在定义时，并没有严格要去通讯双方必须为不同的程序，也就是说只要符合 TCP 状态机的模型，就可以做到自己与自己通讯。通过下面一示例可以证明：

上面示例在开始运行时一直失败，说明 11111 端口没有被 LISTEN，所以连接一直失败，但是在某一时刻突然就连上了！还是请出我们的老朋友 ss 看看怎么回事

额，竟然只有一个 socket！这时的 nc 命令同时兼具了 server 与 client 两个角色，这时其实是个 echo server，输会什么，就好输会什么。

这看上去有些不可思议，为了弄清问题，可以通过 tcpdump 来分析连接是怎么建立的。

然后通过 Wireshark 打开得到的 pcap 文件，发现了著名的「三次握手」

虽然第二个 packet 显示为 out of order，但是并没有影响该 socket TCP 状态的转移！

这里需要再介绍下 TCP 状态转移过程：

当出于 close 状态的 socket 发出 包后，会处于 状态，这时如果收到 并回复 包后，就会处于 。

可以看到，一个 socket 竟然就可以完成「三次握手」！

那么能不能复现「四次挥手」呢？直接 结束上面的 nc 进程，然后再通过 tcpdump+wireshark 可以得到下面的结果：

通过 ss 命令也没找到处于 TIME-WAIT 状态的 11111，说明进行的是「被动关闭」（状态转移图右下脚）流程。

结论

看完本文的一点“实用”干货可能是解释为什么不要去 LISTEN 比较高的端口，但是更希望大家能多去动手，发现隐藏在表象下的根源，这其实和脱单是一个道理 -:)

最后，祝18周岁以上的朋友今年是最后一个“光棍节”！

参考

https://www.baeldung.com/httpclient-timeout

https://blog.cloudflare.com/this-is-strictly-a-violation-of-the-tcp-specification/

https://linux.die.net/man/8/ss