2019-09-13tcp keepalive解决网络可用性，应用层keepalive解决网络和服务可用性，应用层无法区别网络还是服务问题，加上tcp心跳包可以进一步区分，有助于客户端做动态调整 14
2019-09-14解答问题：如果从实现功能角度看，传输层和应用层的心跳机制没有结合的必要，因为传输层的心跳探测连接可用性，应用层的心跳机制也可以完成探测; 但从debug角度看，应用层的心跳探测机制无法定位是网络的问题还是系统的问题，此时由传输层辅助就非常好，但实现会相对复杂！作者回复: 是的👍
10
2019-09-13智能心跳，采用什么算法逼近或者选择心跳周期？如何感知当前的心跳周期是否太小？因为一旦太大就会导致连接断开作者回复: 比较常见的有二分法。
4
2019-10-24能简单说下 二分法来进行心跳探测 的逻辑么？作者回复: 其实就是下一次动态调整的心跳间隔是：当前已经确认的安全的心跳间隔最大值 和 已经确认的心跳探测过大的最小值 的中间均值。比如上一次心跳间隔是4分钟，而且连续N次都成功ack了，那么当前已经确认的安全的心跳间隔是4分钟，假设已经确认10分钟时心跳间隔过大了，那么下一次调整的心跳就是 4 + 10 / 2 = 7分钟。
1 2
2019-10-17看流程图，服务器检查心跳并不是定时的， 而只是推送的时候检测？作者回复: 具体是哪个图呀，理解不太对，心跳和推送是独立的，并不会在推送的时候进行检测，一般会由独立的定时器来根据一定时间内socket中是否有数据收发来定时触发的。
2
2019-09-20看了老师的讲解，在理论上是明白了，但是具体实践上该如何操作？比如：tcp的keepalive该如何通过具体的代码语言去实现。这些具体操作性的知识，不知道本课程后面是否有涉及到？作者回复: tcp的keepalive开启比较简单，比如netty下可以通过如下代码开启：
ServerBootstrap bootstrap = new ServerBootstrap();
bootstrap.childOption(ChannelOption.SO_KEEPALIVE, true);
另外tcp keepalive的心跳间隔的配置也需要修改一下系统的/etc/sysctl.conf，类似下面：
net.ipv4.tcp_keepalive_time=120
net.ipv4.tcp_keepalive_intvl=30
net.ipv4.tcp_keepalive_probes=3 2
2019-09-13服务端在进行推送时候，假设判断用户连接有效，即用户在线，此时推送是同时推与客户端应用保持的长连接和apns等多条通道吗？然后在客户端去重？还是每次只会选择一条通道？作者回复: 会双推，走APNs不会直接落地app的db，苹果会根据应用在前台还是在后台来决定要不要展示APNs走通知栏的消息。现在也有很多应用支持应用在前台时也展示通知栏的消息，看具体需求。
2
2019-10-24如果用了长连接，怎么支持显示用户在线状态的功能了，保活机制会让用户一直在线吧？作者回复: 在线状态可以在用户完成上线操作后记录到uid维度的存储里供使用。保活机制不一定能保证用户一直在线，只是能降低运营商NAT超时导致连接被强制中断的概率，同时通过心跳保活还能及时发现连接是否可用，从而快速进行重连，来提升连接的可用性。
1
2019-09-16老师好，我用go的tcpsocket，有一端异常退出时，另一端会触发掉线通知。所以我不明白的是，socket是不是不需要心跳？还是是因为我是在局域网测试，和公网情况不一样？作者回复: 因为tcp本身是一个虚拟连接，中间链路断开的话另一端是感知不到的，另外，移动运营商的NAT会对一段时间没有数据传输的连接切断，所以对于维护高可用的一条长连接心跳是必不可少的。
3 1- 2019-09-16请问老师，我这里使用应用层发心跳包，很奇怪在内网测试环境，网页一直不操作都不会断线，但在外网同套代码，不操作1，2个小时后，网页的长链接就会断线，WS脚本重连也连不上，但只要重新刷新页面就可以连上了，这是什么原因？
作者回复: 心跳间隔是多少？外网的中间路由环节和运营商网络都可能在 一个连接一段时间没有数据传输的时候 从NAT表删除这个连接的映射。所以心跳间隔最好不要大于5分钟。
1 - 2019-09-15智能心跳的算法是咋样的
作者回复: 一般可以采用二分法来进行心跳探测。
1 
2019-09-14老师 客户端或服务端心跳实现是在客户端维持一个轮训服务吗？这样会不会有浪费客户端资源的问题，有没有什么好方法解决轮训定时器这种资源浪费问题作者回复: 一种方式是客户端采用固定timer来定时发送心跳包，也可以在客户端没有消息收发后的一段时间才可以发送心跳包，这样能节约一些流量。
1- 2019-10-31老师您好，您这节只讲了tcp的心跳机制，我觉得可以采用类似QUIC协议，自定义connection id判断逻辑连接状态，无需通过通信五元组来判断是否为同一连接，这样可以避免各种NAT设备，或nginx代理等出现的映射失效问题，在复杂网络环境中不用在频繁断线重连节省开销
作者回复: 是个好想法，不过QUIC之所以能够实现抽象的connection id应该也是得益于底层依赖的UDP是无状态传输协议，基于TCP之上要解决连接迁移的问题估计会很难。要是你有一些思路咱们可以继续探讨一下。
2019-09-16我觉得可以：毕竟不是完全基于同一层；TCP Keepalive是基于传输层，应用层心跳是基于应用层的，关键在于如何合理组合使用，中间如何去处理。
昨天某个完课的课程老师告诉我一定要注意知识的关联性：这门课程看了一遍其实是反向再来看的-觉得自己当时没注意一些知识，根据七层网络协议各层分别相互交付而言我认为是可以的；其实关键问题就在于TCP Keepalive的部分事情如何和应用层心跳合理结合-这才是问题处理的难点。
这个就像早期我们做软件直接CS或BS架构：现在数据系统层往往会多一个No sql DB，用的合理是能解决很多问题-关键难点就在如何合理使用；这是我的个人理解。任何架构做不好完美，不过使用合理可以增强效果/正确率。作者回复: 结合使用是没问题的，tcp keepalive和应用层心跳配合使用，当出现消息收发问题的时候，能够协助我们发现是网络层问题还是应用层问题。
2019-09-14我看上图 心跳处理流程，只有客户端当判断连接无效的时候才会进行 连接重连，重连的这个动作服务端不会进行吗？ 如果这样的话服务端还要发送心跳消息进行心跳检测做什么呢？服务端是不是可以这样处理，当一段时间没有收到客户端的心跳包的时候就判断与该客户端的心跳连接断开了，直接释放对应的资源不就可以了吗？作者回复: 服务端不知道客户端的固定连接地址呀，所以重连一般都是由客户端发起。服务端一般不需要发送心跳，是由客户端来发送心跳，服务端一段时间没有收到客户端的心跳包的时候就可以判断连接异常，主动断开等客户端重连上线就可以了。
2019-09-13文章中指出的心跳监测的时间间隔是发送作者回复: 是指客户端发送心跳包的间隔。
2019-09-13问题：心跳机制是不是可以结合tcp的keepalive和应用层的心跳协议？当然可以，不过只使用应用层的心跳协议就可以了，因为一旦应用层的心跳出现问题意味着连接出问题或服务处理不过来，不论什么问题，它更能反应应用真实的整体情况，比如负载均衡与后端服务器之间的应用心跳就能更客观的反应应用情况而便于进一步处理，比如摘除这个后端服务器并报警，而如果只是使用tcp的keepalive的反应的问题就比较片面，只是针对于网络的，而不能反应应用整体的情况，而如果应用整体出问题，连接没有问题也没有什么意义。不过从实现角度来说，tcp的keepalive和使用tcp的应用心跳一起使用并不会增加应用处理网络事件的复杂度，因为基于tcp，我们都是通过read和write来获取连接状态的，所以一起开启也无所谓。- 2019-09-13老师，有没有应用层心跳包的设计规范及要求的文章推荐的
作者回复: 心跳包的设计貌似没有固定的设计规范，目的就是尽量精简，比如只包括通用Header的空包，或者body内容是当前心跳间隔（智能心跳可能需要用到）。