HTTP2和GRPC支持keepalive特性(不要与http 1.1 keepalive头混淆(。
https://github.com/grpc/grpc/blob/master/doc/keepalive.md
该特征周期性地发送Ping请求并接收Ping响应以检查连接是否仍然打开并且没有卡在"断开"状态；半开"；。
但TCP协议也有一个Keepalive功能，它会定期在连接上发送ping数据包，以验证其是否仍然打开，并避免负载平衡器因连接空闲而放弃连接。
既然这2个Keepalive功能正在做完全相同的事情，那么什么时候应该使用HTTP2 Keepalive而不是TCP Keepalive。为什么两者都存在？
我将提到gRPC实现通常启用TCP保活，但只使用默认的操作系统配置。
gRFC:中的一些引文
TCP保活在Java和Go中很难配置。
启用保活很容易，但配置起来很麻烦。Java通常根本无法对其进行配置。Go允许您配置它，但API将时间和间隔设置为相同的值，因此设置5分钟的时间需要一个小时(5分钟乘以10或11次重试(才能将连接确定为无效。因此，Go API在变得有用之前需要非常积极的保持活动设置。
TCP保持活动，即使没有打开的流。
gRFC提到了移动，但由于连接数量庞大，数据中心流量也可能受到影响。如果连接处于非活动状态，通常最好释放资源，而不是花费更多资源来保持其活动状态。IDLE_TIMEOUT(在Java和C，IIRC中可用(可以实现这一点。
没有已知的通用方法可用于gRPC来检测TCP保活的滥用。
TCP保持有效对于网络监控和滥用控制非常难以检测。客户端可能会设置一个非常激进的值，而服务器不得不在不知不觉中支付部分成本。在大规模情况下，过于激进的保留可能会带来物质成本(网络流量的10%以上(，而且很难注意到、修复和防止再次发生。基于HTTP/2 PING的设计允许积极的保活，但前提是服务器接受相关成本。