小记TCP keepalive

Posted 2023-04-02

参考技术A 前几天在调查一个Kafka服务器tcp连接数过大的问题。具体情况是单台Kafka的tcp连接数超过了3万，都是ESTABLISHED状态，到部分remote ip的连接数达到了几百，且连接数每天还在持续增加。这批remote ip都是属于同一个业务。
刚开始怀疑是Kafka某些条件下存在socket leakage的bug。但后来调查证实是防火墙引起的问题——Kafka服务器与这批业务服务器间存在一个防火墙，且配置了清理半小时的空闲连接。而我们使用的Kafka版本较低(0.8.2.1)，在创建连接时没有使用tcp keepalive。于是有些连接长时间没有数据传输就被防火墙在中间悄悄干掉了，而Kafka broker端没有发现，残留了大量无效连接。

其实Kafka官网已经记录了这个issue( https://issues.apache.org/jira/browse/KAFKA-2096 )，解决方案就是在创建tcp连接时加上keepalive选项，在0.9.0版本中已经解决。我们的Kafka由于升级影响较大，为降低风险采取了patch回当前版本的解决方案。

之前一直没太深入了解过TCP Keepalive，借此机会补一下课，也在此简单记录。

TCP keepalive选项，在创建tcp socket时默认是不打开的。默认的发送间隔较长，为7200秒，即2小时。在linux内核中相关的配置参数为

如果需要修改为更短的keepalive间隔，可以用命令

查看一个tcp连接是否使用了keepalive，可以用netstat -o查看，最后一列会是keepalive和倒计时。

要注意tcp keepalive是单向的，即只是单向的发送keepalive包且不需要response。

一个简单例子。

server端：

client端，用python实现：

连接状态：

从上面的最后一列可以看到，client到server的连接使用了keepalive，下次发送keepalive的倒计时为7184秒。

参考资料：

TCP心跳 | TCP keepAlive(转)

应用层对于每个socket采用如下函数来开启 keepalive机制，其参数将采用系统上述配置。

setsockopt(rs, SOL_SOCKET, SO_KEEPALIVE, (void *)&keepAlive, sizeof(keepAlive));

注意：keepalive是一个TCP协议包，并不是应用层数据包，意即通过recv等函数从应用层上是无法获得该协议包。可通过抓包工具来看。

==================================================================

一、什么是keepalive定时器？[1]

在一个空闲的（idle）TCP连接上，没有任何的数据流，许多TCP/IP的初学者都对此感到惊奇。也就是说，如果TCP连接两端没有任何一个进程在向对方发送数据，那么在这两个TCP模块之间没有任何的数据交换。你可能在其它的网络协议中发现有轮询（polling），但在TCP中它不存在。言外之意就是我们只要启动一个客户端进程，同服务器建立了TCP连接，不管你离开几小时，几天，几星期或是几个月，连接依旧存在。中间的路由器可能崩溃或者重启，电话线可能go down或者back up，只要连接两端的主机没有重启，连接依旧保持建立。

这就可以认为不管是客户端的还是服务器端的应用程序都没有应用程序级（application-level）的定时器来探测连接的不活动状态（inactivity），从而引起任何一个应用程序的终止。然而有的时候，服务器需要知道客户端主机是否已崩溃并且关闭，或者崩溃但重启。许多实现提供了存活定时器来完成这个任务。

存活定时器是一个包含争议的特征。许多人认为，即使需要这个特征，这种对对方的轮询也应该由应用程序来完成，而不是由TCP中实现。此外，如果两个终端系统之间的某个中间网络上有连接的暂时中断，那么存活选项（option）就能够引起两个进程间一个良好连接的终止。例如，如果正好在某个中间路由器崩溃、重启的时候发送存活探测，TCP就将会认为客户端主机已经崩溃，但事实并非如此。

存活（keepalive）并不是TCP规范的一部分。在Host Requirements RFC罗列有不使用它的三个理由：（1）在短暂的故障期间，它们可能引起一个良好连接（good connection）被释放（dropped），（2）它们消费了不必要的宽带，（3）在以数据包计费的互联网上它们（额外）花费金钱。然而，在许多的实现中提供了存活定时器。

一些服务器应用程序可能代表客户端占用资源，它们需要知道客户端主机是否崩溃。存活定时器可以为这些应用程序提供探测服务。Telnet服务器和Rlogin服务器的许多版本都默认提供存活选项。

个人计算机用户使用TCP/IP协议通过Telnet登录一台主机，这是能够说明需要使用存活定时器的一个常用例子。如果某个用户在使用结束时只是关掉了电源，而没有注销（log off），那么他就留下了一个半打开（half-open）的连接。在图18.16，我们看到如何在一个半打开连接上通过发送数据，得到一个复位（reset）返回，但那是在客户端，是由客户端发送的数据。如果客户端消失，留给了服务器端半打开的连接，并且服务器又在等待客户端的数据，那么等待将永远持续下去。存活特征的目的就是在服务器端检测这种半打开连接。
二、keepalive如何工作？[1]

在此描述中，我们称使用存活选项的那一段为服务器，另一端为客户端。也可以在客户端设置该选项，且没有不允许这样做的理由，但通常设置在服务器。如果连接两端都需要探测对方是否消失，那么就可以在两端同时设置（比如NFS）。

若在一个给定连接上，两小时之内无任何活动，服务器便向客户端发送一个探测段。（我们将在下面的例子中看到探测段的样子。）客户端主机必须是下列四种状态之一：

1) 客户端主机依旧活跃（up）运行，并且从服务器可到达。从客户端TCP的正常响应，服务器知道对方仍然活跃。服务器的TCP为接下来的两小时复位存活定时器，如果在这两个小时到期之前，连接上发生应用程序的通信，则定时器重新为往下的两小时复位，并且接着交换数据。

2) 客户端已经崩溃，或者已经关闭（down），或者正在重启过程中。在这两种情况下，它的TCP都不会响应。服务器没有收到对其发出探测的响应，并且在75秒之后超时。服务器将总共发送10个这样的探测，每个探测75秒。如果没有收到一个响应，它就认为客户端主机已经关闭并终止连接。

3) 客户端曾经崩溃，但已经重启。这种情况下，服务器将会收到对其存活探测的响应，但该响应是一个复位，从而引起服务器对连接的终止。

4) 客户端主机活跃运行，但从服务器不可到达。这与状态2类似，因为TCP无法区别它们两个。它所能表明的仅是未收到对其探测的回复。

服务器不必担心客户端主机被关闭然后重启的情况（这里指的是操作员执行的正常关闭，而不是主机的崩溃）。当系统被操作员关闭时，所有的应用程序进程（也就是客户端进程）都将被终止，客户端TCP会在连接上发送一个FIN。收到这个FIN后，服务器TCP向服务器进程报告一个文件结束，以允许服务器检测这种状态。

在第一种状态下，服务器应用程序不知道存活探测是否发生。凡事都是由TCP层处理的，存活探测对应用程序透明，直到后面2，3，4三种状态发生。在这三种状态下，通过服务器的TCP，返回给服务器应用程序错误信息。（通常服务器向网络发出一个读请求，等待客户端的数据。如果存活特征返回一个错误信息，则将该信息作为读操作的返回值返回给服务器。）在状态2，错误信息类似于“连接超时”。状态3则为“连接被对方复位”。第四种状态看起来像连接超时，或者根据是否收到与该连接相关的ICMP错误信息，而可能返回其它的错误信息。

windows 实现:

 

在一个正常的TCP连接上，当我们用无限等待的方式调用下面的Recv或Send的时候：

   ret=recv(s,&buf[idx],nLeft,flags);

   或

   ret=send(s,&buf[idx],nLeft,flags);

   如果TCP连接被对方正常关闭，也就是说，对方是正确地调用了closesocket(s)或者shutdown(s)的话，那么上面的Recv或Send调用就能马上返回，并且报错。这是由于closesocket(s)或者shutdown(s)有个正常的关闭过程，会告诉对方“TCP连接已经关闭，你不需要再发送或者接受消息了”。但是，如果是网线突然被拔掉，TCP连接的任何一端的机器突然断电或重启动，那么这时候正在执行Recv或Send操作的一方就会因为没有任何连接中断的通知而一直等待下去，也就是会被长时间卡住。这种情形解决的办法是启动TCP编程里的keepAlive机制。

   struct TCP_KEEPALIVE inKeepAlive = {0};
     unsigned long ulInLen = sizeof(struct TCP_KEEPALIVE);
     struct TCP_KEEPALIVE utKeepAlive = {0};
     unsigned long ulOutLen = sizeof(struct TCP_KEEPALIVE);
     unsigned long ulBytesReturn = 0;

    inKeepAlive.onoff=1;
     inKeepAlive.keepaliveinterval=5000; //单位为毫秒
    inKeepAlive.keepalivetime=1000;      //单位为毫秒
    ret=WSAIoctl(s, SIO_KEEPALIVE_VALS, (LPVOID)&inKeepAlive, ulInLen, 
                           (LPVOID)&outKeepAlive, ulOutLen, &ulBytesReturn, NULL, NULL);

  此处的keepalivetime表示的是TCP连接处于畅通时候的探测频率，一旦探测包没有返回，就以keepaliveinterval的频率发送，经过若干次的重试，如果探测包都没有返回，那么就得出结论：TCP连接已经断开，于是上面的Recv或Send调用也就能马上返回，不会无限制地卡住了。

 

上图是对上面文字的说明。亮条之前，TCP处于畅通状态，KeepAlive是以1000毫秒(keepalivetime的值)的频率发送探测包，在发送到第32个探测包的时候，探测包没有返回，于是就以5000毫秒(keepalivetime的值)的频率发送探测包，重发几次后，探测包都没有返回，于是就得出结论：此TCP连接已经断开了！

 

对于Win2K/XP/2003，可以从下面的注册表项找到影响整个系统所有连接的keepalive参数：

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters]

“KeepAliveTime”=dword:006ddd00 “KeepAliveInterval”=dword:000003e8 “MaxDataRetries”=”5″

 

  对于实用程序来说，2小时的空闲时间太长。因此，我们需要手工开启Keepalive功能并设置合理的Keepalive参数。在XP和WIN2003系统上，可以针对单独的socket来设置，但是在windows 2000，不能单独设置，如果设置，那么影响是整个系统的所有socket。

linux实现:

SO_KEEPALIVE/TCP_KEEPCNT/TCP_KEEPIDLE/TCP_KEEPINTVL 如果一方已经关闭或异常终止连接，而另一方却不知道，我们将这样的TCP连接称为半打开的。TCP通过保活定时器(KeepAlive)来检测半打开连接。 在高并发的网络服务器中，经常会出现漏掉socket的情况，对应的结果有一种情况就是出现大量的CLOSE_WAIT状态的连接。这个时候，可以通过设置KEEPALIVE选项来解决这个问题，当然还有其他的方法可以解决这个问题，详细的情况可以查看参考资料8。

使用方法如下：
//Setting For KeepAlive
 int keepalive = 1;
 setsockopt(incomingsock,SOL_SOCKET,SO_KEEPALIVE,(void*)(&keepalive),(socklen_t)sizeof(keepalive));
                         
 int keepalive_time = 30;
 setsockopt(incomingsock, IPPROTO_TCP, TCP_KEEPIDLE,(void*)(&keepalive_time),(socklen_t)sizeof(keepalive_time));
 int keepalive_intvl = 3;
 setsockopt(incomingsock, IPPROTO_TCP, TCP_KEEPINTVL,(void*)(&keepalive_intvl),(socklen_t)sizeof(keepalive_intvl));
int keepalive_probes= 3;
 setsockopt(incomingsock, IPPROTO_TCP, TCP_KEEPCNT,(void*)(&keepalive_probes),(socklen_t)sizeof(keepalive_probes));
设置SO_KEEPALIVE选项来开启KEEPALIVE，然后通过TCP_KEEPIDLE、TCP_KEEPINTVL和TCP_KEEPCNT设置keepalive的开始时间、间隔、次数等参数。
 当然，也可以通过设置/proc/sys/net/ipv4/tcp_keepalive_time、tcp_keepalive_intvl和tcp_keepalive_probes等内核参数来达到目的，但是这样的话，会影响所有的socket，因此建议使用setsockopt设置。

http://blog.csdn.net/cccallen/article/details/8003324