TCP Keepalive && Heartbeat

在默认情况下，在建立TCP连接之后，空闲时刻客户端和服务端不会互相发送数据包确认连接。假如有一端发生异常而掉线（如死机、防火墙拦截包、服务器爆炸），另一端若不进行连接确认，则会一直消耗资源。

为了保证连接的有效性，可以检测到对方端非正常的断开，我们通常利用两种机制来实现：

• 利用TCP协议的Keepalive
• 在应用层实现心跳检测(Heart Beat)

TCP Keepalive

TCP Keepalive通过定时发送Keepalive探测包来探测连接的对端是否存活。

交互过程：

在收到对端的确认报文后，设置keepalive timer。当长时间两端无交互并且保活定时器超时的时候，本段会发送keepalive probe等待对端确认。若对端在一定时间内确认（具体的规则貌似比较繁琐），keepalive timer重置；否则，长时间未响应，连接终止。

TCP Keepalive默认是关闭的，因为它会消耗额外的资源，并且可能会关闭正常的连接。（它也非TCP标准，详情可见The Host Requirements RFC [RFC1122]）

在Linux Kernal中可以调整以下几个数值来设置Keepalive的属性：

sysctl variables	net.ipv4.tcp_keepalive_time	net.ipv4.tcp_keepalive_intvl	net.ipv4.tcp_keepalive_probes
default	7200s	75s	9

Heart Beat

很多应用层协议都有心跳检测机制，客户端每隔一段时间就会向服务端发送一个数据包，通知服务端自己可以正常工作，同时传递一些数据。

两种方式的特点：

• TCP Keepalive是TCP协议自带的实现，使用简单，其发送的数据包与应用层心跳检测包相比更小，但其功能也简单，仅提供检测连接功能
• 应用层心跳包不依赖于传输层协议，无论传输层协议是TCP还是UDP都可以用
• 应用层心跳包可以定制，可以应对更复杂的情况或传输一些额外信息
• Keepalive仅代表连接保持着，而心跳包往往还代表客户端可正常工作

对于TCP长连接，需要“保活”机制。可以在上层协议中自己实现“心跳包”，也可以使用TCP底层自身的Keepalive机制。这两种方式采用哪种更好呢？这里贴一下一位网友的回帖，我觉得说的不错。

“套接字本身是有一套心跳保活机制的（TCP Keepalive），不过默认的设置并不像我们一厢情愿的那样有效。在双方TCP套接字建立连接后（即都进入ESTABLISHED状态）并且在两个小时左右上层没有任何数据传输的情况下，这套机制才会被激活。

很多人认为两个小时的时间设置得很不合理。为什么不设置成为10分钟，或者更短的时间？（可以通过SO_KEEPALIVE选项设置。）但是这样做其实并不被推荐。实际上这套机制只是操作系统底层使用的一个被动机制，原理上不应该被上层应用层使用。当系统关闭一个由KEEPALIVE机制检查出来的死连接时，是不会主动通知上层应用的，只有在调用相应的IO操作在返回值中检查出来。

因此，忘记SO_KEEPALIVE，在应用层自己写一套保活机制比较靠谱。”