如果TCP连接被对方正常关闭，也就是说，对方是正确地调用了closesocket(s)或者shutdown(s)的话，那么上面的Recv或Send调用就能马上返回，并且报错。这是由于close  socket(s)或者shutdown(s)有个正常的关闭过程，会告诉对方TCP连接已经关闭，你不需要再发送或者接受消息了。

        但是，如果意外断开，客户端(3g的移动设备)并没有正常关闭socket。双方并未按照协议上的四次挥手去断开连接。

        那么这时候正在执行Recv或Send操作的一方就会因为没有任何连接中断的通知而一直等待下去，也就是会被长时间卡住。

        像这种如果一方已经关闭或异常终止连接，而另一方却不知道，我们将这样的TCP连接称为半打 的。

        解决意外中断办法都是利用保活机制。而保活机制分又可以让底层实现也可自己实现。

        1、 自己编写心跳包程序

        简单的说也就是在自己的程序中加入一条线程，定时向对端发送数据包，查看是否有ACK，如果有则连接正常，没有的话则连接断开

        2、 启动TCP编程里的keepAlive机制

        一）双方拟定心跳(自实现)

        一般由客户端发送心跳包，服务端并不回应心跳，只是定时轮询判断一下与上次的时间间隔是否超时(超时时间自己设定)。服务器并不主动发送是不想增添服务器的通信量，减少压力。

        但这会出现三种情况：

        情况1.

        客户端由于某种网络延迟等原因很久后才发送心跳(它并没有断)，这时服务器若利用自身设定的超时判断其已经断开，而后去关闭socket。若客户端有重连机制，则客户端会重新连接。若不确定这种方式是否关闭了原本正常的客户端，则在ShutDown的时候一定要选择send,表示关闭发送通道，服务器还可以接收一下，万一客户端正在发送比较重要的数据呢，是不?

        情况2.

        客户端很久没传心跳，确实是自身断掉了。在其重启之前，服务端已经判断出其超时，并主动close，则四次挥手成功交互。

        情况3.

        客户端很久没传心跳，确实是自身断掉了。在其重启之前，服务端的轮询还未判断出其超时，在未主动close的时候该客户端已经重新连接。

        这时候若客户端断开的时候发送了FIN包，则服务端将会处于CLOSE_WA上网行为状态;

        这时候若客户端断开的时候未发送FIN包，则服务端处还是显示ESTABLISHED状态;

        而新连接上来的客户端(也就是刚才断掉的重新连上来了)在服务端肯定是ESTABLISHED;这时候就有个问题，若利用轮询还未检测出上条旧连接已经超时(这很正常，timer总有个间隔吧)，而在这时，客户端又重复的上演情况3，那么服务端将会出现大量的假的ESTABLISHED连接和CLOSE_WA上网行为连接。

        最终结果就是新的其他客户端无法连接上来，但是利用netstat还是能看到一条连接已经建立，并显示ESTABLISHED，但始终无法进入程序代码。个人最初感觉导致这种情况是因为假的ESTABLISHED连接和  CLOSE_WA上网行为连接会占用较大的系统资源，程序无法再次创建连接(因为每次我发现这个问题的时候我只连了10个左右客户端却已经有40多条无效连接)。而最近几天测试却发现有一次程序内只连接了2，3个设备，但是有8条左右的虚连接，此时已经连接不了新客户端了。这时候我就觉得我想错了，不可能这几条连接就占用了大量连接把，如果说几十条还有可能。但是能肯定的是，这个问题的产生绝对是设备在不停的重启，而服务器这边又是简单的轮询，并不能及时处理，暂时还未能解决。

        二）利用KeepAlive

        其实keepalive的原理就是TCP内嵌的一个心跳包,

        以服务器端为例，如果当前 server 端检测到超过一定时间(默认是 7,200,000 milliseconds ，也就是 2  个小时)没有数据传输，那么会向 client 端发送一个 keep-alive packet (该 keep-alive packet 就是 ACK和 当前  TCP 序列号减一的组合)，此时 client 端应该为以下三种情况之一：

        1. client 端仍然存在，网络连接状况良好。此时 client 端会返回一个 ACK 。server 端接收到  ACK 后重置计时器(复位存活定时器)，在 2 小时后再发送探测。如果 2 小时内连接上有数据传输，那么在该时间基础上向后推延 2 个小时。

        2. 客户端异常关闭，或是网络断开。在这两种情况下， client  端都不会响应。服务器没有收到对其发出探测的响应，并且在一定时间(系统默认为 1000 ms )后重复发送 keep-alive packet  ，并且重复发送一定次数( 2000 XP 2003 系统默认为 5 次 , Vista 后的系统默认为 10 次)。

        3.  客户端曾经崩溃，但已经重启。这种情况下，服务器将会收到对其存活探测的响应，但该响应是一个复位，从而引起服务器对连接的终止。

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

        全局设置可更改 /etc/sysctl.conf ,加上:

        net.ipv4.tcp_keepalive_intvl = 20

        net.ipv4.tcp_keepalive_probes = 3

        net.ipv4.tcp_keepalive_time = 60

        在程序中设置如下:

        #include sys/socket.h  
 #include netinet/in.h  
 #include arpa/inet.h  
 #include sys/types.h  
 #include netinet/tcp.h  
  
 int keepAlive = 1; // 开启keepalive属性  
 int keepIdle = 60; // 如该连接在60秒内没有任何数据往来,则进行探测   
 int keepInterval = 5; // 探测时发包的时间间隔为5 秒  
 int keepCount = 3; // 探测尝试的次数.如果第1次探测包就收到响应了,则后2次的不再发.  
  
 setsockopt(rs, SOL_SOCKET, SO_KEEPALIVE, (void *)keepAlive, sizeof(keepAlive));  
 setsockopt(rs, SOL_TCP, TCP_KEEPIDLE, (void*)keepIdle, sizeof(keepIdle));  
 setsockopt(rs, SOL_TCP, TCP_KEEPINTVL, (void *)keepInterval, sizeof(keepInterval));  
 setsockopt(rs, SOL_TCP, TCP_KEEPCNT, (void *)keepCount, sizeof(keepCount));

        在程序中表现为,当tcp检测到对端socket不再可用时(不能发出探测包,或探测包没有收到ACK的响应包),select会返回socket可读,并且在recv时返回-1,同时置上errno为ETIMEDOUT.