rtspsever网络编程中的socket选项之keepalive

从代码可以看出，初始化的时候，设置了keepalive变量，

static void SetSockeKeepAlive(SOCKET connect){    int keepAlive = 1;  // 开启keepalive属性    int keepIdle = 1;   // 如该连接在1秒内没有任何数据往来,则进行探测    int keepInterval = 1; // 探测时发包的时间间隔为1 秒    int keepCount = 5; // 探测尝试的次数.如果第1次探测包就收到响应了,则后4次的不再发.    setsockopt(connect, SOL_SOCKET, SO_KEEPALIVE, (void *)&keepAlive, sizeof(keepAlive));    setsockopt(connect, SOL_TCP, TCP_KEEPIDLE, (void*)&keepIdle, sizeof(keepIdle));    setsockopt(connect, SOL_TCP, TCP_KEEPINTVL, (void *)&keepInterval, sizeof(keepInterval));    setsockopt(connect, SOL_TCP, TCP_KEEPCNT, (void *)&keepCount, sizeof(keepCount));}

第一：keepalive存在的目的是：为了探知客户端是否存活。

第二：协议解读

下面协议解读，基于RFC1122#TCP Keep-Alives。

1. TCP Keepalive虽不是标准规范，但操作系统一旦实现，默认情况下须为关闭，可以被上层应用开启和关闭。
2. TCP Keepalive必须在没有任何数据（包括ACK包）接收之后的周期内才会被发送，允许配置，默认值不能够小于2个小时
3. 不包含数据的ACK段在被TCP发送时没有可靠性保证，意即一旦发送，不确保一定发送成功。系统实现不能对任何特定探针包作死连接对待
4. 规范建议keepalive保活包不应该包含数据，但也可以包含1个无意义的字节，比如0x0。
5. SEG.SEQ = SND.NXT-1，即TCP保活探测报文序列号将前一个TCP报文序列号减1。SND.NXT = RCV.NXT，即下一次发送正常报文序号等于ACK序列号；总之保活报文不在窗口控制范围内 有一张图，可以很容易说明，但请仔细观察Tcp Keepalive部分：

第三：常用使用模式

1. 默认情况下使用keepalive周期为2个小时，如不选择更改，属于误用范畴，造成资源浪费：内核会为每一个连接都打开一个保活计时器，N个连接会打开N个保活计时器。 优势很明显：

• TCP协议层面保活探测机制，系统内核完全替上层应用自动给做好了
• 内核层面计时器相比上层应用，更为高效
• 上层应用只需要处理数据收发、连接异常通知即可
• 数据包将更为紧凑

1. 关闭TCP的keepalive，完全使用业务层面心跳保活机制 完全应用掌管心跳，灵活和可控，比如每一个连接心跳周期的可根据需要减少或延长
2. 业务心跳 + TCP keepalive一起使用，互相作为补充，但TCP保活探测周期和应用的心跳周期要协调，以互补方可，不能够差距过大，否则将达不到设想的效果。朋友的公司所做IM平台业务心跳2-5分钟智能调整 + tcp keepalive 300秒，组合协作，据说效果也不错。

虽然说没有固定的模式可遵循，那么有以下原则可以参考：

• 不想折腾，那就弃用TCP Keepalive吧，完全依赖应用层心跳机制，灵活可控性强
• 除非可以很好把控TCP Keepalive机制，那就可以根据需要自由使用吧

当然还可以用开源的libkeepalive库，结合使用，比较好！

如下：http://libkeepalive.sourceforge.net/

部分内容参考：http://www.blogjava.net/yongboy/archive/2015/04/14/424413.html