利用keepalive和timeout来推断死连接

问题是这样出现的。

操作：client正在向服务端请求数据的时候，突然拔掉client的网线。

现象：client死等。服务端socket一直存在。

在网上搜索后，须要设置KEEPALIVE属性。

于是就在client和服务端都设置了KEEPALIVE属性。

代码例如以下：

int keepalive = 1;  // 打开keepalive

int keepidle = 10;  // 空暇10s開始发送检測包（系统默认2小时）

int keepinterval = 1;  // 发送检測包间隔 （系统默认75s）

int keepcount = 5;  // 发送次数假设5次都没有回应，就认定peer端断开了。

（系统默认9次）

setsockopt(fd, SOL_SOCKET, SO_KEEPALIVE,&keepalive, sizeof(keepalive));

setsockopt(fd, IPPROTO_TCP, TCP_KEEPIDLE,&keepidle, sizeof(keepidle));

setsockopt(fd, IPPROTO_TCP, TCP_KEEPINTVL,&keepinterval, sizeof(keepinterval));

setsockopt(fd, IPPROTO_TCP, TCP_KEEPCNT,&keepcount, sizeof(keepcount));

这种情况下，client没有问题了，能够主动关闭，可是服务端还是在死等。也就是说keepalive没起作用。

事实上我也没有查到原因，插一句题外话。百度搜索真是不好用（偏偏google被封了，公司也不肯买vpn，有种淡淡的忧伤）。

后来我用了一个没有被封的google ip搜索到了这样一个属性，TCP_USER_TIMEOUT (since Linux 2.6.37)。

链接：http://man7.org/linux/man-pages/man7/tcp.7.html

This option takes an unsigned int as anargument.  When the

value is greater than 0, it specifies themaximum amount of

time in milliseconds that transmitted datamay remain

unacknowledged before TCP will forciblyclose the

corresponding connection and returnETIMEDOUT to the

application.  If the option value is specified as 0, TCPwill

to use the system default.

Increasing user timeouts allows a TCPconnection to survive

extended periods without end-to-endconnectivity.  Decreasing

user timeouts allows applications to"fail fast", if so

desired. Otherwise, failure may take up to 20 minutes with

the current system defaults in a normal WANenvironment.

This option can be set during any state ofa TCP connection,

but is only effective during thesynchronized states of a

connection (ESTABLISHED, FIN-WAIT-1,FIN-WAIT-2, CLOSE-WAIT,

CLOSING, and LAST-ACK).  Moreover, when used with the TCP

keepalive (SO_KEEPALIVE) option,
TCP_USER_TIMEOUT will

overridekeepalive to determine when to close a connection due

to keepalivefailure.

The option has no effect on when TCPretransmits a packet, nor

when a keepalive probe is sent.

This option, like many others, will beinherited by the socket

returned by accept(2), if it was set on thelistening socket.

Further details on the user timeout featurecan be found in

RFC 793 and RFC 5482 ("TCP UserTimeout Option").

所以我们在服务端加上了TCP_USER_TIMEOUT属性，问题就攻克了。

unsigned int timeout = 10000;  // 10s
setsockopt(fd, IPPROTO_TCP, TCP_USER_TIMEOUT, &timeout, sizeof(timeout));

后来又搜索了一下，在以下的文章里找到了印证。

下面做一下摘录。原文请见:http://blog.leeyiw.org/tcp-keep-alive/

使用TCP KEEP-ALIVE与TCP_USER_TIMEOUT机制推断通信对端是否存活

第一个问题：

在对端的网线被拔、网卡被卸载或者禁用的时候。对端没有机会向本地操作系统发送TCP RST或者FIN包来关闭连接。

这时候操作系统不会觉得对端已经挂了。

所以在调用send函数的时候。返回的仍然是我们指定发送的数据字节数。

当我们无法通过send的返回值来推断对端是否存活的情况下。就要使用TCP Keep-alive机制了。

在《Unix网络编程（卷一）》中提到，使用SO_KEEPALIVE套接字选项启用对套接字的保活（Keep-alive）机制。

给一个TCP套接口设置保持存活（keepalive）选项后，假设在2小时内在此套接口的任一方向都没有数据交换。TCP就自己主动给对方发一个保持存活探測分节（keepalive probe）。

TCP提供了这样的机制帮我们推断对端是否存活，假设对端没有对KeepAlive包进行正常的响应，则会导致下一次对套接字的send或者recv出错。应用程序就能够检測到这个异常。

第二个问题:

假设发送方发送的数据包没有收到接收方回复的ACK数据包。则TCP Keep-alive机制就不会被启动，而TCP会启动超时重传机制。这样就使得TCP Keep-alive机制在未收到ACK包时失效。