背景
我们都知道，基于Kubernetes的微服务，大行其道，传统部署模式一直都在跟着变化，但其实，在原有业务向服务化方向过度过程中，有些场景可能会变得复杂。
比如说：将Kubernetes的模式应用到开发环节上，这个环节需要频繁的变更代码，微服务的方式，可能就需要不断的：
改代码->构建镜像->镜像推送->部署->拉去镜像->生成容器
尤其是PHP的业务，不需要构建二进制，仅需要发布代码，因此，如果按照上面的部署方式，就需要频繁改代码，走构建镜像这个流程，最后再做发布，这在开发环节就显得过于麻烦了，换而言之，有没有办法，能让开发直接将代码上传到容器中呢？
其实是有的，就是设计一个FTP中间件代理，让用户本地改完代码，通过FTP客户端（很多IDE是支持FTP的）直接上传到容器内部，甚至于用户保存一下代码就上传到容器内。
因此，这就引出了今天的主角，是我基于FTP协议+gRPC协议自研的FTP代理工具。
这个工具上线后，服务全公司所有研发，经过一段时间运行和修补，相对稳定，也做了一些关于内存方面的优化，直到又一次，在维护这个FTP代理的时候，发现一个奇怪的问题：
FTP代理进程，监听的是 192.168.88.32 的 21 端口，所以，这个端口对应了多少连接，就表示有多少个客户端存在，通过：
netstat -apn |grep "192.168.88.32:21"
发现，有将近1000个链接，且都是 ESTABLISHED，ESTABLISHED 状态表示一个连接的状态是“已连接”，但我们研发团队，并没有那么多人，直觉上看，事出反常必有妖。
初步分析可能性
感觉可能有一种情况，就是每个人开了多个FTP客户端，实际场景下，研发同学组可能会使用3种类型的FTP客户端
PHPStorm：这个客户端（SFTP插件）自己会维护一个FTP长连接。 Sublime + VsCode，这2个客户端不会维护链接，数据交互完成（比如传输任务），就主动发送 QUIT 指令到FTP代理端，然后所有链接关闭。很干净。
另外，使用PHPStorm的话，也存在开多个IDE创建，就使用多个FTP客户端连接的情况。 为了继续排查，我把所有对 192.168.88.32:21 的链接，做了分组统计，看看哪个IP的连接数最多
# 注：61604 是 ftp代理的进程ID
netstat -apn|grep "61604/server"|grep '192.168.88.32:21'|awk -F ':' '{print$2}'|awk '{print$2}'|sort|uniq -c |sort
上面的统计，是看哪个IP，对 192.168.88.32:21 连接数最多（18个）。
统计发现，很多IP，都存在多个链接的情况，难道每个人都用了多个IDE且可能还多IDE窗口使用吗？于是，挑了一个最多的，找到公司中使用这个IP的人，沟通发现，他确实使用了IDE多窗口，但是远远没有使用18个客户端那么多，仅仅PHPStorm开了3个窗口而已。
初步排查结论：应该是FTP代理所在服务器的问题，和用户开多个客户端没有关系。
进一步排查
这次排查，是怀疑，这将近1000个的 ESTABLISHED 客户端链接中，有大量假的 ESTABLISHED 链接存在，之前的统计发现，实际上，对 192.168.88.32:21 的客户端链接进行筛选，得到的IP，一共才200个客户端IP而已，平均下来，每个人都有5个FTP客户端链接FTP代理，想象觉得不太可能。那么，如何排查 ESTABLISHED 假链接呢？
在 TCP 四次挥手过程中，首先需要有一端，发起 FIN 包，接收方接受到 FIN 包之后，便开启四次挥手的过程，这也是连接断开的过程。
从之前的排查看，有人的IP，发起了多达18个FTP连接，那么，要排查是不是在 FTP 代理服务器上，存在假的 ESTABLISHED 连接的话，就首先需要去 开发同学的机器上看，客户端连接的端口，是不是仍在使用。比如：
tcp ESTAB 0 0 192.168.88.32:21 192.168.67.38:58038
这个表明，有一个研发的同学 IP是 192.168.67.38，使用了端口 58038，连接 192.168.88.32 上的 FTP 代理服务的 21 端口。所以，先要去看，到底研发同学的电脑上，这个端口存在不存在。
后来经过与研发同学沟通确认，研发电脑上并没有 58038 端口使用，这说明，对FTP代理服务的的客户端链接中显示的端口，也就是实际用户的客户端端口，存在大量不存在的情况。
结论：FTP代理服务器上，存在的近1000个客户端连接中（ESTABLISHED状态），有大量的假连接存在。也就是说，实际上这个连接早就断开不存在了，但服务端却还显示存在。
排查假 ESTABLISHED 连接
首先，如果出现假的 ESTABLISHED 连接，表示连接的客户端已经不存在了，客户端一方，要么发起了 TCP FIN 请求服务端没有收到，比如因为网络的各种原因（比如断网了）之后，FTP客户端无法发送FIN到服务端。要么服务端服务器接受到了 FIN，但是在后续过程中，丢包了等等。
为了验证上面的问题，我本机进行了一次模拟，连接FTP服务端后，本机直接断网，断网后，杀死FTP客户端进程，等待5分钟（为什么等待5分钟后面说）后，重新联网。然后再 FTP 服务端，查看服务器上与 FTP代理进行连接的所有IP，然后发现我本机的IP和端口依然在列，然后再我本机，通过
lsof -i :端口号
却没有任何记录，直接说明：服务端确实保持了假 ESTABLISHED 链接，一直不释放。
上面提到，我等待5分钟，是因为，服务端的 keepalive，是这样的配置：
[root@xx xx]# sysctl -a |grep keepalive
net.ipv4.tcp_keepalive_intvl = 75
net.ipv4.tcp_keepalive_probes = 9
net.ipv4.tcp_keepalive_time = 300
服务器默认设置的 tcp keepalive 检测是300秒后进行检测，也就是5分钟，当检测失败后，一共进行9次重试，每次时间间隔是75秒。 那么，问题就来了，服务器设置了 keepalive，如果 300 + 9*75 秒后，依然连接不上，就应该主动关闭假 ESTABLISHED 连接才对。为何还会积压呢？
猜想1：大量的积压的 ESTABLISHED 连接，实际上都还没有到释放时间
为了验证这个问题，我们就需要具体的看某个连接，什么时候创建的。所以，我找到其中一个我确定是假的 ESTABLISHED的链接（那个IP的用户，把所有FTP客户端都关了，进程也杀死了），看此连接的创建时间，过程如下：
先确定 FTP 代理进程的ID，为 61604
然后，看看这个进程的所有连接，找到某个端口的（55360，就是一个客户端所使用的端口）
[root@xxx xxx]# lsof -p 61604|grep 55360
server 61604 root 6u IPv4 336087732 0t0 TCP node088032:ftp->192.168.70.16:55360 (ESTABLISHED)
我们看到一个 “6u”，这个就是进程使用的这个连接的socket文件，Linux中，一切皆文件。我们看看这个文件的创建时间，就是这个连接的创建时间了
ll /proc/61604/fd/6
//输出：
lrwx------. 1 root root 64 Nov 1 14:03 /proc/61604/fd/6 -> socket:[336087732]
这个连接是11月1号创建的，现在已经11月8号，这个时间，早已经超出了 keepalive 探测 TCP连接是否存活的时间。这说明2个点：
1、可能 Linux 的 KeepAlive 压根没生效。 2、可能我的 FTP 代理进程，压根没有使用 TCP KeepAlive
猜想2： FTP 代理进程，压根没有使用 TCP KeepAlive
要验证这个结论，就得先知道，怎么看一个连接，到底具不具备 KeepAlive 功效？
netstat 命令不好使（也可能我没找到方法），我们使用 ss 命令，查看 FTP进程下所有连接21端口的链接
ss -aoen|grep 192.168.12.32:21|grep ESTAB
从众多结果中，随便筛选2个结果：
tcp ESTAB 0 0 192.168.12.32:21 192.168.20.63:63677 ino:336879672 sk:65bb <->
tcp ESTAB 0 0 192.168.12.32:21 192.168.49.21:51896 ino:336960511 sk:67f7 <->
我们再对比一下，所有连接服务器sshd进程的
tcp ESTAB 0 0 192.168.12.32:333 192.168.53.207:63269 timer:(keepalive,59sec,0) ino:336462258 sk:6435 <->
tcp ESTAB 0 0 192.168.12.32:333 192.168.55.185:64892 timer:(keepalive,3min59sec,0) ino:336461969 sk:62d1 <->
tcp ESTAB 0 0 192.168.12.32:333 192.168.53.207:63220 timer:(keepalive,28sec,0) ino:336486442 sk:6329 <->
tcp ESTAB 0 0 192.168.12.32:333 192.168.53.207:63771 timer:(keepalive,12sec,0) ino:336896561 sk:65de <->
对比很容易发现，连接 21端口的所有连接，多没有 timer 项。这说明，FTP代理 进程监听 21 端口时，所有进来的链接，全都没有使用keepalive。
找了一些文章，大多只是说，怎么配置Linux 的 Keep Alive，以及不配置的，会造成 ESTABLISHED 不释放问题，没有说进程需要额外设置啊？难道 Linux KeepAlive 配置，不是对所有连接直接就生效的？
所以，我们有必要验证 Linux keepalive，必须要进程自己额外开启才能生效
验证 Linux keepalive，必须要进程自己额外开启才能生效
在开始这个验证之前，先摘取一段FTP中间件代理关于监听 21 端口的部分代码：
func (ftpServer *FTPServer) ListenAndServe() error {
laddr, err := net.ResolveTCPAddr("tcp4", ftpServer.listenTo)
if err != nil {
return err
}
listener, err := net.ListenTCP("tcp4", laddr)
if err != nil {
return err
}
for {
clientConn, err := listener.AcceptTCP()
if err != nil || clientConn == nil {
ftpServer.logger.Print("listening error")
break
}
//以闭包的方式整理处理driver和ftpBridge，协程结束整体由GC做资源释放
go func(c *net.TCPConn) {
driver, err := ftpServer.driverFactory.NewDriver(ftpServer.FTPDriverType)
if err != nil {
ftpServer.logger.Print("Error creating driver, aborting client connection：" + err.Error())
} else {
ftpBridge := NewftpBridge(c, driver)
ftpBridge.Serve()
}
c = nil
}(clientConn)
}
return nil
}
足够明显，整个函数，net.ListenTCP 附近都没有任何设置KeepAlive的相关操作。我们查看 相关函数，找到了设置 KeepAlive的地方，进行一下设置：
if err != nil || clientConn == nil {
ftpServer.logger.Print("listening error")
break
}
// 此处，设置 keepalive
clientConn.SetKeepAlive(true)
重新构建部署之后，可以看到，所有对21端口的连接，全部都带了 timer
ss -aoen|grep 192.168.12.32:21|grep ESTAB
输出如下：
tcp ESTAB 0 0 192.168.12.32:21 192.168.70.76:54888 timer:(keepalive,1min19sec,0) ino:397279721 sk:6b49 <->
tcp ESTAB 0 0 192.168.12.32:21 192.168.37.125:49648 timer:(keepalive,1min11sec,0) ino:398533882 sk:6b4a <->
tcp ESTAB 0 0 192.168.12.32:21 192.168.33.196:64471 timer:(keepalive,7.957ms,0) ino:397757143 sk:6b4c <->
tcp ESTAB 0 0 192.168.12.32:21 192.168.21.159:56630 timer:(keepalive,36sec,0) ino:396741646 sk:6b4d <->
可以很明显看到，所有的连接，全部具备了 timer 功效，说明：想要使用 Linux 的 KeepAlive，需要程序单独做设置进行开启才行。
最后：ss 命令结果中 keepalive 的说明
首先，看一下 Linux 中的配置，我的机器如下：
[root@xx xx]# sysctl -a |grep keepalive
net.ipv4.tcp_keepalive_intvl = 75
net.ipv4.tcp_keepalive_probes = 9
net.ipv4.tcp_keepalive_time = 300
tcpkeepalivetime：表示多长时间后，开始检测TCP链接是否有效。 tcpkeepaliveprobes：表示如果检测失败，会一直探测 9 次。 tcpkeepaliveintvl：承上，探测9次的时间间隔为 75 秒。
然后，我们看一下 ss 命令的结果：
ss -aoen|grep 192.168.12.32:21|grep ESTAB
tcp ESTAB 0 0 192.168.12.32:21 192.168.70.76:54888 timer:(keepalive,1min19sec,0) ino:397279721 sk:6b49 <->
摘取这部分：timer:(keepalive,1min19sec,0) ，其中：
keepalive：表示此链接具备 keepalive 功效。 1min19sec：表示剩余探测时间，这个时间每次看都会边，是一个递减的值，第一次探测，需要 net.ipv4.tcpkeepalivetime 这个时间倒计时，如果探测失败继续探测，后边会按照 net.ipv4.tcpkeepaliveintvl 这个时间值进行探测。直到探测成功。 0：这个值是探测时，检测到这是一个无效的TCP链接的话已经进行了的探测次数。
后记
其实，针对这个问题以及这个过程的排查思路，也是后来我经常面试别人的一个面试题，在这个过程中，大多数服务端开发者并不能给到一个绝对满意的答案。在如何解决服务应用避免出现此问题诸多回答中，很多人会提出下面的一个方案：
“既然 Server 端应用可能出现虚假 ESTABLISHED 连接，那就做保活就可以了，Server 端主动发送类型 ping-pong 心跳检测，发现客户端无法回应时，关闭这个虚假连接”。
这个答案有些类似RPC服务的常用处理模式，但是这个回答是有问题的。其实，Server 端要使用上述方案的话，如果是4层应用，很好处理，开启一个线程或协程专门做心跳检测即可。但是，如果是典型的7层应用，比如：HTTP Server 或者 FTP Server，则无法使用上述方案。拿 HTTP Server 来说，服务端是不可能主动发送请求到客户端的，这个协议本身就注定HTTP服务器不能主动发送请求给HTTP客户端。
另外，后期我打算写一套Golang的教程（也许文字版也许是视频），从0开始开发一个FTP中间件，用于将客户端的FTP请求经过中间层处理后，再通过gRPC协议转发到SDN虚拟网络里的容器内。感兴趣的朋友可以多多关注~
欢迎关注“海角之南”公众号获取更新动态
