啊，这个TCP保活机制，真是让我又爱又恨，从入门的欣喜若狂，现在只想让它入土去吧。
什么是保活机制，一开始接触到它是感觉它的心跳检测功能及代码的简便，我比较懒，四行就能解决的事情绝不写一堆。所以我就自动屏蔽了它的另一个特性：
它是TCP实现的，TCP是传输层的东西，这个过程应用层是不知道的。
TCP保活机制的实现过程是这样的：连接中启动保活功能的一端，在保活时间内连接处于非活动状态，则向对方发送一个保活探测报文，如果收到响应，则重置保活计时器，如果没有收到响应报文，则经过一个保活时间间隔后再次向对方发送一个保活探测报文，如果还没有收到响应报文，则继续，直到发送次数到达保活探测数，此时，对方主机将被确认为不可到达，连接被中断。
// 应用TCP保活机制的相关代码
int set_keepalive(int sockfd, int keepalive_time, int keepalive_intvl, int keepalive_probes) {
int optval;
socklen_t optlen = sizeof(optval);
optval = 1;
if (-1 == setsockopt(sockfd, SOL_SOCKET, SO_KEEPALIVE, &optval, optlen)) {
perror("setsockopt failure.");
return -1;
}
optval = keepalive_probes;
if (-1 == setsockopt(sockfd, SOL_TCP, TCP_KEEPCNT, &optval, optlen)) {
perror("setsockopt failure.");
return -1;
}
optval = keepalive_intvl;
if (-1 == setsockopt(sockfd, SOL_TCP, TCP_KEEPINTVL, &optval, optlen)) {
perror("setsockopt failure.");
return -1;
}
optval = keepalive_time;
if (-1 == setsockopt(sockfd, SOL_TCP, TCP_KEEPIDLE, &optval, optlen)) {
perror("setsockopt failure.");
return -1;
}
}
当然，我还看到有另一套
// 应用TCP保活机制的相关代码
int set_keepalive(int sockfd, int keepalive_time, int keepalive_intvl, int keepalive_probes) {
int optval;
socklen_t optlen = sizeof(optval);
optval = 1;
if (-1 == setsockopt(sockfd, SOL_SOCKET, SO_KEEPALIVE, &optval, optlen)) {
perror("setsockopt failure.");
return -1;
}
optval = keepalive_probes;
if (-1 == setsockopt(sockfd, SOL_TCP, TCP_KEEPALIVE, &optval, optlen)) {
perror("setsockopt failure.");
return -1;
}
}
都试过了。
但是就像上面那套黑体字一样，我在应用层无法检测到这个保活机制把哪些客户端关了，我用的是epoll模型，它把客户端关了我得去执行EPOLL_CTL_DEL啊，那向谁执行？不知道啊。
然后我又回顾了一下应用层心跳机制，其实也挺不错的，在这里用一下别人的图：
接下来是文章重点：
TCP协议自带的保活机制和应用层自己写的心跳机制，怎么选。
搁昨天我就选保活机制了，但是经过了一天的挣扎，我还是选心跳机制。为啥呢？
1、其实保活机制也是要收发数据，如果收发心跳包就算负担了那这个服务器可以放手了。
2、当系统关闭一个由KeepAlive 机制检查出来的死连接时，是不会主动通知上层应用的，只能通过调用相应IO操作的返回值中发现。
3、在出现短暂的网络错误的时候，保活机制会使一个好的连接断开。
4、保活机制会占用不必要的带宽。
5、保活机制是存在争议的，主要争议之处在于是否应在TCP协议层实现，有两种主要观点：其一，保活机制不必在TCP协议中提供，而应该有应用层实现；其二，认为大多数应用都需要保活机制，应该在TCP协议层实现。
6、socks代理对保活机制不支持。
综上，我选择应用层自己实现的心跳机制。