TCP是面向连接的,一般情况,两端的应用程序可以通过发送和接收数据得知对端的存活。
当两端的应用程序都没有数据发送和接收时,如何判断连接是否正常呢?

这就是SO_KEEPALIVE的作用。

1. SO_KEEPALIVE 的作用

1.1 SO_KEEPALIVE的定义

SO_KEEPALIVE用于开启或者关闭保活探测,默认情况下是关闭的。

SO_KEEPALIVE开启时,可以保持连接检测对方主机是否崩溃,避免(服务器)永远阻塞于TCP连接的输入。

相关的属性包括:
tcp_keepalive_timetcp_keepalive_probestcp_keepalive_intvl

tcp_keepalive_intvl (integer; default: 75; since Linux 2.4)
      The number of seconds between TCP keep-alive probes.

tcp_keepalive_probes (integer; default: 9; since Linux 2.2)
      The maximum number of TCP keep-alive probes to send before
      giving up and killing the connection if no response is
      obtained from the other end.

tcp_keepalive_time (integer; default: 7200; since Linux 2.2)
      The number of seconds a connection needs to be idle before TCP
      begins sending out keep-alive probes.  Keep-alives are sent
      only when the SO_KEEPALIVE socket option is enabled.  The
      default value is 7200 seconds (2 hours).  An idle connection
      is terminated after approximately an additional 11 minutes (9
      probes an interval of 75 seconds apart) when keep-alive is
      enabled.

      Note that underlying connection tracking mechanisms and
      application timeouts may be much shorter.

这些属性可以在/proc/sys/net/ipv4/下查看:

cat /proc/sys/net/ipv4/tcp_keepalive_time
7200

cat /proc/sys/net/ipv4/tcp_keepalive_probes
9

cat /proc/sys/net/ipv4/tcp_keepalive_intvl
75

也可以通过命令行查看:

sudo sysctl -a | grep keepalive

net.ipv4.tcp_keepalive_time = 7200
net.ipv4.tcp_keepalive_probes = 9
net.ipv4.tcp_keepalive_intvl = 75

1.2 连接探活的过程

开启SO_KEEPALIVE后,如果2小时内在此套接口的任一方向都没有数据交换,TCP就自动给对方发一个保持存活探测分节(keepalive probe)。这是一个对方必须响应的TCP分节.

它会导致以下三种情况:

  • 对方接收一切正常:以期望的ACK响应。2小时后,TCP将发出另一个探测分节。
  • 对方已崩溃且已重新启动:以RST响应。套接口的待处理错误被置为ECONNRESET,套接 口本身则被关闭。
  • 对方无任何响应:源自berkeley的TCP发送另外8个探测分节,相隔75秒一个,试图得到一个响应。一共尝试9次,即在发出第一个探测分节11分钟 15秒后若仍无响应就放弃。套接口的待处理错误被置为ETIMEOUT,套接口本身则被关闭。如ICMP错误是“host unreachable(主机不可达)”,说明对方主机并没有崩溃,但是不可达,这种情况下待处理错误被置为 EHOSTUNREACH。

根据上面的介绍我们可以知道对端以一种非优雅的方式断开连接的时候,我们可以设置SO_KEEPALIVE属性使得我们在2小时以后发现对方的TCP连接是否依然存在。

int keepAlive = 1;

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

如果我们不能接受如此之长的等待时间,怎么办?

2.设置TCP KEEPALIVE

上面提到,SO_KEEPALIVE默认的时间间隔太长,不利于应用程序检测连接状态。

解决方法有2种:

  • 全局设置
  • 针对单个连接设置

2.1 全局设置

在Linux中我们可以通过修改 /etc/sysctl.conf 的全局配置:

net.ipv4.tcp_keepalive_time=7200
net.ipv4.tcp_keepalive_intvl=75
net.ipv4.tcp_keepalive_probes=9

添加上面的配置后输入 sysctl -p 使其生效,
你可以使用命令来查看当前的默认配置

sysctl -a | grep keepalive

如果应用中已经设置SO_KEEPALIVE,程序不用重启,内核直接生效.

这种方法设置的全局的参数,针对整个系统生效,对单个socket的设置不够友好。

2.2 针对单个连接设置

我们可以使用TCP的TCP_KEEPCNTTCP_KEEPIDLETCP_KEEPINTVL3个选项。
这些选项是连接级别的,每个socket都可以设置这些属性。

这些选项的定义,可以通过man查看。

man 7 tcp

socket option:

TCP_KEEPCNT (since Linux 2.4)
      The maximum number of keepalive probes TCP should send before
      dropping the connection.  This option should not be used in
      code intended to be portable.
      关闭一个非活跃连接之前的最大重试次数。
      该选项不具备可移植性。

TCP_KEEPIDLE (since Linux 2.4)
      The time (in seconds) the connection needs to remain idle
      before TCP starts sending keepalive probes, if the socket
      option SO_KEEPALIVE has been set on this socket.  This option
      should not be used in code intended to be portable.
      设置连接上如果没有数据发送的话,多久后发送keepalive探测分组,单位是秒
      该选项不具备可移植性。

TCP_KEEPINTVL (since Linux 2.4)
      The time (in seconds) between individual keepalive probes.
      This option should not be used in code intended to be
      portable.
      前后两次探测之间的时间间隔,单位是秒
      该选项不具备可移植性。

代码层面的设置步骤:

int keepAlive = 1;    // 非0值,开启keepalive属性

int keepIdle = 60;    // 如该连接在60秒内没有任何数据往来,则进行此TCP层的探测

int keepInterval = 5; // 探测发包间隔为5秒

int keepCount = 3;        // 尝试探测的最多次数

// 开启探活
setsockopt(sockfd, SOL_SOCKET, SO_KEEPALIVE, (void *)&keepAlive, sizeof(keepAlive));

setsockopt(sockfd, SOL_TCP, TCP_KEEPIDLE, (void*)&keepIdle, sizeof(keepIdle));

setsockopt(sockfd, SOL_TCP, TCP_KEEPINTVL, (void *)&keepInterval, sizeof(keepInterval));

setsockopt(sockfd, SOL_TCP, TCP_KEEPCNT, (void *)&keepCount, sizeof(keepCount)

3.为什么应用层需要heart beat/心跳包?

通过上面的介绍,感觉TCP keepalive已经很牛逼了,但为什么还会提到应用层的心跳呢?

目前了解的原因包括两个:

  • TCP keepalive处于传输层,由操作系统负责,能够判断进程存在,网络通畅,但无法判断进程阻塞或死锁等问题。
  • 客户端与服务器之间有四层代理或负载均衡,即在传输层之上的代理,只有传输层以上的数据才被转发,例如socks5等

所以,基于以上原因,有时候还是需要应用程序自己去设计心跳规则的。
可以服务端负责周期发送心跳包,检测客户端,也可以客户端负责发送心跳包,或者服服务端和客户端同时发送心跳包。

可以根据具体的应用场景进行设计。

参考

《UNIX网络编程卷1》
《Linux多线程服务端编程》