HTTP Keep-Alive 和 TCP Keepalive 有什么区别？长连接能保证对方一直在线吗？

知识点详解：连接还在，与请求能完成，不是一回事

HTTP 为什么想复用连接？

假设客户端连续请求同一个服务。每次都新建连接，会重复付出建连等成本。持久连接允许在符合协议与实现条件时继续使用已有连接。

HTTP/1.1 默认持久连接，但不是无限保留。响应定界、Connection: close、空闲超时与错误处理都会影响后续能否复用。规范见 RFC 9112。

HTTP/2 还有多路复用，HTTP/3 则基于 QUIC。不能把 HTTP/1.1 的 Connection 头写法当成所有 HTTP 版本通用的连接开关，也不能把“连接复用”直接等同“同时并发处理请求”。

TCP Keepalive 在什么时候做什么？

一条连接长时间没有传输时，操作系统可以在启用相关选项的条件下发送探测。探测次数、间隔和开始时间，依赖系统与配置。

这是为了在部分空闲失效场景下发现对端不可达，并不是为了持续请求业务接口。Linux 的具体选项可核对 tcp(7)。

连接正在传输数据时，还有其他超时与重传机制。不要把所有断线检测都说成 Keepalive，也不要背一个默认时长后认为任何环境都相同。

为什么 TCP 活着，业务却可能卡住？

假设应用服务还在，操作系统可以回应 TCP 探测，但处理请求的工作线程或数据库连接全部在等待。

此时传输层探测可能正常，业务仍然超时。因为 Keepalive 没有执行“查订单”这条路径，也不知道我们期望的延迟是多少。

应用层心跳或健康检查也要定义范围。只返回一个固定 OK，不能证明数据库、权限系统和全部业务能力健康；检查过重，又可能给故障中的系统增加压力。

图：TCP 还活着，业务仍可能卡住。

代理会让“同一条连接”变得更复杂

浏览器到代理、代理到后端，可能是不同的连接。前一段还保持着，不代表后一段也保持着。

因此，排查空闲后第一次请求失败，要对照各段连接池、空闲超时和关闭行为。某一侧缓存了已经被另一侧关闭的连接，就可能在下一次使用时遇到错误。

重试也不是随手再发一次。如果请求有副作用，需要先判断是否可以安全重试，不能用连接问题替代幂等设计。

图：代理前后，是两段连接。

面试官继续追问

Keepalive 可以取代业务超时吗？

不能。它关注特定空闲失效检测，业务请求需要自己的截止时间。否则连接存在但服务迟迟不返回，用户还是会无限等待。

配置得越频繁越好吗？

不一定。更频繁会增加探测与资源成本，也要考虑网络和代理行为。先明确需要发现哪种失效、希望多久发现，再选择参数。

面试速记卡

• HTTP 持久连接：尽可能复用连接承载后续请求。
• TCP Keepalive：启用后的传输层空闲探测。
• 应用心跳：按应用协议表达状态，不是同一机制。
• 健康：TCP 可达不等于业务可服务。
• 排查：客户端、代理、后端的连接与超时逐段检查。