【tcp】心跳检测，保活机制

为什么要心跳检查

因为目前讨论的数据连接场景，都是无源连接，排除NAT的情况，连接就是存在于src和dest两端OS中的状态机，为什么会要用无源连接呢，有源是连接建立带宽就分配好了，不传有效数据这个带宽也被占用着，这不就浪费了，虚拟信号时代的电话就是有源的。

心跳检查是两端都要做的，不做的那一端一样存在状态不对而不自知的情况。

状态机在两端是有可能不一致的，比如一端认为这条连接已经销毁，另外一端可能认为仍有效。心跳机制的作用之一就是解决这种不一致的情况，类似“校对”的作用。
在浏览器上请求一个需要长时间才得到结果的请求，最后返回超时错误。

你说的情况我们经常遇到，我估计你说的就是客户端自己的超时设置，也就是如果http响应无法在限定时间内完成（比如1秒内），那么客户端应用程序自己会报timeout错误。

这应该不是中间设备做了reset，因为如果是那样，这个中间设备应该会给客户端和服务端都发TCP RST，然后客户端报错会变成ECONNRESET这种（ECONNRESET是linux的网络协议栈报给用户空间程序的报错）。
心跳消息显示push ack是为何呢？

按照TCP协议（参考RFC793）规定， *** 作系统收到有PSH标志位的报文后，这些报文不会被驻留在接收缓冲区，而是要立即通知用户空间程序来接收。这样对于用户空间程序及时收发处理心跳报文是有利的。
AWS的nlb keep-alive最大是350s，我们的服务端keep-alive是默认配置，客户端使用了连接池，也进行了探测，但是有个骚 *** 作是随机选取池子里面的一个链接进行探测，然后那些超过350s还没探测的链接，再次使用就出问题了。

你说的“随机选取池子里面的一个链接进行探测”，我判断是健康检查，就是业务健康性（类似k8s的readiness probe），而不是keepalive。

如果是这样的话，这个健康检查确实不是为保活而生的，也很难达到保活的目的。建议这样做设置：client idle timeout < LB idle timeout < server idle timeout，这样可以尽可能的保证不出现连接失效的情况。

这里说的“保活时间”，不是心跳包的间隔，而是空闲保活时间，idle timeout。
保活机制：心跳包异常导致应用重启？

https://timegeekbangorg/column/article/482610
如何解决 Keep-Alive 导致 ECONNRESET 的问题

https://zhuanlanzhihucom/p/86953757
解决使用 KeepAlive Agent 遇到的 ECONNRESET

https://zhuanlanzhihucom/p/34147188

以上就是关于【tcp】心跳检测，保活机制全部的内容，包括:【tcp】心跳检测，保活机制、、等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！