设为首页 - 加入收藏 益阳站长网 (http://www.0737zz.com)- 国内知名站长资讯网站,提供最新最全的站长资讯,创业经验,网站建设等!
热搜: 平台 模式 为什么 什么
当前位置: 首页 > 运营中心 > 网站设计 > 教程 > 正文

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

发布时间:2019-09-25 06:15 所属栏目:[教程] 来源:互联网架构师精髓
导读:终于点题了,文题中提到的心跳便是一个本文想要重点强调的另一个 TCP 相关的知识点。上一节我们已经解释过了,网络层面的 KeepAlive 不足以支撑应用级别的连接可用性,本节就来聊聊应用层的心跳机制是实现连接保活

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

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

应用层心跳的设计细节

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

  1. //?HeartBeatTask?
  2. ?
  3. if?(channel?instanceof?Client)?{?
  4. ?
  5. ((Client)?channel).reconnect();?
  6. ?
  7. }?else?{?
  8. ?
  9. channel.close();?
  10. ?
  11. }?

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

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

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

dubbo protocol

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

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

注意和 HTTP 的 KeepAlive 区别对待

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

这压根是两个概念。

KeepAlive 常见错误

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

  1. ETIMEOUT 超时错误,在发送一个探测保护包经过 (tcp_keepalive_time + tcp_keepalive_intvl * tcp_keepalive_probes)时间后仍然没有接收到 ACK 确认情况下触发的异常,套接字被关闭
  2. java.io.IOException: Connection timed out
  3. EHOSTUNREACH host unreachable(主机不可达)错误,这个应该是 ICMP 汇报给上层应用的。
  4. java.io.IOException: No route to host
  5. 链接被重置,终端可能崩溃死机重启之后,接收到来自服务器的报文,然物是人非,前朝往事,只能报以无奈重置宣告之。
  6. java.io.IOException: Connection reset by peer

总结

有三种使用 KeepAlive 的实践方案:

默认情况下使用 KeepAlive 周期为 2 个小时,如不选择更改,属于误用范畴,造成资源浪费:内核会为每一个连接都打开一个保活计时器,N 个连接会打开 N 个保活计时器。 优势很明显:

  • TCP 协议层面保活探测机制,系统内核完全替上层应用自动给做好了
  • 内核层面计时器相比上层应用,更为高效
  • 上层应用只需要处理数据收发、连接异常通知即可
  • 数据包将更为紧凑
  1. 关闭 TCP 的 KeepAlive,完全使用应用层心跳保活机制。由应用掌管心跳,更灵活可控,比如可以在应用级别设置心跳周期,适配私有协议。
  2. 业务心跳 + TCP KeepAlive 一起使用,互相作为补充,但 TCP 保活探测周期和应用的心跳周期要协调,以互补方可,不能够差距过大,否则将达不到设想的效果。

各个框架的设计都有所不同,例如 Dubbo 使用的是方案三,但阿里内部的 HSF 框架则没有设置 TCP 的 KeepAlive,仅仅由应用心跳保活。和心跳策略一样,这和框架整体的设计相关。

【免责声明】本站内容转载自互联网,其相关言论仅代表作者个人观点绝非权威,不代表本站立场。如您发现内容存在版权问题,请提交相关链接至邮箱:bqsm@foxmail.com,我们将及时予以处理。

网友评论
推荐文章