TCP KEEP-ALIVE和TCP_USER_TIMEOUT机制

正常通信的情况下,send函数发送成功会返回发送数据的字节数。当有错误发生时,send返回-1,全局变量errno被设置。很多情况下,send返回-1是由于连接被对端关闭(对端发送了RST或者FIN包),这种情况errno会被设置为ECONNRESET(Connection reset by peer)。

可是在对端的网线被拔、网卡被卸载或者禁用的时候,对端没有机会向本地操作系统发送TCP RST或者FIN包来关闭连接。这时候操作系统不会认为对端已经挂了。所以在调用send函数的时候,返回的仍然是我们指定发送的数据字节数。当我们无法通过send的返回值来判断对端是否存活的情况下,就要使用TCP Keep-alive机制了。

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

给一个TCP套接口设置保持存活(keepalive)选项后,如果在2小时内在此套接口的任一方向都没有数据交换,TCP就自动给对方发一个保持存活探测分节(keepalive probe)。

TCP提供了这种机制帮我们判断对端是否存活,如果对端没有对KeepAlive包进行正常的响应,则会导致下一次对套接字的send或者recv出错。应用程序就可以检测到这个异常。

设置KeepAlive机制的选项如下代码所示:

int keep_alive = 1;
int keep_idle = 5, keep_interval = 1, keep_count = 3;
int ret = 0;

if (-1 == (ret = setsockopt(fd, SOL_SOCKET, SO_KEEPALIVE, &keep_alive,
    sizeof(keep_alive)))) {
    fprintf(stderr, "[%s %d] set socket to keep alive error: %s", __FILE__,
        __LINE__, ERRSTR);
}
if (-1 == (ret = setsockopt(fd, IPPROTO_TCP, TCP_KEEPIDLE, &keep_idle,
    sizeof(keep_idle)))) {
    fprintf(stderr, "[%s %d] set socket keep alive idle error: %s", __FILE__,
        __LINE__, ERRSTR);
}
if (-1 == (ret = setsockopt(fd, IPPROTO_TCP, TCP_KEEPINTVL, &keep_interval,
    sizeof(keep_interval)))) {
    fprintf(stderr, "[%s %d] set socket keep alive interval error: %s", __FILE__,
        __LINE__, ERRSTR);
}
if (-1 == (ret = setsockopt(fd, IPPROTO_TCP, TCP_KEEPCNT, &keep_count,
    sizeof(keep_count)))) {
    fprintf(stderr, "[%s %d] set socket keep alive count error: %s", __FILE__,
        __LINE__, ERRSTR);
}
  1. 设置SO_KEEPALIVE选项,将这个选项设置为1,代表打开KeepAlive机制。
  2. 设置TCP_KEEPIDLE选项,值为5秒,代表如果TCP连接上有五秒钟没有任何数据包传输,则启动保活机制,发送TCP Keep-alive机制。默认为2小时。
  3. 设置TCP_KEEPINTVL选项,值为1秒,代表如果启动保活机制,则每隔1秒发送一个Keep-alive包。默认为75秒。
  4. 设置TCP_KEEPCNT选项,值为3,代表如果对端对3次Keep-alive数据包都没有正常响应,则判断对端已经崩溃。默认为9。

这样断网的判断问题就解决了。

但是如果发送方发送的数据包没有收到接收方回复的ACK数据包,则TCP Keep-alive机制就不会被启动,而TCP会启动超时重传机制,这样就使得TCP Keep-alive机制在未收到ACK包时失效。在查阅这个问题时找到了stackoverflow上面的资料:http://stackoverflow.com/questions/5907527/application-control-of-tcp-retransmission-on-linux

根据排名第一的回答表示,Linux Kernel 2.6.37中增加了一个叫做TCP_USER_TIMEOUT的socket选项。答案大意是,TCP_USER_TIMEOUT选项是TCP层的socket选项,选项接受unsigned int类型的值。值为数据包被发送后未接收到ACK确认的最大时长,以毫秒为单位,例如设置为10000时,代表如果发送出去的数据包在十秒内未收到ACK确认,则下一次调用send或者recv,则函数会返回-1,errno设置为ETIMEOUT,代表connection timeout。

实现的代码应该如下:

unsigned int timeout = 10000;
if (-1 == setsockopt(fd, IPPROTO_TCP, TCP_USER_TIMEOUT, &timeout, sizeof(timeout))) {
    fprintf(stderror, "set TCP_USER_TIMEOUT option error: %s", strerror(errno));
}

如上所述,使用TCP Keep-alive加上TCP_USER_TIMEOUT机制,就可以完美解决通信对端异常断网、掉电的情况下,连接被长期挂起的问题了。

转自http://blog.leeyiw.org/tcp-keep-alive/;

TCP KEEP-ALIVE和TCP_USER_TIMEOUT机制,布布扣,bubuko.com

时间: 2024-10-24 15:08:51

TCP KEEP-ALIVE和TCP_USER_TIMEOUT机制的相关文章

TCP 连接与TCP keep alive 保活检测机制

生产环境中一台2核4G的linux服务器TCP连接数时常保持在5-7w间徘徊,查看日志每秒的请求数也就100-200,怎么会产生这么大的TCP连接数.检查了下客户端上行的HTTP协议,Connection 头字段是Keep-Alive,并且客户端在请求完之后没有立即关闭连接.而服务端的设计也是根据客户端来的,客户端上行如果Connection:Keep-Alive,服务端是不会主动关闭连接的.在客户端与服务端交互比较频繁的时候,这样的设计还是比较合理的,可以减少TCP的重复握手.显然如果只交互一

HTTTP及TCP的超时以及KEEP-ALIVE机制小结

一.HTTP的超时和Keep Alive HTTP Keepalive 机制是http 1.1中增加的一个功能. 在HTTP 1.0中,客户端每发起一个http 请求,等收到接收方的应答之后就断开TCP.下一个请求再需要发送时,要重新建立TCP连接. 在HTTP 1.1中,客户端每发起一个http请求之后,服务器可以通过keep alive的方式告知客户端,同时保持之前建立的TCP连接.下一个http请求和应答从而能够避免再次建连,通过已有连接继续发送. HTTP层的超时设置实例代码如下,set

TCP Nagle算法&&延迟确认机制

收藏 秋风醉了 发表于 3年前 阅读 1367 收藏 0 点赞 0 评论 0 [腾讯云]买域名送云解析+SSL证书+建站!>>>   摘要: TCP Nagle算法&&延迟确认机制 TCP Nagle算法 http://baike.baidu.com/view/2468335.htm 百度百科:TCP/IP协议中,无论发送多少数据,总是要在数据前面加上协议头,同时,对方接收到数据,也需要发送ACK表示确认.为了尽可能的利用网络带宽,TCP总是希望尽可能的发送足够大的数据.

Linux下TCP延迟确认(Delayed Ack)机制导致的时延问题分析

版权声明:本文由潘安群原创文章,转载请注明出处: 文章原文链接:https://www.qcloud.com/community/article/105 来源:腾云阁 https://www.qcloud.com/community 案例一:同事随手写个压力测试程序,其实现逻辑为:每秒钟先连续发N个132字节的包,然后连续收N个由后台服务回显回来的132字节包.其代码简化如下: char sndBuf[132]; char rcvBuf[132]; while (1) { for (int i

TCP实现可靠传输的机制

实现可靠传输需要保证三个条件: (1)无比特差错传输 (2)字节流不丢不重不乱序 (3)接收方的处理能力大于发送速率 **************************************************************** TCP的首部检验和会检查首部和数据段,保证报文段无比特差错,满足条件(1). 应用程序把数据缓存到发送缓存,接收方TCP把数据放到接收缓存.发送方根据接收方反馈回来的窗口设置发送窗口,窗口是缓存的前片段,缓存内窗口外的字节不允许发送,实现了流量控制,满

TCP协议的确认重传机制

TCP协议是面向连接的传输层协议,TCP的传输特点具有可靠性,它具有面向连接服务来确保可靠稳定传输,而确认重传机制是TCP协议保证可靠稳定传输最重要的机制,他包括累计确认.超时时间计算.快速重传等几个方面. 确认重传机制 在发送一个数据之后,就开启一个定时器,若是在这个时间内没有收到发送数据的ACK确认报文,则对该报文进行重传,在达到一定次数还没有成功时放弃并发送一个复位信号. 1.累计确认 累计确认就是TCP协议的确认方法,TCP使用可变长度报文段来发送数据,重传时,报文段数据可能会比原报文段

TCP拥塞控制机制

我们知道TCP是拥有拥塞控制机制的,而UDP是没有的,为什么需要拥塞控制机制呢,就是防止丢包过多导致传输效率低下.网络中传输的包太多,路由器的缓存又不够,每一个发送端都以自己想要的发送速率发送包,自然会导致网络拥塞.所以我TCP就包括了拥塞控制机制. 有几种拥塞控制方法? 2种 1.端到端拥塞控制.网络层没有显示的告知传输层此时网络出现拥塞了,传输层通过报文段的丢失(超时或3次冗余确认得知)认为网络出现拥塞了,TCP会缩减其拥塞窗口,减小发送速率. 2.网络辅助的拥塞控制.网络层显示的告知发送端

【原创】TCP超时重传机制探索

TCP超时重传机制探索 作者:tll (360电商技术) 1)通信模型 TCP(Transmission Control Protocol)是一种可靠传输协议.在传输过程中当发送方(sender)向接收方(receiver)发送的数据丢失时,将引起发送方向接收方重传丢失的数据包. 其通信模型例如以下: wx_fmt=png" data-ratio="1.5138121546961325" data-w="362" _src="https://mm

tcp可靠传输的机制有哪些(面试必看

一.综述 1.确认和重传:接收方收到报文就会确认,发送方发送一段时间后没有收到确认就重传. 2.数据校验 3.数据合理分片和排序: UDP:IP数据报大于1500字节,大于MTU.这个时候发送方IP层就需要分片(fragmentation).把数据报分成若干片,使每一片都小于MTU.而接收方IP层则需要进行数据报的重组.这样就会多做许多事情,而更严重的是,由于UDP的特性,当某一片数据传送中丢失时,接收方便无法重组数据报.将导致丢弃整个UDP数据报. tcp会按MTU合理分片,接收方会缓存未按序