socket心跳包机制实践与理解

实现Socket心跳包主要分为两大类，第一采用tcp自带的KeepAlive，第二是自定义心跳包，恰巧我在产品VICA中都使用过，下面就这两种心跳包机制谈谈个人的理解与感受。

首先第一种KeepAlive机制，这种机制的原理是在客户机与服务器之间维持一个低级别的探查，当检查到一定时间双方没有发生通信时，则会启动通信心跳，连续通信三次，每次间隔一个时间，根据这次探查结果来确认当前socket是否可用。 这种机制的好处就在于具体的通信内容不需要程序员操心发送与接受，它自动实现了这套功能。如果客户机想实时了解与服务器之间的连接状态，则KeepAlive需要在客户机上添加， 如果服务器需要了解与客户端的连接状态，则服务器需要添加，也就是 谁需要谁添加，可单向心跳，也可双向心跳，用起来非常方便与灵活。下面是KeepAlive的具体使用示例：

            uint dummy = 0;
            byte[] inOptionValues = new byte[Marshal.SizeOf(dummy) * 3];
            BitConverter.GetBytes((uint)1).CopyTo(inOptionValues, 0);
            BitConverter.GetBytes((uint)6000).CopyTo(inOptionValues, Marshal.SizeOf(dummy));
            BitConverter.GetBytes((uint)6000).CopyTo(inOptionValues, Marshal.SizeOf(dummy) * 2);

            clientSocket.IOControl(IOControlCode.KeepAliveValues, inOptionValues, null);

　　上面提到如果客户机与服务器都需要知道对方状态的话，那就意味着必须要做双向心跳，这对服务器额外增加了压力。同时由于Java版的socket服务采用了Netty框架，我们在这个框架下配合使用keepAlive一直没有起到作用。面对这样的情况，平台无关性的业务定制的心跳包才更有了意义。

其次对于自定义心跳包，我采用的方案是由客户机主动发起心跳，服务器接收到客户机的心跳包后做一个明确的回复，客户机收到服务器的心跳回复后则认可本次通信，所以这里其实产生了一个约定：客户机会不停的发心跳包给服务器，服务器会定时的接收这些心跳包。 基于这个约定客户机和服务器就可以确认短线方案：当客户机或服务器没有收到来自对方的心跳包或者心跳服务后，则断开连接。这种方案的好处是服务器不用再主动发心跳包，一定程度上降低了对服务器的压力，同时这种机制是基于应用层的，所以无关平台行，很好的解决了上面keepalive出现的问题。 但是这种机制带来的缺点也比较明显，那就是额外增加了一个约定，导致客户机与服务器存在一定的耦合性。所以如何应用这两种机制，还是需要根据自己的特定需求，切不可盲目实施。