TCP连接探测中的Keepalive 和心跳包​

     在做服务器时，如果发生客户端网线或断电等非正常断开的现象，如果服务器没有设置SO_KEEPALIVE选项，则会一直不关闭SOCKET。

如果设置了SO_KEEPALIVE选项，则会使用操作系统的默认参数进行探测报文的发送。我们参考下MSDN的一段话:

SIO_KEEPALIVE_VALS (opcode setting: I, T==3)

Enables or disables the per-connection setting of the TCP keep-alive option which specifies the TCP keep-alive timeout and interval. For more information on the keep-alive option, see section 4.2.3.6 on theRequirements for Internet Hosts—Communication Layers specified in RFC 1122 available at theIETF website. The argument structure forSIO_KEEPALIVE_VALS is specified in thetcp_keepalive structure defined in theMstcpip.h header file. This structure is defined as follows:

 

/* Argument structure for SIO_KEEPALIVE_VALS */
struct tcp_keepalive {
    u_long  onoff;
    u_long  keepalivetime;
    u_long  keepaliveinterval;
};

The value specified in the onoff member determines if TCP keep-alive is enabled or disabled. If theonoff member is set to a non-zero value, TCP keep-alive is enabled and the other members in the structure are used. Thekeepalivetime member specifies the timeout, in milliseconds, with no activity until the first keep-alive packet is sent. Thekeepaliveinterval member specifies the interval, in milliseconds, between when successive keep-alive packets are sent if no acknowledgement is received.（对于一个已经建立的tcp连接。如果在keepalivetime时间内双方没有任何的数据包传输，则开启keepalive功能的一端将发送 keepalive数据包，若没有收到应答，则每隔keepaliveinterval时间再发送该数据包，发送keepalive_probes次。一直没有收到应答，则发送rst包关闭连接。若收到应答，则将计时器清零。）

The SO_KEEPALIVE option, which is one of the SOL_SOCKET Socket Options, can also be used to enable or disable the TCP keep-alive on a connection, as well as query the current state of this option. To query whether TCP keep-alive is enabled on a socket, the getsockopt function can be called with the SO_KEEPALIVE option. To enable or disable TCP keep-alive, thesetsockopt function can be called with the SO_KEEPALIVE option. If TCP keep-alive is enabled with SO_KEEPALIVE, then the default TCP settings are used for keep-alive timeout and interval unless these values have been changed usingSIO_KEEPALIVE_VALS. The default settings when a TCP socket is initialized sets the keep-alive timeout to 2 hours and the keep-alive interval to 1 second. The number of keep-alive probes cannot be changed and is set to 10.

SIO_KEEPALIVE_VALS is supported on Windows 2000 and later.

也就是在2H内，没有数据交互，会发送探测报文。

 

 

采用TCP连接的C/S模式软件，连接的双方在连接空闲状态时，如果任意一方意外崩溃、当机、网线断开或路由器故障，另一方无法得知TCP连接已经失效，除非继续在此连接上发送数据导致错误返回。很多时候，这不是我们需要的。我们希望服务器端和客户端都能及时有效地检测到连接失效，然后优雅地完成一些清理工作并把错误报告给用户。

如何及时有效地检测到一方的非正常断开，一直有两种技术可以运用。一种是由TCP协议层实现的Keepalive，另一种是由应用层自己实现的心跳包。

TCP默认并不开启Keepalive功能，因为开启Keepalive功能需要消耗额外的带宽和流量，尽管这微不足道，但在按流量计费的环境下增加了费用，另一方面，Keepalive设置不合理时可能会因为短暂的网络波动而断开健康的TCP连接。并且，默认的Keepalive超时需要7,200,000 milliseconds，即2小时，探测次数为5次。

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

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

“KeepAliveTime”=dword:006ddd00

“KeepAliveInterval”=dword:000003e8

“MaxDataRetries”=”5″

 

对于实用的程序来说，2小时的空闲时间太长。因此，我们需要手工开启Keepalive功能并设置合理的Keepalive参数。

// 开启KeepAlive

BOOL bKeepAlive = TRUE;

int nRet = ::setsockopt(socket_handle, SOL_SOCKET, SO_KEEPALIVE, (char*)&bKeepAlive, sizeof(bKeepAlive));

if (nRet == SOCKET_ERROR)

{

return FALSE;

}

 

// 设置KeepAlive参数

tcp_keepalive alive_in                = {0};

tcp_keepalive alive_out                = {0};

alive_in.keepalivetime                = 5000;                // 开始首次KeepAlive探测前的TCP空闭时间

alive_in.keepaliveinterval        = 1000;                // 两次KeepAlive探测间的时间间隔

alive_in.onoff                                = TRUE;

unsigned long ulBytesReturn = 0;

nRet = WSAIoctl(socket_handle, SIO_KEEPALIVE_VALS, &alive_in, sizeof(alive_in),

&alive_out, sizeof(alive_out), &ulBytesReturn, NULL, NULL);

if (nRet == SOCKET_ERROR)

{

return FALSE;

}

开启Keepalive选项之后，对于使用IOCP模型的服务器端程序来说，一旦检测到连接断开，GetQueuedCompletionStatus函数将立即返回FALSE，使得服务器端能及时清除该连接、释放该连接相关的资源。对于使用select模型的客户端来说，连接断开被探测到时，以recv目的阻塞在socket上的select方法将立即返回SOCKET_ERROR，从而得知连接已失效，客户端程序便有机会及时执行清除工作、提醒用户或重新连接。

 

另一种技术，由应用程序自己发送心跳包来检测连接的健康性。客户端可以在一个Timer中或低级别的线程中定时向发服务器发送一个短小精悍的包，并等待服务器的回应。客户端程序在一定时间内没有收到服务器回应即认为连接不可用，同样，服务器在一定时间内没有收到客户端的心跳包则认为客户端已经掉线。

 

 

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

　windows下此处的”非正常断开”指TCP连接不是以优雅的方式断开,如网线故障等物理链路的原因,还有突然主机断电等原因.

有两种方法可以检测:

1.TCP连接双方定时发握手消息

2.利用TCP协议栈中的KeepAlive探测 第二种方法简单可靠,只需对TCP连接两个Socket设定KeepAlive探测, 所以本文只讲第二种方法在Linux,Window2000下的实现(在其它的平台上没有作进一步的测试) Windows 2000平台下 头文件

#include <MSTcpIP.h>

//开启keepalive功能，并修改默认的keepalive
//用于心跳包检测

//开启keepalive
BOOL bKeepAlive=TRUE; 
ret=setsockopt(listenSocket,SOL_SOCKET,SO_KEEPALIVE,(char*)&bKeepAlive,sizeof(bKeepAlive));
if(ret ==SOCKET_ERROR)
{
	cerr<<"开启keepalive功能失败！"<<endl;
	cerr<<"error code:"<<WSAGetLastError()<<endl;
	closesocket(listenSocket);
	WSACleanup();
	exit(1);
}

//修改keepalive参数
tcp_keepalive aliveIn;
aliveIn.onoff=1;
aliveIn.keepalivetime=900 * 1000; // TCP连接多长时间(毫秒)没有数据就开始发送心跳包，有数据传递的时候不发送心跳包。//系统默认2小时，我设置15分钟，不宜设置过小
aliveIn.keepaliveinterval=1000; //当keepalivetime时间到达后，每隔多长时间(毫秒)发送一个心跳包，发5次(系统默认值)	
tcp_keepalive aliveOut;
DWORD uiBytesReturn=0;
ret=WSAIoctl(listenSocket,SIO_KEEPALIVE_VALS,&aliveIn,sizeof(aliveIn),&aliveOut,sizeof(aliveOut),&uiBytesReturn,NULL,NULL);
if(ret ==SOCKET_ERROR)
{
	cerr<<"修改keepalive参数失败！"<<endl;
	cerr<<"error code:"<<WSAGetLastError()<<endl;
	closesocket(listenSocket);
	WSACleanup();
	exit(1);
}

 

 

附加一篇文章备忘：

摘自：http://blog.csdn.net/xuyuefei1988/article/details/8279812 以及http://blog.chinaunix.net/uid-14973561-id-3533891.html两篇博文

心跳包的实现有这样的两种技术

心跳检测步骤：
1客户端每隔一个时间间隔发生一个探测包给服务器
2客户端发包时启动一个超时定时器
3服务器端接收到检测包，应该回应一个包
4如果客户机收到服务器的应答包，则说明服务器正常，删除超时定时器
5如果客户端的超时定时器超时，依然没有收到应答包，则说明服务器挂了

一：TCP的KeepAlive保活机制

在《UNIX网络编程第1卷》中也有详细的阐述：

SO_KEEPALIVE 保持连接检测对方主机是否崩溃，避免（服务器）永远阻塞于TCP连接的输入。设置该选项后，如果2小时内在此套接口的任一方向都没有数据交换，TCP就自 动给对方 发一个保持存活探测分节(keepalive probe)。这是一个对方必须响应的TCP分节.它会导致以下三种情况：对方接收一切正常：以期望的ACK响应。2小时后，TCP将发出另一个探测分 节。对方已崩溃且已重新启动：以RST响应。套接口的待处理错误被置为ECONNRESET，套接 口本身则被关闭。对方无任何响应：源自berkeley的TCP发送另外8个探测分节，相隔75秒一个，试图得到一个响应。在发出第一个探测分节11分钟 15秒后若仍无响应就放弃。套接口的待处理错误被置为ETIMEDOUT，套接口本身则被关闭。如ICMP错误是“host unreachable(主机不可达)”，说明对方主机并没有崩溃，但是不可达，这种情况下待处理错误被置为 EHOSTUNREACH。
在该书的第158页有更详细的描述。
根据上面的介绍我们可以知道对端以一种非优雅的方式断开连接的时候，我们可以设置SO_KEEPALIVE属性使得我们在2小时以后发现对方的TCP连接是否依然存在。
keepAlive = 1；
Setsockopt(listenfd, SOL_SOCKET, SO_KEEPALIVE, (void*)&keepAlive, sizeof(keepAlive));
如果我们不能接受如此之长的等待时间，从TCP-Keepalive-HOWTO上可以知道一共有两种方式可以设置，一种是修改内核关于网络方面的 配置参数，另外一种就是SOL_TCP字段的TCP_KEEPIDLE， TCP_KEEPINTVL， TCP_KEEPCNT三个选项。
The tcp_keepidle parameter specifies the interval of inactivity that causes TCP to generate a KEEPALIVE transmission for an application that requests them. tcp_keepidle defaults to 14400 (two hours).
/*开始首次KeepAlive探测前的TCP空闭时间 */
The tcp_keepintvl parameter specifies the interval between the nine retries that are attempted if a KEEPALIVE transmission is not acknowledged. tcp_keepintvl defaults to 150 (75 seconds).
/* 两次KeepAlive探测间的时间间隔 */
The TCP_KEEPCNT option specifies the maximum number of keepalive probes to be sent. The value of TCP_KEEPCNT is an integer value between 1 and n, where n is the value of the systemwide tcp_keepcnt parameter.
/* 判定断开前的KeepAlive探测次数 */
因此我们可以得到
int keepIdle = 6;
int keepInterval = 5;
int keepCount = 3;
setsockopt(listenfd, SOL_TCP, TCP_KEEPIDLE, (void *)&keepIdle, sizeof(keepIdle));
setsockopt(listenfd, SOL_TCP,TCP_KEEPINTVL, (void *)&keepInterval, sizeof(keepInterval));
setsockopt(listenfd,SOL_TCP, TCP_KEEPCNT, (void *)&keepCount, sizeof(keepCount));
我们需要注意的TCP-Keepalive-HOWTO上这段话：
Remember that keepalive is not program−related, but socket−related, so if you have multiple sockets, you can handle keepalive for each of them separately.
这些属性是sockt继承的，非整个代码内的所有sockets都继承这个属性，因为如果要应用到多个套接口上必须分别使用setsockopt。(原文我认为错误的地方被我给改动)
如果心搏函数要维护客户端的存活，即服务器必须每隔一段时间必须向客户段发送一定的数据，那么使用SO_KEEPALIVE是有很大的不足的。因为 SO_KEEPALIVE选项指"此套接口的任一方向都没有数据交换",我不知道大家是怎么理解这个实现的。在Linux 2.6系列上，上面话的理解是只要打开SO_KEEPALIVE选项的套接口端检测到数据发送或者数据接受就认为是数据交换。
因此在这种情况下使用 SO_KEEPALIVE选项 检测对方是否非正常连接是完全没有作用的，在每隔一段时间发包的情况， keep-alive的包是不可能被发送的。上层程序在非正常端开的情况下是可以正常发送包到缓冲区的。非正常端开的情况是指服务器没有收到"FIN" 或者 "RST"包。

当然这种情况也是比较好断定对方是否存活，我提出来的主要原因是想看看大家对"此套接口的任一方向都没有数据交换"是怎么去理解的。

二：keepalive机制的弊端    摘自(http://blog.csdn.net/ctthuangcheng/article/details/8596818)
       如果没有设置keep alive，可能你在你的socket（阻塞性）的上面，接收: recv会一直阻塞不能返回，除非对端主动关闭连接，因为recv不知道socket断了。发送：取决于数据量的大小，只要底层协议栈的buffer能放下你的发送数据，应用程序级别的send就会一直成功返回。 直到buffer满，甚至buffer满了还要阻塞一段时间试图等待buffer空闲。所以你对send的返回值的检查根本检测不到失败。开启了keep alive功能，你直接通过发送接收的函数返回值就可以知道网络是否异常。

    对于循环不停send的socket，当拔掉网线后，会持续一段时间send返回成功（0~10秒左右，取决 于发送数据的量），然后send阻塞，因为协议层的buffer满了，在等待buffer空闲，大概90秒左右后才会返回错误。由此看来，send的时候，keep alive似乎没有起到作用，这个原因至今也不清楚。后来通过给send之前设置timer来解决的。

但是，tcp自己的keepalive有这样的一个bug：

       正常情况下，连接的另一端主动调用colse关闭连接，tcp会通知，我们知道了该连接已经关闭。但是如果tcp连接的另一端突然掉线，或者重启断电，这个时候我们并不知道网络已经关闭。而此时，如果有发送数据失败，tcp会自动进行重传。重传包的优先级高于keepalive，那就意味着，我们的keepalive总是不能发送出去。 而此时，我们也并不知道该连接已经出错而中断。在较长时间的重传失败之后，我们才会知道。

       为了避免这种情况发生，我们要在tcp上层，自行控制。对于此消息，记录发送时间和收到回应的时间。如果长时间没有回应，就可能是网络中断。如果长时间没有发送，就是说，长时间没有进行通信，可以自行发一个包，用于keepalive，以保持该连接的存在。

三：应用层自己实现的心跳包
由应用程序自己发送心跳包来检测连接是否正常，大致的方法是：服务器在一个 Timer事件中定时 向客户端发送一个短小精悍的数据包，然后启动一个低级别的线程，在该线程中不断检测客户端的回应， 如果在一定时间内没有收到客户端的回应，即认为客户端已经掉线；同样，如果客户端在一定时间内没 有收到服务器的心跳包，则认为连接不可用。