前言

可能很多 Java 程序员对 TCP 的理解只有一个三次握手，四次握手的认识，我觉得这样的原因主要在于 TCP 协议本身稍微有点抽象（相比较于应用层的 HTTP 协议）；其次，非框架开发者不太需要接触到 TCP 的一些细节。其实我个人对 TCP 的很多细节也并没有完全理解。

长连接与短连接

TCP 本身并没有长短连接的区别 ，长短与否，完全取决于我们怎么用它。

• 短连接：每次通信时，创建 Socket；一次通信结束，调用 socket.close()。这就是一般意义上的短连接，短连接的好处是管理起来比较简单，存在的连接都是可用的连接，不需要额外的控制手段。

• 长连接：每次通信完毕后，不会关闭连接，这样可以做到连接的复用。 长连接的好处是省去了创建连接的耗时。

连接的保活：KeepAlive

首先想到的是 TCP 中的 KeepAlive 机制。KeepAlive 并不是 TCP 协议的一部分，但是大多数操作系统都实现了这个机制（所以需要在操作系统层面设置 KeepAlive 的相关参数）。KeepAlive 机制开启后，在一定时间内（一般时间为 7200s，参数 tcp_keepalive_time）在链路上没有数据传送的情况下，TCP 层将发送相应的 KeepAlive 探针以确定连接可用性，探测失败后重试 10（参数 tcp_keepalive_probes）次，每次间隔时间 75s（参数 tcp_keepalive_intvl），所有探测失败后，才认为当前连接已经不可用。

回忆七层网络模型

我们已经为应用层面的连接保活做了足够的铺垫，下面就来一起看看，怎么在应用层做连接保活。

连接的保活：应用层心跳

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

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

应用层心跳的设计细节

以 Eureka 为例，支持应用层的心跳，客户端会开启Heartbeat timer，主要就是为了给心跳做贡献，eureka这里叫做续约。

// Heartbeat timer
  scheduler.schedule(
          new TimedSupervisorTask(
                  "heartbeat",
                  scheduler,
                  heartbeatExecutor,
                  renewalIntervalInSecs,
                  TimeUnit.SECONDS,
                  expBackOffBound,
                  new HeartbeatThread()
          ),
          renewalIntervalInSecs, TimeUnit.SECONDS);

关于client有两项配置

# 该配置指示eureka客户端需要向eureka服务器发送心跳的频率  (Spring Cloud默认该配置是 30s)
eureka.instance.lease-renewal-interval-in-seconds: 10

# 该配置指示eureka服务器在接收到最后一个心跳之后等待的时间，然后才能从列表中删除此实例 (Spring Cloud默认该配置是 90s)
eureka.instance.lease-expiration-duration-in-seconds: 30 

还有一个问题client注册的时候，是不是开启了http层的keepalive呢，答案是没有的。只是eureka在应用层上的心跳机制，保持连接,下图就是jersey远程注册的时候看到的断点信息，可见header中没有加上，keepalive。

注意和 HTTP 的 KeepAlive 区别对待

• TCP层的KeepAlive为TCP层握手结束之后保持连接，其timeout为TCP层握手结束之后能保持多长时间，如果在这个时间范围内客户端没有数据传输，则关闭连接。

• HTTP层的Keep-Alive为HTTP层请求结束之后保持连接，其timeout为HTTP层请求结束之后能保持多少时间，如果在这个时间范围内客户端没有数据传输，则关闭连接。

这个eureka到底有没有保持tcp的keepalive呢？还有有待考究。

参考连接：

TCP keepalive 和 http keep-alive： https://segmentfault.com/a/1190000012894416

Spring Cloud之Eureka客户端健康检测(五)：https://blog.csdn.net/MrSpirit/article/details/80164315

Eureka的健康检测机制：http://hyuga.top/2019/07/24/spring-cloud-eureka-health/

Eureka的工作原理以及它与ZooKeeper的区别：https://www.cnblogs.com/snowjeblog/p/8821325.html

深入理解Eureka之源码解析：https://blog.csdn.net/forezp/article/details/73017664

最后

以上就是玩命画板为你收集整理的【Spring Cloud】结合Eureka健康检测机制聊聊TCP长连接和心跳那些事前言长连接与短连接连接的保活：KeepAlive回忆七层网络模型连接的保活：应用层心跳应用层心跳的设计细节注意和 HTTP 的 KeepAlive 区别对待的全部内容，希望文章能够帮你解决【Spring Cloud】结合Eureka健康检测机制聊聊TCP长连接和心跳那些事前言长连接与短连接连接的保活：KeepAlive回忆七层网络模型连接的保活：应用层心跳应用层心跳的设计细节注意和 HTTP 的 KeepAlive 区别对待所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错，欢迎将靠谱客网站推荐给程序员好友。