利用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包时失效。
posted on 2017-05-29 11:41 yjbjingcha 阅读(604) 评论(0) 编辑 收藏 举报