聊聊TCP Keepalive、Netty和Docker

聊聊TCP Keepalive、Netty和Docker

本文主要阐述TCP Keepalive和对应的内核参数,及其在Netty,Docker中的实现。简单总结了工作中遇到的问题,与大家共勉。

起因

之所以研究TCP Keepalive机制,主要是由于在项目中涉及TCP长连接。服务端接收客户端请求后需要执行时间较长的任务,再将结果返回给客户端。期间,客户端和服务端没有任何通讯,客服端持续等待服务端返回结果。

+-----------+                    +-----------+
|           |                    |           |
|  Client   |                    |  Server   |
|           |                    |           |
|           |  Long Connection   |           |
|       <---+--------------------+-->        |
|           |                    |           |
+-----------+                    +-----------+

那么,问题来了,实际情况往往不会这么简单。在服务器和客户端之间往往还有众多的网络设备,其中一些网络设备,由于特殊的原因,会导致上述的长连接无法维持较长时间,客户端因此也无法获得正确的结果。

典型的例子就是NAT或者防火墙,这类网络中介设备都应用了一种叫连接跟踪(connection tracking,conntrack)的技术,用来维护输入和输出的TCP连接信息,使两端设备发送的数据可达。但由于硬件上的瓶颈及基于性能的考虑,这类设备不会维持所有的连接信息,而是会将过期的不活跃的连接信息踢出去。如果这时其中一方还在执行任务,没有返回数据,造成这条连接彻底断开,另一方永远无法获得数据。为了解决这一问题,引入了TCP Keepalive的技术。

+-----------+                    +-----------+                   +-----------+
|           |                    |   NAT OR  |                   |           |
|  Client   |                    |  Firewall |                   |  Server   |
|           |                    |           |                   |           |
|           |  Long Connection   |    drop   |  Long Connection  |           |
|       <---+--------------------+--x     x--+-------------------+-->        |
|           |                    |           |                   |           |
+-----------+                    +-----------+                   +-----------+

TCP Keepalive是什么

其实理解起来非常简单,就是在TCP层的心跳包。当客户端与服务端之间的连接空闲了很长时间,期间没有任何交互时,服务端或客户端会发送一个空数据的ACK探测包给对方,如果连接没有问题,对方再以同样的方式响应一个ACK包,如果网络有中断ACK包会重复发多次直到上限。这样TCP Keepalive就能解决两个问题,其中之一是上述中使网络中介设备保持该连接的活性,维持连接的状态;另外,通过发包也可以探测双方的程序存活状态。Linux在内核中内建了对TCP Keepalive的支持,不过默认是关闭的,需要通过Socket选项SO_KEEPALIVE打开这个功能,这里还涉及三个内核参数:

  • tcp_keepalive_time:连接空闲的时长,默认7200秒。
  • tcp_keepalive_probes:发送ACK探测包的次数上限,默认9次。
  • tcp_keepalive_intvl:发送ACK探测包之间的间隔,默认75秒。
  Client            Server

    |                  |
    +----------------->|
    |       Last       |
    |    Communicate   |
    |<-----------------+
    |                  |
    |                  |
    |       Long       |
    |                  |
    |     Idle Time    |
    |                  |
    |                  |
    |<-----------------+
    |  Keepalive ACK   |
    +----------------->|
    |                  |
    |                  |

Docker和内核参数

在应用层,当我们打开了Socket SO_KEEPALIVE选项,那么Linux内核就会通过内置的定时器帮我们做好TCP Keepalive的相关工作。由于第一节描述的原因,现实中网络中介设备NAT或防火墙往往都会把失活的判断标准调低,也就是说判断长连接活性的空闲时间会远远小于Linux内核锁设置的7200秒,一般也就几十分钟甚至几分钟,这就需要我们调整将内核参数tcp_keepalive_time调低。最简单的方式就是通过sysctl接口,调整对应的参数:

sysctl -w net.ipv4.tcp_keepalive_time=300

但是这里要留意的是,如果你的服务运行在Docker容器中,调整内核参数的方式会有所不同。
这是由于Docker会通过命名空间(namespace)隔离不同的容器网络,而对应的内核参数也是被隔离的。当Docker在启动容器的时候,创建的network命名空间并不会从宿主机继承大部分的内核网络参数,而是将这些参数设置为Linux内核编译时指定的默认值。

因此我们必须通过--sysctl参数,在Docker启动容器时,将对应的内核参数初始化。

并不是所有的内核参数都支持命名空间,我们从Docker的官方文档中,可以了解已支持的内核参数以及使用的限制:

IPC Namespace:
kernel.msgmax, kernel.msgmnb, kernel.msgmni, kernel.sem, kernel.shmall, kernel.shmmax, kernel.shmmni, kernel.shm_rmid_forced.
Sysctls beginning with fs.mqueue.*
If you use the --ipc=host option these sysctls are not allowed.

Network Namespace:
Sysctls beginning with net.*
If you use the --network=host option using these sysctls are not allowed.

Netty中的Keepalive

在了解完TCP Keepalive的机制及Linux内核对其相关支持后,我们回到应用层,看看具体如何实现,以及另外推荐的解决方案。下面我拿Java的Netty举例。Netty中直接提供了ChannelOption.SO_KEEPALIVE选项,将其传给ServerBootstrap.childOption方法,即可开启TCP Keepalive功能,配置好相关内核参数后,剩下的交给内核搞定。那么,既然内核将TCP Keepalive参数暴露给用户态,有没有一种方法能在应用级别调整这些参数,而不用修改系统全局的参数呢?通过man pages了解到,可以通过setsockopt方法为当前TCP Socket配置不同的TCP Keepalive参数,这些参数将会覆盖系统全局的。

通过调整每个Socket的Keepalive参数会更加灵活,不会因修改系统全局参数而影响到其他应用。接下来看看如何通过Java 的Netty库来设置对应的参数,Netty中默认的NIO transport没有直接提供对应的Socket Option,除非使用了netty-transport-native-epoll (https://github.com/netty/netty/pull/2406)。而在JDK 11中新增了对这些参数的支持:

若想在Netty中使用,还需要做一层封装。下面是对应的示例代码,仅供参考:

public void run() throws Exception {
    EventLoopGroup bossGroup = new NioEventLoopGroup();
    EventLoopGroup workerGroup = new NioEventLoopGroup();
    try {
        ServerBootstrap b = new ServerBootstrap();
        b.group(bossGroup, workerGroup)
            .channel(NioServerSocketChannel.class)
            .childHandler(new ChannelInitializer<SocketChannel>() {
                @Override
                public void initChannel(SocketChannel ch) throws Exception {
                    ch.pipeline().addLast(new DiscardServerHandler());
                }
            })
            // 配置TCP Keepalive参数,将Keepalive空闲时间设为150秒
            .option(NioChannelOption.of(ExtendedSocketOptions.TCP_KEEPIDLE), 150)
            .option(NioChannelOption.of(ExtendedSocketOptions.TCP_KEEPINTERVAL), 75)
            .option(NioChannelOption.of(ExtendedSocketOptions.TCP_KEEPCOUNT), 9)
            // 打开SO_KEEPALIVE
            .childOption(ChannelOption.SO_KEEPALIVE, true);

        ChannelFuture f = b.bind(port).sync();
        f.channel().closeFuture().sync();
    } finally {
        workerGroup.shutdownGracefully();
        bossGroup.shutdownGracefully();
    }
}

接下来,我们如何知道设置的参数已经起作用了呢?由于涉及TCP Keepalive机制内建在Linux内核,因此无法在应用级别debug,但可以通过一些其他手段对连接进行监测。其一是通过iproute2提供的ss命令的-o选项查看对应的Socket Options;其二,是通过tcpdump抓包分析。
首先来看,默认不做任何改动时的情况:

接下来仅开启SO_KEEPALIVE

可以看到Socket Options的keepalive定时器为119min,也就是反映出系统默认配置的空闲时间为7200秒。

最后,我们开启SO_KEEPALIVE,并且设置TCP_KEEPIDLE参数为150秒:

可以看到上面tcpdump抓包显示出,两次ACK包间隔为2分半,即150秒,包的length为0,这就是TCP Keepalive的ACK探测包。同时也可以看到下面ss命令显示Socket Options中keepalive timer定时器的倒计时状态。

总结

通过这篇文章,我们了解到:

  • TCP Keepalive的概念、原理及其两个重要作用。
  • TCP Keepalive的三个系统内核参数,及其在Docker容器环境中的特殊配置方式。
  • 通过Java的Netty库演示如何开启TCP Keepalive,探索在应用层灵活配置三个内核参数。

ref:
TCP Keepalive HOWTO
SO: tcp_keepalive_time in docker container
docker run Docs

posted on 2021-08-06 21:21  eshizhan  阅读(255)  评论(0编辑  收藏  举报