聊聊 TCP 长连接和心跳那些事

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

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

8 应用层心跳的设计细节

以 Dubbo 为例，支持应用层的心跳，客户端和服务端都会开启一个 HeartBeatTask，客户端在 HeaderExchangeClient 中开启，服务端将在 HeaderExchangeServer 开启。文章开头埋了一个坑：Dubbo 为什么在服务端同时维护 Map

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

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

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

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

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

9 注意和 HTTP 的 KeepAlive 区别对待

• HTTP 协议的 KeepAlive 意图在于连接复用，同一个连接上串行方式传递请求-响应数据
• TCP 的 KeepAlive 机制意图在于保活、心跳，检测连接错误。

这压根是两个概念。

10 KeepAlive 常见异常

启用 TCP KeepAlive 的应用程序，一般可以捕获到下面几种类型错误

（编辑：网站开发网_安阳站长网）

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