《心跳包机制》由会员分享，可在线阅读，更多相关《心跳包机制（2页珍藏版）》请在金锄头文库上搜索。
1、socket 心跳包机制 跳包之所以叫心跳包是因为：它像心跳一样每隔固定时间发一次，以此来告诉服务器，这个 客户端还活着。事实上这是为了保持长连接，至于这个包的内容，是没有什么特别规定的， 不过一般都是很小的包，或者只包含包头的一个空包。在 TCP 的机制里面，本身是存在有心跳包的机制的，也就是 TCP 的选 项：SO_KEEPALIVE。系统默认是设置的2小时的心跳频率。但是它检查不到机器断电、网线拔出、 防火墙这些断线。而且逻辑层处理断线可能也不是那 么好处理。一般，如果只是用于保活 还是可以的。心跳包一般来说都是在逻辑层发送空的 echo 包来实现的。下一个定时器，在一定 时间间隔下发送
2、一个空包给客户端，然后客户端反馈一个同样的空包回来，服务器如果在一定时间内收不到客户端发送过来的反馈包，那就只有认定说掉线了。其实，要判定掉线，只需要send或者recv 下，如果结果为零，则为掉线。但是， 在长连接下，有可能很长一段时间都没有数据往来。理论上说，这个连接是一直保持连接的， 但是实际情况中，如果中间节点出现什么故障是难以知道的。更要命的是，有的节点（防火 墙）会自动把一定时间之内没有数据交互的连接给断掉。在这个时候，就需要我们的心跳包 了，用于维持长连接，保活。在获知了断线之后，服务器逻辑可能需要做一些事情，比如断线后的数据清理呀， 重新连接呀当然，这个自然是要由逻辑层根据需求
3、去做了。总的来说，心跳包主要也就是用于长连接的保活和断线处理。一般的应用下，判定时间在30-40 秒比较不错。如果实在要求高，那就在6-9 秒。心跳检测步骤：1 客户端每隔一个时间间隔发生一个探测包给服务器2 客户端发包时启动一个超时定时器3 服务器端接收到检测包，应该回应一个包4 如果客户机收到服务器的应答包，则说明服务器正常，删除超时定时器5 如果客户端的超时定时器超时，依然没有收到应答包，则说明服务器挂了服务端为什么需要心跳（保活）机制如果没有特意的设置某些选项或者实现应用层心跳包，TCP空闲的时候是不会 发送任何数据包。也就是说，当一个TCP的socket，客户端与服务端谁也不发 送数
4、据，会一直保持着连接。这其中如果有一方异常掉线（例如死机、路由被破 坏、防火墙切断连接等），另一端如果没有发送数据，永远也不可能知道。这对 于一些服务型的程序来说，是灾难性的后果，将会导致服务端socket资源耗尽。所以为了保证连接的有效性、及时有效地检测到一方的非正常断开，保证连 接的资源被有效的利用，我们就会需要一种保活的机制，通常改机制两种处理方 式：1、利用TCP协议层实现的Keepalive； 2、自己在应用层实现心跳包。两种方式的对比如下：1 、TCP 协议自带的保活功能, 使用起来简单, 减少了应用层代码的复杂度 . 更 节省流量, 因为一般来说应用层的数据传输到协议层时都会被加
5、上额外的包头 包尾. 由 TCP 协议提供的检活, 其发的 ACK 包比应用层的心跳包耗费更少的流 量。2 、应用层心跳包相对与 Keepalive 更灵活，因为协议层的心跳只能提供最纯 粹的检活功能, 但是应用层自己可以随意控制，甚至加入一些额外逻辑。3 、应用层心跳包相对与 Keepalive 更灵活，应用层心跳包不依赖于协议，如 若有一天不用TCP要改为UDP 了，只需做少量改动甚至不用改动即可实现转换。网 络上有说:存活（keepalive）并不是TCP规范的一部分。在Host RequirementsRFC 罗列有不使用它的三个理由：（1）在短暂的故障期间，它们可能引起一个 良好连接（good connection）被释放（dropped），（2）它们消费了不必要的宽 带，（3）在以数据包计费的互联网上它们（额外）花费金钱。实际上，自己实现心跳包也会面临同样的问题，而第一点，在我测试过程中 只要设置参数合理短时间内并不会引起连接主动断开。
