游戏服务器心跳包的作用

游戏服务器心跳包的作用
服务端为什么需要心跳(保活)机制
TCP-Keepalive-HOWTO
闲说HeartBeat心跳包和TCP协议的KeepAlive机制
Socket心跳包机制

心跳包的作用

1 查一下tcp的断线是否真的可靠

一个tcp链接很长时间没有数据传送，路由器已经释放tcp链接， 客户端那边close了， 但服务器那边也不会有反应
为了避免这种现象，可能需要改协议
比如：客户端每隔一段时间发送心跳数据包，如果长时间没有心跳，服务器关闭socket

之前的测试都是，手动强制关闭客户端进程，然后查看服务器的情况，结果往往是，服务器收到了客户端关闭的事件。
其实，我一直忽略了一个问题，我没有拔掉网线来测试！

上面的手动关闭客户端进程，事实上并不能测试出想要的结果，因为进程是在应用层的 ，
所以，这种测试方法不能保证网络驱动层也不发送数据报文给服务器。
经过测试发现，当应用层强制结束进程时，对于TCP连接，驱动层会发送reset数据包！
而服务器收到这个数据包就可以正常关闭了！

那么，如果拔掉网线呢，服务器收不到这个数据包，就会导致死连接存在！

所以，心跳包是必要的，或者应用TCP协议本身的Keep-alive来设置

之所以产生前面的误解，也是由于以前看书的时候，凭空想象，以为TCP连接如同一条绳子，一方断开了，另外一方必然会知道的。
殊不知，TCP连接，这个“面向连接”的连接并不存在
它只是抽象出来的概念，对于物理层，对于网线、光纤而言，不存在连接不连接的概念，因为，对它们而言，无非就是一些电流脉冲而已。

TCP的连接，不过是通过ACK、SEQ这些机制来模拟实现的。

这么看来socket本身的断开通知不是很靠谱，心跳包会更合理一些
那么心跳包的一个意义就是可以更可靠的检测连接是否畅通

如果没有特意的设置某些选项或者实现应用层心跳包，TCP空闲的时候是不会发送任何数据包。
也就是说，当一个TCP的socket，客户端与服务端谁也不发送数据，会一直保持着连接。
这其中如果有一方异常掉线（例如死机、路由被破坏、防火墙切断连接等）
另一端如果没有发送数据，永远也不可能知道。这对于一些服务型的程序来说，是灾难性的后果，将会导致服务端socket资源耗尽。

所以为了保证连接的有效性、及时有效地检测到一方的非正常断开，保证连接的资源被有效的利用，
我们就会需要一种保活的机制，通常改机制两种处理方式：
1、利用TCP协议层实现的Keepalive；
2、自己在应用层实现心跳包。

两种方式的对比如下：
1、TCP协议自带的保活功能, 使用起来简单, 减少了应用层代码的复杂度. 更节省流量, 因为一般来说应用层的数据传输到协议层时都会被加上额外的包头包尾. 由TCP协议提供的检活, 其发的ACK包比应用层的心跳包耗费更少的流量。
2、应用层心跳包相对与Keepalive更灵活，因为协议层的心跳只能提供最纯粹的检活功能, 但是应用层自己可以随意控制，甚至加入一些额外逻辑。
3、应用层心跳包相对与Keepalive更灵活，应用层心跳包不依赖于协议，如若有一天不用TCP要改为UDP了，只需做少量改动甚至不用改动即可实现转换。

网络上有说：存活（keepalive）并不是TCP规范的一部分。在Host Requirements RFC罗列有不使用它的三个理由：
（1）在短暂的故障期间，它们可能引起一个良好连接（good connection）被释放（dropped）
（2）它们消费了不必要的宽带
（3）在以数据包计费的互联网上它们（额外）花费金钱。

实际上，自己实现心跳包也会面临同样的问题，而第一点，在我测试过程中，只要设置参数合理短时间内并不会引起连接主动断开。

2页游之前会 用心跳包检测加速作弊

比如如果某玩家应用加速器作弊，那么他发送的心跳包时间时间间隔就会异常，这样就可以揪出作弊
但是作弊器已经越来越高端了，检测心跳包已经几乎没用，所以这个作用几乎没有了

3 心跳包可以检测游戏延迟