聊聊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