TCP Keepalive、HTTP持久连接、WebSocket Ping/Pong、HTTP/2 PING和QUIC PING有什么区别？
这些机制都与“连接保持”有关，却工作在不同层级。TCP Keepalive 是主机 TCP 实现对空闲 TCP 连接进行探测的可选机制；HTTP/1.1 持久连接表示多个请求可以复用同一条连接，本身不是周期心跳；WebSocket Ping/Pong 是 WebSocket 控制帧，可检查应用通道是否仍能双向工作；HTTP/2 PING 是连接级帧，用不透明数据测量最小往返并确认连接可用；QUIC PING 是可触发确认的 QUIC 帧，常用于验证对端仍可到达或让路径产生确认，但没有携带 WebSocket、HTTP/2 PING 那种回显载荷。
本文目录（18 节）
直接答案
这些机制都与“连接保持”有关，却工作在不同层级。TCP Keepalive 是主机 TCP 实现对空闲 TCP 连接进行探测的可选机制；HTTP/1.1 持久连接表示多个请求可以复用同一条连接，本身不是周期心跳；WebSocket Ping/Pong 是 WebSocket 控制帧，可检查应用通道是否仍能双向工作；HTTP/2 PING 是连接级帧，用不透明数据测量最小往返并确认连接可用；QUIC PING 是可触发确认的 QUIC 帧，常用于验证对端仍可到达或让路径产生确认，但没有携带 WebSocket、HTTP/2 PING 那种回显载荷。
它们不能互相简单替代。开启 TCP Keepalive 不代表反向代理不会因 HTTP 空闲超时关闭连接；HTTP/2 或 QUIC 的协议级 PING 得到响应，也不保证上层业务线程、订阅状态或后端依赖健康。
五类机制对比
| 机制 | 层级 | 谁处理 | 对端响应 | 主要用途 |
|---|---|---|---|---|
| TCP Keepalive | TCP | 操作系统 TCP 栈 | TCP 确认行为 | 探测长期空闲 TCP 对端或路径是否消失 |
| HTTP/1.1 持久连接 | HTTP连接管理 | 客户端、服务端、代理 | 无专用心跳 | 复用连接承载多个请求 |
| WebSocket Ping/Pong | WebSocket | WebSocket 端点 | Pong 回显载荷 | 检查通道活性、维持应用会话 |
| HTTP/2 PING | HTTP/2 | HTTP/2 连接端点 | ACK 回显8字节数据 | 测量往返、确认连接级可用性 |
| QUIC PING | QUIC | QUIC 端点 | 通过 ACK 确认 | 引发确认、验证可达性或维持路径状态 |
“收到响应”只证明对应层级完成了响应。监控结论不能自动上升到更高层。
TCP Keepalive是什么？
RFC 1122 把 TCP keep-alive 定义为可选功能，并要求应用能够为每条连接启用或禁用。其目的之一是判断长期无数据的连接另一端是否已经消失，例如设备断电、网络路径变化，而本地迟迟收不到 FIN 或 RST。
探测通常由内核在连接空闲达到阈值后发送，并在多次无响应后报告错误。具体的空闲时间、探测间隔和次数属于操作系统与套接字配置；不同平台默认值可能很长。仅仅把 SO_KEEPALIVE 打开，并不等于能在几十秒内发现故障。
TCP Keepalive 只适用于 TCP。基于 QUIC 的 HTTP/3 使用 UDP 承载并在 QUIC 层管理连接，不能依赖 TCP keepalive。
TCP Keepalive能证明应用正常吗？
不能。TCP 探测可能由对端内核回答，即使对端应用线程已经死锁、事件循环阻塞或后端服务不可用。它主要回答“这条 TCP 路径和对端 TCP 状态是否仍存在”，不回答“业务请求能否按时完成”。
反过来，TCP Keepalive 失败也要结合路径解释。NAT、防火墙、移动网络切换或中间设备可能丢弃空闲连接状态，对端应用本身未必宕机。
HTTP持久连接是什么？
HTTP 持久连接的核心是复用底层连接处理多个请求，减少重复建立 TCP 和 TLS 连接的成本。在 HTTP/1.1 中，连接默认具有持久性，除非请求或响应使用 Connection: close，或者因协议版本、错误或超时关闭。
“Keep-Alive”常被产品界面当成一个统称，但它与 TCP Keepalive 不是一回事。HTTP 持久连接规定请求完成后连接可以继续用于后续请求；它不要求端点每隔一段时间发送探测包。
代理链中的每一跳都有独立连接。浏览器到反向代理的连接保持，并不等于反向代理到源站的连接也保持相同时间。Connection 等逐跳字段也不能被当作端到端业务配置任意转发。
HTTP空闲超时为什么仍会断开连接？
服务端、负载均衡器、反向代理、NAT 或客户端都可能有自己的空闲超时。最短的那个边界通常决定实际寿命。即使 TCP Keepalive 在内核层启用，如果探测间隔长于中间设备的空闲回收时间，仍无法阻止映射被删除。
此外，有的中间设备只把应用数据视为活跃流量，不保证将底层探测等同于业务活动。设计长连接时必须查明各跳的超时定义，而不是只修改客户端一个参数。
WebSocket Ping和Pong是什么？
RFC 6455 定义了 Ping 与 Pong 控制帧。收到 Ping 的端点应尽快发送 Pong，除非已经收到 Close；响应 Pong 必须包含与 Ping 相同的应用数据。端点也可以主动发送未经请求的 Pong，作为单向心跳。
Ping/Pong 在 WebSocket 协议层工作，能够穿过已建立的 WebSocket 通道并由远端 WebSocket 实现处理。控制帧可以插入分片消息之间，避免大消息传输时心跳被无限延后；控制帧自身不得分片，载荷长度也受控制帧上限约束。
浏览器 JavaScript 通常不能直接构造协议级 Ping 控制帧，浏览器会在协议实现内部处理它们。若应用需要可见的心跳与业务超时，常在消息层另设 ping/pong 消息，但那是应用协议，不应与 WebSocket 控制帧混写。
WebSocket Ping能维持所有中间设备状态吗？
它通常能让链路产生实际流量，因此可能阻止按“完全无流量”判断的中间设备回收连接，但不能保证所有设备都采用相同策略。代理还可能设置最大连接时长、WebSocket 专用超时或速率限制，与是否有 Ping 无关。
心跳间隔应小于已知的最短空闲超时，并保留网络抖动余量，但不能设置得过密。大量客户端同步发送心跳会造成周期性流量尖峰，实践中可加入随机抖动并对失败重连使用退避。
HTTP/2 PING是什么？
HTTP/2 PING 是连接级帧，包含 8 字节不透明数据。接收方收到未设置 ACK 标志的 PING 后，必须尽快发送带 ACK 的 PING，并回显相同数据。发送端可据此测量往返时间并确认对端连接仍然可用。
PING 的流标识必须为 0，所以它不属于某个请求流。某个 HTTP/2 PING 成功，不代表指定 stream 没有被重置，也不代表具体请求处理成功。
RFC 9113 还允许端点把 PING 作为管理空闲连接的工具，但过量 PING 可能被视为滥用。服务端可以实施频率限制或用连接错误终止异常对端。
HTTP/2 PING与WebSocket Ping有什么区别？
HTTP/2 PING 检查整个 HTTP/2 连接，多个并发流共享这一结果；WebSocket Ping 属于一个 WebSocket 连接的控制帧。即使 WebSocket 运行在某种 HTTP 多路复用环境中，两者仍处在不同协议语义层。
HTTP/2 PING 固定回显 8 字节数据；WebSocket Ping 的 Pong 回显其控制帧应用数据。二者都不是业务请求，也不能替代针对业务操作的端到端健康检查。
QUIC PING是什么？
RFC 9000 的 PING 帧没有字段。它是 ack-eliciting 帧，也就是说接收方需要通过 QUIC 的确认机制确认包含它的数据包。端点可在没有其他可发送内容时用它验证对端仍可到达，或让一个数据包变得需要确认。
QUIC PING 不像 HTTP/2 PING 那样携带 8 字节不透明数据，也不是请求对端发回另一个“PONG”帧；确认来自 ACK。要计算测量值，应使用发送数据包与对应确认的时序，并遵循 QUIC 的丢包恢复和 RTT 计算规则。
QUIC PING能阻止连接空闲超时吗？
可确认的活动能够影响 QUIC 空闲计时，但双方协商的最大空闲超时仍决定连接何时因无活动关闭。实现还可能有应用层或资源管理限制。持续发 PING 不能把连接变成永久连接。
QUIC 还支持路径迁移与连接 ID，移动网络切换不一定像 TCP 四元组变化那样必然终止连接；不过新路径仍需验证，NAT 和防火墙状态也可能改变。PING 成功只表示当次路径上的 QUIC 包获得了确认。
为什么心跳成功但业务请求仍超时？
可能原因包括：
- 心跳由内核或协议栈处理，业务线程已经阻塞。
- 心跳是连接级的，某个流已被重置或流量控制受限。
- 反向代理可以回答心跳，但代理到后端的另一条连接失败。
- 心跳载荷很小，大业务消息遇到 MTU、拥塞或带宽问题。
- 身份、会话或订阅已过期，传输连接却仍然存在。
- 上游依赖超时，端点本身仍能及时响应协议控制帧。
因此需要分别记录传输活性、协议活性、业务往返和依赖健康，不能只保留一个“在线”布尔值。
如何设计分层保活与健康检查？
第一层使用操作系统或 QUIC 的连接机制发现静默消失；第二层使用协议级 Ping 检查端点往返；第三层使用轻量业务消息验证会话和处理循环；第四层再用真实但无副作用的业务探针验证后端依赖。每层都应有独立超时与错误分类。
间隔要根据最短空闲回收边界、可接受发现时间、客户端规模和电量成本计算。移动设备尤其不应为了“看起来实时”持续高频唤醒无线网络。失败判定应允许少量丢包，并在重连时使用指数退避和抖动，避免全量客户端同时重连。
排障时该抓哪些证据？
至少记录：使用 TCP、HTTP/2 还是 QUIC；每层心跳类型和间隔；客户端、代理、负载均衡器、源站的空闲超时；最后一次成功业务消息时间；关闭方与关闭信号；WebSocket Close code、HTTP/2 GOAWAY/RST_STREAM、QUIC CONNECTION_
抓包时还要区分 TCP keepalive 探测、普通 ACK、WebSocket 控制帧、HTTP/2 PING 和 QUIC 加密数据包。仅看到周期性小包，不能凭大小猜测它属于哪一种机制。
常见误区
开启TCP Keepalive后WebSocket就不会断吗？
不会。代理的应用层空闲超时、最大连接时长、会话过期或网络切换仍可关闭连接。需要同时核对整条链路的策略。
HTTP Keep-Alive是周期心跳吗？
不是。HTTP 持久连接表示连接可复用于后续请求，本身不定义固定周期的探测消息。
WebSocket Pong成功能证明业务服务健康吗？
不能。Pong 可能由协议实现快速处理，而业务事件循环或下游依赖仍不可用。
HTTP/2 PING能检查某个请求流吗？
不能。PING 是连接级帧，流标识为 0。具体流还需检查其状态、超时和错误码。
QUIC有PONG帧吗？
RFC 9000 没有与 PING 成对的 PONG 帧。PING 通过包含它的数据包被 ACK 来确认。
结论
TCP Keepalive 探测 TCP 路径，HTTP 持久连接复用请求，WebSocket Ping/Pong 检查 WebSocket 通道，HTTP/2 PING 检查复用连接，QUIC PING 通过 ACK 验证 QUIC 可达性。正确做法不是把所有机制都叫“keepalive”，而是标明协议层、响应者、超时边界和能证明的范围，再用业务级探针补齐传输活性无法证明的部分。
参考来源
- RFC 1122, Requirements for Internet Hosts—Communication Layers：https:
/ / www. rfc- editor. org/ rfc/ rfc1122. txt - RFC 9112, HTTP/1.1：https:
/ / www. rfc- editor. org/ rfc/ rfc9112. txt - RFC 6455, The WebSocket Protocol：https:
/ / www. rfc- editor. org/ rfc/ rfc6455. txt - RFC 9113, HTTP/2：https:
/ / www. rfc- editor. org/ rfc/ rfc9113. txt - RFC 9000, QUIC: A UDP-Based Multiplexed and Secure Transport：https:
/ / www. rfc- editor. org/ rfc/ rfc9000. txt