tcp 服务端如何判断客户端断开链接

一篇文章：

 

最近在作一个服务器端程序，C/S结构。功能方面比较简单就是client端与server端创建链接，而后发送消息给server。 我在server端会使用专门的线程处理一条socket链接。这就涉及到一个问题，若是socket链接断开（异常，正常）后，我如何才能感知到？server端这边是绝对被动的，sever端不能主动断开链接。也没有链接链路维持包之类的。client端发送数据的时间也是不定的。在socket链接断开后， server要可以感知到并释放资源。
这个问题在思考测试，询问同事以后，找到了一个方法，能够作到这一点。
当使用 select()函数测试一个socket是否可读时，若是select()函数返回值为1，且使用recv()函数读取的数据长度为0 时，就说明该socket已经断开。
为了更好的断定socket是否断开，我判断当recv()返回值小于等于0时，socket链接断开。可是还须要判断 errno是否等于 EINTR 。若是errno == EINTR 则说明recv函数是因为程序接收到信号后返回的，socket链接仍是正常的，不该close掉socket链接。

PS：对于堵塞socket的recv函数会在如下三种状况下返回：
（1）recv到数据时，会返回。
（2）在整个程序接收到信号时，返回-1。 errno = EINTR。//在程序的起始阶段，屏蔽掉信号的除外。部分信号仍是屏蔽不掉的。
（3）socket出现问题时，返回-1.具体错误码看 man recv()
（4）必定要看 man 说明，很详细，颇有帮助。
这种方法通过长时间测试后，是有效的。因此写出来让你们参考一下，请你们发表意见。

 

参考： http://www.cppblog.com/prayer/archive/2009/04/14/79900.aspx

 

tcp会自动断开链接吗？

已经创建了TCP链接，并可能互通讯息。可是若是长时间不进行信息的传递。这个TCP链接会自动断开吗？
若是能自动断开的话，这个时间大约是多少呢？

回答： TCP的保活定时器可以保证TCP链接一直保持，可是TCP的保活定时器不是每一个TCP/IP协议栈就实现了，由于RFC并不要求TCP保活定时器必定要实现。

摘自《TCP/IP详解》卷1第23章：保活并非T C P规范中的一部分。Host Requirements RFC提供了3个不使用保活定
时器的理由： (1) 在出现短暂差错的状况下，这可能会使一个很是好的链接释放掉；
（2）它们耗费没必要要的带宽；（3）在按分组计费的状况下会在互联网上花掉更多的钱。
然而，许多实现提供了保活定时器。

更具体的资料，请参阅RFC。

tcp/ip详解更全面的描述：

tcp保活定时器

23.1介绍

在一个空闲的（idle）TCP链接上，没有任何的数据流，许多TCP/IP的初学者都对此感到惊奇。也就是说，若是TCP链接两端没有任何一个进程在向对方发送数据，那么在这两个TCP模块之间没有任何的数据交换。你可能在其它的网络协议中发现有轮询（polling），但在TCP中它不存在。言外之意就是咱们只要启动一个客户端进程，同服务器创建了TCP链接，无论你离开几小时，几天，几星期或是几个月，链接依旧存在。中间的路由器可能崩溃或者重启，电话线可能go down或者back up，只要链接两端的主机没有重启，链接依旧保持创建。

这就能够认为无论是客户端的仍是服务器端的应用程序都没有应用程序级（application-level）的定时器来探测链接的不活动状态（inactivity），从而引发任何一个应用程序的终止。回忆在10.7结束，BGP每隔30秒就向对方发送一个应用程序探测。这是一个应用程序定时器（application timer），与TCP存活定时器不一样。

然而有的时候，服务器须要知道客户端主机是否已崩溃而且关闭，或者崩溃但重启。许多实现提供了存活定时器来完成这个任务。

存活（keepalive）并非TCP规范的一部分。在Host Requirements RFC罗列有不使用它的三个理由：（1）在短暂的故障期间，它们可能引发一个良好链接（good connection）被释放（dropped），（2）它们消费了没必要要的宽带，（3）在以数据包计费的互联网上它们（额外）花费金钱。然而，在许多的实现中提供了存活定时器。

存活定时器是一个包含争议的特征。许多人认为，即便须要这个特征，这种对对方的轮询也应该由应用程序来完成，而不是由TCP中实现。一些人对这个话题表现了极大的热情，甚至达到宗教般的狂热。

若是两个终端系统之间的某个中间网络上有链接的暂时中断，那么存活选项（option）就可以引发两个进程间一个良好链接的终止。例如，若是正好在某个中间路由器崩溃、重启的时候发送存活探测，TCP就将会认为客户端主机已经崩溃，但事实并不是如此。

一些服务器应用程序可能表明客户端占用资源，它们须要知道客户端主机是否崩溃。存活定时器能够为这些应用程序提供探测服务。Telnet服务器和Rlogin服务器的许多版本都默认提供存活选项。

我的计算机用户使用TCP/IP协议经过Telnet登陆一台主机，这是可以说明须要使用存活定时器的一个经常使用例子。若是某个用户在使用结束时只是关掉了电源，而没有注销（log off），那么他就留下了一个半打开（half-open）的链接。在图18.16，咱们看到如何在一个半打开链接上经过发送数据，获得一个复位（reset）返回，但那是在客户端，是由客户端发送的数据。若是客户端消失，留给了服务器端半打开的链接，而且服务器又在等待客户端的数据，那么等待将永远持续下去。存活特征的目的就是在服务器端检测这种半打开链接。

更多： http://blog.csdn.net/zhoujunyi/article/details/1920871

个人方法不同，我用getsockopt来判断，仍是蛮准确的 

int SocketConnected(int sock)
{
if(sock<=0)
return 0;
struct tcp_info info;
int len=sizeof(info);
getsockopt(sock, IPPROTO_TCP, TCP_INFO, &info, (socklen_t *)&len);
if((info.tcpi_state==TCP_ESTABLISHED))
{
//myprintf("socket connected\n");
return 1;
}
else
{
//myprintf("socket disconnected\n");
return 0;
}
}

tcp_info和TCP_ESTABLISHED在 linux/tcp.h

包含

#include <linux/types.h>
#include <asm/byteorder.h>
#include <linux/config.h>
#include < linux/skbuff.h>
#include < linux/ip.h>
#include < net/sock.h>

 

http://www.cse.scu.edu/~dclark/am_256_graph_theory/linux_2_6_stack/globals.html#index_t

int SocketConnected(int sock) 
{ 
if(sock<=0) 
return 0; 
struct tcp_info info; 
int len=sizeof(info); 
getsockopt(sock, IPPROTO_TCP, TCP_INFO, &info, (socklen_t *)&len); 
if((info.tcpi_state==TCP_ESTABLISHED)) 
{ 
//myprintf("socket connected\n"); 
return 1; 
} 
else 
{ 
//myprintf("socket disconnected\n"); 
return 0; 
} 
}

 

 

 

 

目前主要有三种方法来实现用户掉线检测：SO_KEEPALIVE ,SIO_KEEPALIVE_VALS 和Heart-Beat线程。

下面我就上面的三种方法来作一下介绍。

(1)SO_KEEPALIVE 机制

        这是socket库提供的功能，设置接口是setsockopt API：

   BOOL bSet=TRUE;

   setsockopt(hSocket,SOL_SOCKET,SO_KEEPALIVE,(const char*)&bSet,sizeof(BOOL));

       根据MSDN的文档，若是为socket设置了KEEPALIVE选项，TCP/IP栈在检测到对方掉线后，

   任何在该socket上进行的调用(发送/接受调用)就会马上返回，错误号是WSAENETRESET ；

   同时，此后的任何在该socket句柄的调用会马上失败，并返回WSAENOTCONN错误。

 

   该机制的缺点也很明显：

         默认设置是空闲2小时才发送一个“保持存活探测分节”，不能保证明时检测！

   固然也能够修改时间间隔参数，可是会影响到全部打开此选项的套接口！

         关联了完成端口的socket可能会忽略掉该套接字选项。

 

 

(2)SIO_KEEPALIVE_VALS 机制

         设置接口是WSAIoctl API:

     DWORD dwError = 0L ;

     tcp_keepalive sKA_Settings = {0}, sReturned = {0} ;

     sKA_Settings.onoff = 1 ;

     sKA_Settings.keepalivetime = 5500 ; // Keep Alive in 5.5 sec.

     sKA_Settings.keepaliveinterval = 3000 ; // Resend if No-Reply

     if (WSAIoctl(skNewConnection, SIO_KEEPALIVE_VALS, &sKA_Settings,

          sizeof(sKA_Settings), &sReturned, sizeof(sReturned), &dwBytes,

          NULL, NULL) != 0)

     {

           dwError = WSAGetLastError() ;

     }

     实现时须要添加tcp_keepalive and SIO_KEEPALIVE_VALS的定义文件MSTCPiP.h

     该选项不一样于SO_KEEPALIVE 机制的就是它是针对单个链接的，对系统其余的套接

     口并不影响。

        针对完成端口的socket,设置了SIO_KEEPALIVE_VALS后，激活包由TCP STACK来负责。

     当网络链接断开后，TCP STACK并不主动告诉上层的应用程序，可是当下一次RECV或者SEND操做

     进行后，立刻就会返回错误告诉上层这个链接已经断开了.若是检测到断开的时候，在这个链接

     上有正在PENDING的IO操做，则立刻会失败返回.

 

 

     该机制的缺点：

             不通用啦。MS的API只能用于Windows拉。不过，优雅一些^_^.

    

(3)Heart-Beat线程

        没说的。本身写一个后台线程，实现Heart-Beat包，客户端受到该包后，马上返回相应的反馈 包。

 

    该方法的好处是通用，但缺点就是会改变现有的通信协议！

/* Net check Make sure you have not used OUT OF BAND DATA AND YOU CAN use OOB */
int netcheck(int fd) 
{
        int buf_size = 1024;
        char buf[buf_size];
        //clear OOB DATA 
        recv(fd, buf, buf_size);
        if(send(fd, (void *)"\0", 1, MSG_OOB) < 0 )
        {
                fprintf(stderr, "Connection[%d] send OOB failed, %s", fd, strerror(errno));
                return -1;
        }
        return 0;
}

/* Setting SO_TCP KEEPALIVE */
//int keep_alive = 1;//设定KeepAlive
//int keep_idle = 1;//开始首次KeepAlive探测前的TCP空闭时间
//int keep_interval = 1;//两次KeepAlive探测间的时间间隔
//int keep_count = 3;//断定断开前的KeepAlive探测次数
void set_keepalive(int fd, int keep_alive, int keep_idle, int keep_interval, int keep_count)
{
        int opt = 1;
        if(keep_alive)
        {
                if(setsockopt(fd, SOL_SOCKET, SO_KEEPALIVE,
                                        (void*)&keep_alive, sizeof(keep_alive)) == -1)
                {
                        fprintf(stderr, 
                                "setsockopt SOL_SOCKET::SO_KEEPALIVE failed, %s\n",strerror(errno));
                }
                if(setsockopt(fd, SOL_TCP, TCP_KEEPIDLE,
                                        (void *)&keep_idle,sizeof(keep_idle)) == -1)
                {
                        fprintf(stderr,
                                "setsockopt SOL_TCP::TCP_KEEPIDLE failed, %s\n", strerror(errno));
                }
                if(setsockopt(fd,SOL_TCP,TCP_KEEPINTVL,
                                        (void *)&keep_interval, sizeof(keep_interval)) == -1)
                {
                        fprintf(stderr,
                                 "setsockopt SOL_tcp::TCP_KEEPINTVL failed, %s\n", strerror(errno));
                }
                if(setsockopt(fd,SOL_TCP,TCP_KEEPCNT,
                                        (void *)&keep_count,sizeof(keep_count)) == -1)
                {
                        fprintf(stderr, 
                                "setsockopt SOL_TCP::TCP_KEEPCNT failed, %s\n", strerror(errno));
                }
        }
}

 

一篇文章:

keep alive VS heart beart:

这周在上班的路上看了本书《Effective TCP/IP Programming》，如下是一些读书笔记。顺带推荐一下这本书，写的很棒，适用于像我这样常常要写一些有必定质量的网络编程，但又没时间啃那些讲解TCPIP协议大部头书的人。

不少人都知道TCP并不会去主动检测链接的丢失，这意味着，若是双方不产生交互，那么若是网络断了或者有一方机器崩溃，另一方将永远不知道链接已经不可用了。检测链接是否丢失的方法大体有两种：keepalive和heart-beat。

Keepalive是不少的TCP实现提供的一种机制，它容许链接在空闲的时候双方会发送一些特殊的数据段，并经过响应与否来判断链接是否还存活着（所谓keep~~alive）。我曾经写过一篇关于keepalive的blog ，但后来我也发现，其实keepalive在实际的应用中并不常见。为什么如此？这得归结于keepalive设计的初衷。Keepalive适用于清除死亡时间比较长的链接。 
好比这样的场景：一个用户建立tcp链接访问了一个web服务器，当用户完成他执行的操做后，很粗暴的直接拨了网线。这种状况下，这个tcp链接已经断开了，可是web服务器并不知道，它会依然守护着这个链接。若是web server设置了keepalive，那么它就可以在用户断开网线的大概几个小时之后，确认这个链接已经中断，而后丢弃此链接，回收资源。
采用keepalive，它会先要求此链接必定时间没有活动（通常是几个小时），而后发出数据段，通过屡次尝试后（每次尝试之间也有时间间隔），若是仍没有响应，则判断链接中断。可想而知，整个周期须要很长的时间。
因此，如前面的场景那样，须要一种方法可以清除和回收那些在系统不知情的状况下死去了好久的链接，keepalive是很是好的选择。 
可是，在大部分状况下，特别是分布式环境中，咱们须要的是一个可以快速或者实时监控链接状态的机制，这里，heart-beat才是更加合适的方案。 
Heart-beat（心跳），按个人理解，它的原理和keepalive很是相似，都是发送一个信号给对方，若是屡次发送都没有响应的话，则判断链接中断。它们的不一样点在于，keepalive是tcp实现中内建的机制，是在建立tcp链接时经过设置参数启动keepalive机制；而heart-beat则须要在tcp之上的应用层实现。一个简单的heart-beat实现通常测试链接是否中断采用的时间间隔都比较短，能够很快的决定链接是否中断。而且，因为是在应用层实现，由于能够自行决定当判断链接中断后应该采起的行为，而keepalive在判断链接失败后只会将链接丢弃。关于heart-beat，一个很是有趣的问题是，应该在传输真正数据的链接中发送“心跳”信号，仍是能够专门建立一个发送“心跳”信号的链接。好比说，A，B两台机器之间经过链接m来传输数据，如今为了可以检测A，B之间的链接状态，咱们是应该在链接m中传输“心跳”信号，仍是建立新的链接n来专门传输“心跳”呢？我我的认为二者皆可。若是担忧的是端到端的链接状态，那么就直接在该条链接中实现“心跳”。但不少时候，关注的是网络情况和两台主机间的链接状态，这种状况下， 建立专门的“心跳”链接也何尝不可。