一次对server服务大量积压异常TCP ESTABLISHED链接的排查笔记

关注

转载最新推荐文章于 2026-09-22 12:51:29 发布 1.6k 阅读 AI 写同款· GEO 优化 ›

Go net包实战：构建端口扫描器、DHCP服务器与负载均衡器网络原语（network primitives）是现代云原生基础设施的基石，其核心在于对底层 socket、连接状态与 I/O 调度的精确建模。Go 语言通过标准库 net 包，以零抽象、强可控的方式封装系统调用，天然支持高并发、低延迟的网络行为实现。相比 Python 的 scapy 或 Node.js 的 net 模块，net 包提供可预测的错误分类（如 net.OpError）、原生 goroutine 友好调度，以及与 epoll/kqueue 的深度绑定，使开发者能直接推演连接建立、UDP 广播处阅读详情

背景

我们都知道，基于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

tcp_keepalive_time：表示多长时间后，开始检测TCP链接是否有效。
tcp_keepalive_probes：表示如果检测失败，会一直探测 9 次。
tcp_keepalive_intvl：承上，探测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.tcp_keepalive_time 这个时间倒计时，如果探测失败继续探测，后边会按照 net.ipv4.tcp_keepalive_intvl 这个时间值进行探测。直到探测成功。
0：这个值是探测时，检测到这是一个无效的TCP链接的话已经进行了的探测次数。

作者：海角之南
链接：https://www.jianshu.com/p/a1c3aba4af96
来源：简书

收录于