无论Windows还是linux，Keepalive就三个配置参数。下文以linux环境为介绍。
tcp_sock结构体中有三个有关的成员变量。
keepalive_probes ： 探测次数
keepalive_time ： 探测的超时时间
keepalive_intvl ： 探测间隔
对 于一个已经建立的tcp连接。如果在keepalive_time时间内双方没有任何的数据包传输，则开启keepalive功能的一端将发送 keepalive数据包，若没有收到应答，则每隔keepalive_intvl时间再发送该数据包，发送keepalive_probes次。如果一直没有收到对方应答，则发送rst包关闭连接。若收到应答，则将计时器清零。
对keepalive进行如下设置：
sk->keepalive_probes = 3;
sk->keepalive_time = 30;
sk->keepalive_intvl = 1;
意 思就是说对于tcp连接，如果一直在socket上有数据来往就不会触发keepalive，但是如果30秒一直没有数据往来，则keep alive开始工作：发送keepalive探测包，发端受到响应则认为网络是好的，结束探测；如果没有响应，每隔1秒发探测包，一共发送3次，3次后仍没有相应，则发送RST包关闭连接。也就是从网络开始到你的socket能够意识到网络异常，最多花33秒。但是如果没有设置keep alive，可能你在你的socket（阻塞性）的上面接收: recv会一直阻塞不能返回，除非对端主动关闭连接，因为recv不知道socket断了。对于发送方来说，取决于发送数据量的大小，只要底层协议栈的buffer能放下你的发送数据，应用程序级别的send就会一直成功返回。 直到buffer满，甚至buffer满了还要阻塞一段时间试图等待buffer空闲。所以对send的返回值的检查根本检测不到失败。开启了keep alive功能，你直接通过发送接收的函数返回值就可以知道网络是否异常。
但是，tco自己的keepalive有这样的缺点:
正常情况下，连接的另一端主动调用close关闭连接，tcp会通知，应用层知道该连接已经关闭。但是如果tcp连接的另一端因为某种情况，突然掉线，或者断电重启，这个时候，发送端并不知道网络已经关闭了，而此时，发送端如果有数据发送，tcp就会自动进行重传，重传数据包的优先级高于keepalive，那就意味着，我们的keepalive总是不能发送出去，而此时，我们也并不知道该连接已经出错而中断，在较长时机的重传失败之后，我们才知道。
为了避免上述情况发生，在应用层上，要自行设计控制流程，对于消息，记录发送和收到回应的时间，如果长时间没有回应，就有可能是网络中断，如果长时间没有数据交互，可以在应用层自己构造一个类似于keepalive的短小数据来确认链接的存在。