TCP连接探测中的Keepalive和心跳包

tcp keepalive  心跳  保活

Linuxtcp心跳keepalive保活
1. TCP保活的必要性
  1) 很多防火墙等对于空闲socket自动关闭
  2) 对于非正常断开, 服务器并不能检测到. 为了回收资源, 必须提供一种检测机制.

2. 导致TCP断连的因素
  如果网络正常, socket也通过close操作来进行优雅的关闭, 那么一切完美. 可是有很多情况, 比如网线故障, 客户端一侧突然断电或者崩溃等等, 这些情况server并不能正常检测到连接的断开.

3. 保活的两种方式:
  1) 应用层面的心跳机制
  自定义心跳消息头. 一般客户端主动发送, 服务器接收后进行回应(也可以不回应). 这里不进行详述.
  PS: 有人从软件的功能角度列出第三种方式, 就是通过第三方软件来进行探测, 确定连接的有效性. 这种方式局限性很大, 而且不属于软件内部的功能实现. 不进行讨论.
  2) TCP协议自带的保活功能
  打开keep-alive功能即可. 具体属性也可以通过API设定.

4. 两种方式的优劣性
  TCP协议自带的保活功能, 使用起来简单, 减少了应用层代码的复杂度. 推测也会更节省流量, 因为一般来说应用层的数据传输到协议层时都会被加上额外的包头包尾. 由TCP协议提供的检活, 其发的探测包, 理论上实现的会更精妙(用更少的字节完成更多的目标), 耗费更少的流量.
  由应用自己实现的应用层的心跳, 为心跳消息额外定义一个消息类型就可以了. 就是应用正常的消息包, 只是这个包特殊点, 专门用来检活而已, 通常比较小, 可能只有消息头就可以了, 除非需要额外的信息.
  应用层心跳的好处我个人的理解有两点:
  一是比较灵活, 因为协议层的心跳只能提供最纯粹的检活功能, 但是应用层自己可以随意控制, 包括协议可能提供的是秒级的, 但是你想做成毫秒级的都任意(虽然实际几乎不会有这种时间级别的心跳), 包里还甚至可以携带额外的信息, 这些都是灵活之处.
  二是通用, 应用层的心跳不依赖协议. 如果有一天不用TCP要改为UDP了, 协议层不提供心跳机制了, 但是你应用层的心跳依旧是通用的, 可能只需要做少许改动就可以继续使用.
应用层心跳的不好的地方也很显而易见, 增加开发工作量, 由于应用特定的网络框架, 还可能很增加代码结构的复杂度. 再就是根据上面的推测, 应用层心跳的流量消耗还是更大的, 毕竟这本质上还是个普通的数据包.

5. 到底选用那种心跳方式?
  优劣点第4节已经进行了阐述, 因此如果能确定你们更换协议的可能性非常小, 同时只是需要检活的功能, 那么用协议自带的就绝对OK了, 使用简单而且高效. 有些自负的人总喜欢用自己搞的, 来代替成熟协议自带的东西, 代替系统内核提供的东西, 其实往往你应用层实现的东西, 都是更拙劣的. 网上看了一些关于协议的Keep-alive不靠谱的说法, 也都比较空想和想当然, 都没有拿出任何事实论据或实验数据. 这点大家有见解, 欢迎交流哈~

6. 类Unix平台如何使用Keep-alive
  keepalive默认是关闭的, 因为虽然流量极小, 毕竟是开销. 因此需要用户手动开启. 有两种方式开启.
  1) 在代码里针对每个socket进行单独设定, 使用起来灵活.
  除了keepAlive 开关, 还有keepIdle, keepInterval, keepCount 3个属性, 使用简单, 如下:

1 int keepAlive = 1; // 开启keepalive属性. 缺省值: 0(关闭)
2 int keepIdle = 60; // 如果在60秒内没有任何数据交互,则进行探测. 缺省值:7200(s)
3 int keepInterval = 5; // 探测时发探测包的时间间隔为5秒. 缺省值:75(s)
4 int keepCount = 2; // 探测重试的次数. 全部超时则认定连接失效..缺省值:9(次)
5 setsockopt(s, SOL_SOCKET, SO_KEEPALIVE, (void*)&keepAlive, sizeof(keepAlive));
6 setsockopt(s, SOL_TCP, TCP_KEEPIDLE, (void*)&keepIdle, sizeof(keepIdle));
7 setsockopt(s, SOL_TCP, TCP_KEEPINTVL, (void*)&keepInterval, sizeof(keepInterval));
8 setsockopt(s, SOL_TCP, TCP_KEEPCNT, (void*)&keepCount, sizeof(keepCount)); 

  使用时需要#include <netinet/tcp.h>, 否则 SOL_TCP 和 TCP_KEEPIDLE 等3个宏找不到.

  ps: 忍不住吐槽一下, 网上大量毫不负责的转载, 千篇一律的搜索结果, 很多人根本都没进行过任何验证吧. 为了找这么个头文件都费了不小的事. 大多数帖子里的说的都是不可用的.

  2) 修改配置文件, 对整个系统所有的socket有效.

  我们可以用cat命令查看到系统中这几个默认的值.

#cat /proc/sys/net/ipv4/tcp_keepalive_time 7200
#cat /proc/sys/net/ipv4/tcp_keepalive_intvl 75
#cat /proc/sys/net/ipv4/tcp_keepalive_probes 9

修改它们:

#echo 60 > /proc/sys/net/ipv4/tcp_keepalive_time
#echo 5 > /proc/sys/net/ipv4/tcp_keepalive_intvl
#echo 3 > /proc/sys/net/ipv4/tcp_keepalive_probes

推荐阅读(文章后面的评论也不错):

    http://www.felix021.com/blog/read.php?2076

    http://www.tldp.org/HOWTO/html_single/TCP-Keepalive-HOWTO/

来源:http://blog.csdn.net/aa2650/article/details/17027845

作者:风波

mail : [email protected]

时间: 2024-11-02 14:33:48

TCP连接探测中的Keepalive和心跳包的相关文章

TCP连接探测中的Keepalive 和心跳包

采用TCP连接的C/S模式软件,连接的双方在连接空闲状态时,如果任意一方意外崩溃.当机.网线断开或路由器故障,另一方无法得知TCP连接已经失效,除非继续在此连接上发送数据导致错误返回.很多时候,这不是我们需要的.我们希望服务器端和客户端都能及时有效地检测到连接失效,然后优雅地完成一些清理工作并把错误报告给用户. 如何及时有效地检测到一方的非正常断开,一直有两种技术可以运用.一种是由TCP协议层实现的Keepalive,另一种是由应用层自己实现的心跳包. TCP默认并不开启Keepalive功能,

TCP连接探测中的Keepalive和心跳包. 关键字: tcp keepalive, 心跳, 保活

1. TCP保活的必要性 1) 很多防火墙等对于空闲socket自动关闭 2) 对于非正常断开, 服务器并不能检测到. 为了回收资源, 必须提供一种检测机制. 2. 导致TCP断连的因素 如果网络正常, socket也通过close操作来进行优雅的关闭, 那么一切完美. 可是有很多情况, 比如网线故障, 客户端一侧突然断电或者崩溃等等, 这些情况server并不能正常检测到连接的断开. 3. 保活的两种方式: 1) 应用层面的心跳机制 自定义心跳消息头. 一般客户端主动发送, 服务器接收后进行回

通过wireshark抓包来讲解HTTP中Connection: keep-alive头部的作用

今天周末时间,有空给大家讲解一个小知识点,即HTTP的keep-alive头部.我使用wireshark来抓取网络包来在实战中讲解.希望能让大家更容易.更直观的理解! HTTP中keep-alive头部的作用是为保持TCP连接,这样可以复用TCP连接不需要为每个HTTP请求都建立一个单独的TCP连接.这样既可以节省操作系统资源,也能够保持HTTP请求的高效性. 我们通过wireshark抓的包来分析一下: 下面的例子中128.14.154.105是HTTP服务器,192.168.1.6是客户端.

图说使用socket建立TCP连接

在网络应用如火如荼的今天,熟悉TCP/IP网络编程,那是最好不过.如果你并不非常熟悉,不妨花几分钟读一读. 为了帮助快速理解,先上个图,典型的使用socket建立和使用TCP/UDP连接过程为(截图来源戳这里): 下面仅讲述TCP连接建立的过程. (参考资料来自这里) 1. Initial State (初始阶段) o TCP is connection based, ... establishing it is a complex multistage process o initially

心跳包(HeartBeat)

http://itindex.net/detail/52922-%E5%BF%83%E8%B7%B3-heartbeat-coderzh 几乎所有的网游服务端都有心跳包(HeartBeat或Ping)的设计,在最近开发手游服务端时,也用到了心跳包.思考思考,心跳包是必须的吗?为什么需要心跳包?TCP没有提供断线检测的方法吗?TCP提供的KeepAlive机制可以替代HeartBeat吗? 由于连接丢失时,TCP不会立即通知应用程序.比如说,客户端程序断线了,服务端的TCP连接不会检测到断线,而是

如何在socket编程的Tcp连接中实现心跳协议

心跳包的发送,通常有两种技术 方法1:应用层自己实现的心跳包 由应用程序自己发送心跳包来检测连接是否正常,大致的方法是:服务器在一个 Timer事件中定时 向客户端发送一个短小精悍的数据包,然后启动一个低级别的线程,在该线程中不断检测客户端的回应, 如果在一定时间内没有收到客户端的回应,即认为客户端已经掉线:同样,如果客户端在一定时间内没 有收到服务器的心跳包,则认为连接不可用. 方法2:TCP的KeepAlive保活机制 因为要考虑到一个服务器通常会连接多个客户端,因此由用户在应用层自己实现心

WPF中使用定时器 DispatcherTimer 做TCP连接中的心跳 HeartBeat

开发过程中经常遇到定时触发的需求,如:TCP/IP连接中,使用心跳包保持连接或检测连接是否已经中断. WPF中有多种定时器: 1.using System.Windows.Threading; 代码如下: using System.Windows.Threading; public partial class MainWindow : Window { DispatcherTimer timerHeartBeat = new DispatcherTimer(); public MainWindo

闲说HeartBeat心跳包和TCP协议的KeepAlive机制

很多应用层协议都有HeartBeat机制,通常是客户端每隔一小段时间向服务器发送一个数据包,通知服务器自己仍然在线,并传输一些可能必要的数据.使用心跳包的典型协议是IM,比如QQ/MSN/飞信等协议. 学过TCP/IP的同学应该都知道,传输层的两个主要协议是UDP和TCP,其中UDP是无连接的.面向packet的,而TCP协议是有连接.面向流的协议. 所以非常容易理解,使用UDP协议的客户端(例如早期的“OICQ”,听说OICQ.com这两天被抢注了来着,好古老的回忆)需要定时向服务器发送心跳包

怎样解决W5200/W5500在TCP通信过程中意外断开?(Keepalive)

在使用W5200和W5500的TCP通信过程中,有一个非常容易被问到的问题: (这里以W5200为例) W5200作为服务器,假如客户端的网线断开 或 瞬间停电,服务器该怎样判断? 那么当客户端由于这些原因忽然断开,该怎样解决? 今天给大家介绍解决以上问题的办法,即如何使用Keepalive. 什么是Keepalive? Keepalive即心跳检测,以下简称KA,之所以称之为心跳检测是因为它像心跳一样每隔一段时间发一次,以此来告诉对方自己是否存活.心跳检测用于TCP通讯过程中服务器检测客户端是