Zmq pub/sub无故连接中断解决之 —— TCP keepalive简介

最新推荐文章于 2024-09-13 22:35:38 发布

guotianqing

最新推荐文章于 2024-09-13 22:35:38 发布

阅读量9.3k

点赞数 6

分类专栏：问题解决 zmq 文章标签： TCP_Keepalive 保活包连接中断 zmq ZMQ_TCP_KEEPALIVE_IDLE

本文链接：https://blog.csdn.net/guotianqing/article/details/102961474

版权

问题解决同时被 2 个专栏收录

14 篇文章 2 订阅

订阅专栏

zmq

3 篇文章 4 订阅

订阅专栏

现象

使用Zmq pub/sub模式，多个sub订阅一个pub的数据。pub会不定期推送数据，有时很多，有时2个小时也没有数据。

pub端和sub端部署在互联网环境中，sub端可能是分散到各地的服务器。

最近发现，当pub长时间没有发送数据时，sub之后就再也接收不到数据了。而且这种现象也不是100%，测试了几天，有个80%的样子吧。

在pub端，netstat查看时，连接已经没有了，而在sub端连接仍然存在。好奇怪！

原因及解决

由于一段时间没有发现原因，为了测试，我在pub端同一机器上部署了sub端，而这个sub端一点问题也没有，哈哈。

以前以为，只要连接断开，Zmq的connect就会自动重连，所以不需要关心连接的问题。

根据文档和测试，也确实是这样。但是请注意，这里说的连接断开是正常的断开，有4次挥手的断开，也就是说通信双方都知道连接断开了。

但有时，并非如此。在复杂的网络环境中，通信双方大概率会经过NAT等网络设备，它们会悄无声息地关闭连接。并且，在长连接长时间无数据时，通信双方根本无法知晓。

下面开始验证猜想。很简单，为了保持网络连接，增加心跳即可。应用层的心跳也简单，但根据ZMQ文档，最好使用TCP的keepalive。

If we use a TCP connection that stays silent for a long while, it will, in some networks, just die. Sending something (technically, a “keep-alive” more than a heartbeat), will keep the network alive.

查看zmq_setsockopt API文档，发现了好东西(以下说明是我查资料后自己的理解，详情请参考下文链接)：

ZMQ_TCP_KEEPALIVE

设置SO_KEEPALIVE属性，是否开启keepalive特性。默认为-1，使用操作系统默认值，即不开启。

ZMQ_TCP_KEEPALIVE_CNT

设置TCP_KEEPCNT属性，如果保活包没有收到响应，连接重试的次数。在达到这个次数仍然无响应的，标记该连接不可用。Windoes好象默认是10。

ZMQ_TCP_KEEPALIVE_IDLE

设置TCP_KEEPALIVE属性，如果连接在该段时间内持续空闲，将发送第一个保活包。Windows默认为2小时。

ZMQ_TCP_KEEPALIVE_INTVL

设置TCP_KEEPINTVL属性，如果发送的保活包没有应答，则间隔该时长继续发送保活包，直到连接标识连接断开。Windows默认为1s。

于是，我修改了程序，设置启用keepalive，且ZMQ_TCP_KEEPALIVE_IDLE为120s，其他保持默认就好。

如下代码片断：

c/c++:

// 开启TCP保活机制，防止网络连接因长时间无数据而被中断
int tcp_keep_alive = 1;
zmq_setsockopt(fd, ZMQ_TCP_KEEPALIVE, &tcp_keep_alive, sizeof(tcp_keep_alive));

// 网络连接空闲2min即发送保活包
int tcp_keep_idle = 120;
zmq_setsockopt(fd, ZMQ_TCP_KEEPALIVE_IDLE, &tcp_keep_idle, sizeof(tcp_keep_idle));

python:

# self.client is my socket here
self.client.setsockopt(zmq.TCP_KEEPALIVE, 1)
self.client.setsockopt(zmq.TCP_KEEPALIVE_IDLE, 120)
self.client.setsockopt(zmq.TCP_KEEPALIVE_INTVL, 1) # 随意

这样，连接就不再断开了。即使断开了，2min后，keepalive属性会检测到连接不可用，zmq的重连机制就生效喽！

如果想了解更加详细信息，可以继续阅读。

TCP keepalive

顾名思义，TCP keepalive属性就是要保持TCP连接的活动性（可用性）。

该属性主要用来检测TCP sockets的连接状态，是可用的还是已经断开。

原理

当建立TCP连接的时候，会关联到一些定时器，其中一些定时器用来处理keepalive事务。

当该定时器到0时，发送到对端一个keepalive探测包（下称保活包），保活包没有真实的数据，并且需要对端响应ACK。

由于TCP/IP协议的支持，不管对端是否设置了keepalive属性，它收到保活包后，都会响应ACK。

如果接收到了ACK，那么该连接是可用的。如果没有收到，那么在该连接上的应用数据可能会出现异常。

使用场景

不使用keepalive依然可以安全地使用TCP通信。不过，既然你读到了这里，很可能是因为你遇到了问题，很可能，读完这篇短文后你会尝试使用keepalive解决问题。

当然，也可能是你没有找到比读这些东西更有趣的事情了，哈哈。

keepalive默认是关闭的。打开它也很方便，不会造成问题，不过会产生一些额外的流量，可能会对路由器或者防火墙产生影响。

总而言之，keepalive主要用于以下2个场景：

检测对端是否已死
防止由于网络空闲导致的连接断开

下面阐述。

检测对端状态

TCP的连接和断开都是有握手的。为什么还需要检测呢？如果对端断开了，我的socket会进行4次挥手的啊。

对，正常情况下，上述语句正确。但是，以下情况呢：

内核崩溃
进程异常终止退出
对端正常，但是网络断了，如网线掉了或者被路由器/防火墙断了

以上情况下，对端会在不跟你说byebye的情况下挂掉，你的socket就不会得到通知了。

这里，tcp连接状态看起来没有什么异常，但应用数据会发送失败。

典型的情况是，A和B通过三次握手建立了连接，并进行通信。在连接空闲期间，突然，B断电了，而且没有跟A进行4次挥手。

B来电重启后，这时，A知道自己有一个已经建立好的连接可以跟B通信，但B什么也不知道。

当A给B发送数据时，因为对于B来说，在没有建立连接的情况下收到数据是异常的，会响应RST，此时，A才会明白，并关闭自己并不可用的连接。

Keepalive 能解决这个问题，它会在连接上定期发送保活包，当一端不可用时，会标识连接的不可用状态。

防止空闲连接断开

我是因为这个问题才写的这篇文章。通信双方会建立连接，通信，然后中间有1.5小时连接会空闲。再然后，我的客户端就收不到数据了。这就是空闲连接断开的案例。

这是一个很普遍的问题。网络环境较为复杂，中间可能会经过NAT代理、防火墙等网络设备。

取决于这些网络设备对连接跟踪的具体实现，由于设备本身的物理限制，如内存等，它们只能跟踪有限的连接。它们通常会保持新近活动的连接而把最先不活跃的连接删除。

回到AB通信的例子，AB保持长连接是它们自身所需，但是网络代理并不知道，所以当AB再次通信时，代理已经没有该连接的记录，自然无法正常处理数据包，连接断开。

这些网络设备通常使用所谓的LRU机制删除内存中的连接，所以，定期在连接上发送数据可以保持连接不会被删除，因为它总是很活跃的！

示意图如下：

    _____           _____                                     _____
   |     |         |     |                                   |     |
   |  A  |         | NAT |                                   |  B  |
   |_____|         |_____|                                   |_____|
      ^               ^                                         ^
      |--->--->--->---|----------- SYN ------------->--->--->---|
      |---<---<---<---|--------- SYN/ACK -----------<---<---<---|
      |--->--->--->---|----------- ACK ------------->--->--->---|
      |               |                                         |
      |               | <--- connection deleted from table      |
      |               |                                         |
      |--->- PSH ->---| <--- invalid connection                 |
      |               |                                         |

使用举例

函数 SetSockOpt 用来设置socket的属性。1 – 2 147 460 之间的秒数都是合法的值，设置为0时，关闭该发生，设置值超过最大值时，按最大值生效。

GetSockOpt 用来获取已经设备的值。单位是秒。

参考代码片断如下：

//---------------------------------------
// Initialize variables and call setsockopt. 
// The SO_KEEPALIVE parameter is a socket option 
// that makes the socket send keepalive messages
// on the session. The SO_KEEPALIVE socket option
// requires a boolean value to be passed to the
// setsockopt function. If TRUE, the socket is
// configured to send keepalive messages, if FALSE
// the socket configured to NOT send keepalive messages.
// This section of code tests the setsockopt function
// by checking the status of SO_KEEPALIVE on the socket
// using the getsockopt function.

bOptVal = TRUE;

iResult = getsockopt(ListenSocket, SOL_SOCKET, SO_KEEPALIVE, (char *) &iOptVal, &iOptLen);
if (iResult == SOCKET_ERROR) {
    wprintf(L"getsockopt for SO_KEEPALIVE failed with error: %u\n", WSAGetLastError());
} else
    wprintf(L"SO_KEEPALIVE Value: %ld\n", iOptVal);

iResult = setsockopt(ListenSocket, SOL_SOCKET, SO_KEEPALIVE, (char *) &bOptVal, bOptLen);
if (iResult == SOCKET_ERROR) {
    wprintf(L"setsockopt for SO_KEEPALIVE failed with error: %u\n", WSAGetLastError());
} else
    wprintf(L"Set SO_KEEPALIVE: ON\n");

iResult = getsockopt(ListenSocket, SOL_SOCKET, SO_KEEPALIVE, (char *) &iOptVal, &iOptLen);
if (iResult == SOCKET_ERROR) {
    wprintf(L"getsockopt for SO_KEEPALIVE failed with error: %u\n", WSAGetLastError());
} else
    wprintf(L"SO_KEEPALIVE Value: %ld\n", iOptVal);