深入原理学习之–TCP长连接与心跳保活

终于点题了，文题中提到的心跳便是一个本文想要重点强调的另一个 TCP 相关的知识点。上一节我们已经解释过了，网络层面的 KeepAlive 不足以支撑应用级别的连接可用性，本节就来聊聊应用层的心跳机制是实现连接保活的。

如何理解应用层的心跳?简单来说，就是客户端会开启一个定时任务，定时对已经建立连接的对端应用发送请求(这里的请求是特殊的心跳请求)，服务端则需要特殊处理该请求，返回响应。如果心跳持续多次没有收到响应，客户端会认为连接不可用，主动断开连接。不同的服务治理框架对心跳，建连，断连，拉黑的机制有不同的策略，但大多数的服务治理框架都会在应用层做心跳，Dubbo 也不例外。

应用层心跳的设计细节

以 Dubbo 为例，支持应用层的心跳，客户端和服务端都会开启一个HeartBeatTask，客户端在HeaderExchangeClient中开启，服务端将在HeaderExchangeServer开启。文章开头埋了一个坑：Dubbo 为什么在服务端同时维护Map呢?主要就是为了给心跳做贡献，心跳定时任务在发现连接不可用时，会根据当前是客户端还是服务端走不同的分支，客户端发现不可用，是重连;服务端发现不可用，是直接 close。

// HeartBeatTask 
 
if (channel instanceof Client) { 
 
((Client) channel).reconnect(); 
 
} else { 
 
channel.close(); 
 
} 

熟悉其他 RPC 框架的同学会发现，不同框架的心跳机制真的是差距非常大。心跳设计还跟连接创建，重连机制，黑名单连接相关，还需要具体框架具体分析。

除了定时任务的设计，还需要在协议层面支持心跳。最简单的例子可以参考 nginx 的健康检查，而针对 Dubbo 协议，自然也需要做心跳的支持，如果将心跳请求识别为正常流量，会造成服务端的压力问题，干扰限流等诸多问题。

dubbo protocol

其中 Flag 代表了 Dubbo 协议的标志位，一共 8 个地址位。低四位用来表示消息体数据用的序列化工具的类型(默认 hessian)，高四位中，第一位为1表示是 request 请求，第二位为 1 表示双向传输(即有返回response)，第三位为 1 表示是心跳事件。

心跳请求应当和普通请求区别对待。

（编辑：西安站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!