HTTP Keep-Alive 与 TCP KeepAlive：名字相似，解决的问题不同

资料 在 Keep-Alive 小节里把两个名字很像的概念放在了一起：HTTP 的 Keep-Alive 和 TCP 的 KeepAlive。它们都和“连接不要立刻断”有关，但所在层级、触发方式、解决的问题并不一样。

HTTP Keep-Alive 是应用层的长连接机制。它关心的是：一次 HTTP 请求响应结束后，这条 TCP 连接能不能继续留下来，给后续 HTTP 请求复用。这样就不用每个请求都重新三次握手、传输数据、再四次挥手。

TCP KeepAlive 是 TCP 层的保活探测机制。它关心的是：一条已经空闲很久的 TCP 连接，对端到底还在不在。如果连接长期没有业务数据，操作系统可以定期发探测包，对端回 ACK 就认为连接还活着；连续探测没有响应，就认为连接可能失效并关闭它。

HTTP/1.0 时代，默认更接近短连接模型。一个请求建立一次 TCP 连接，请求资源，拿到响应，然后释放连接。如果页面上有很多图片、脚本、接口请求，每个资源都这样走一遍，连接建立和关闭的开销会很重。文中也提到，HTTP/1.0 需要通过请求头配置 `Connection: Keep-Alive` 来使用长连接。

HTTP/1.1 默认开启长连接。客户端和服务器完成一个 HTTP 请求响应后，不马上关闭 TCP 连接，而是继续保持打开。后续请求可以继续走这条连接，省掉重复握手和挥手的时间，也减少服务器和网络设备处理连接状态变化的压力。

把它放到真实页面里看就更直观：浏览器访问一个网页，HTML 里可能引用 CSS、JS、图片、字体，还可能立刻发起接口请求。长连接让这些请求尽量复用已有 TCP 连接，不必为每个小资源都从零开始建立连接。

长连接能提升性能，但它不是免费午餐。资料 也提醒了这一点：长时间的持久连接会占用服务器资源，尤其在高并发场景下更明显。每条连接都可能占用文件描述符、内核连接状态、读写缓冲区和应用层连接对象。

如果连接一直不关闭，服务端很快会遇到资源上限。比如大量客户端打开连接后长时间不发送请求，服务器看起来没有处理多少业务，却被空闲连接占满了。反过来，如果超时时间设置得太短，连接复用效果又会变差，客户端频繁重连，延迟和 CPU 开销都会上升。

所以 HTTP Keep-Alive 通常要配合空闲超时时间、最大请求数、反向代理连接池、上游连接复用等策略一起看。Nginx、应用服务器、网关和客户端 SDK 都可能有自己的连接复用参数。排查问题时，不能只看业务接口耗时，还要看连接是否频繁新建、是否过早关闭、是否有大量空闲连接堆积。

TCP KeepAlive 的位置更底。它由操作系统和 TCP 协议栈实现，不是 HTTP 头部，也不是浏览器主动声明的应用层长连接。文中的说法很贴切：TCP 有一个定时任务，空闲超过一定时间后，会向对端发送探测报文，用来判断对端是否还存活。

为什么需要它？因为 TCP 连接不一定会优雅关闭。对端进程崩溃、机器断电、网络中断、防火墙丢弃空闲连接，都可能让一端还以为连接存在。没有业务数据时，应用层可能迟迟感知不到连接已经失效。TCP KeepAlive 就是在这种空闲状态下做底层探测。

它的一般过程是：连接空闲一段时间后，内核发出探测包；如果收到 ACK，就认为连接仍可用；如果连续多次探测没有响应，就把连接判定为失效，通知应用层连接出错或关闭。具体空闲多久开始探测、探测间隔多长、最多探测几次，通常由操作系统参数控制。

把两个概念放在协议栈里，就不容易混。HTTP Keep-Alive 在应用层，它处理的是 HTTP 请求响应的复用；TCP KeepAlive 在传输层，它处理的是空闲 TCP 连接的存活检测。

前者更像性能优化：少做重复的建连和断开。后者更像可靠性兜底：连接很久没说话时，确认对端是否还在。一个连接可以使用 HTTP Keep-Alive，但系统层面的 TCP KeepAlive 没开；也可以是一个自定义 TCP 长连接，完全不用 HTTP，却开启了 TCP KeepAlive 做空闲探测。

这也是面试和排查里最常见的坑。问 HTTP Keep-Alive 时，不要回答“内核定期发探测包”；问 TCP KeepAlive 时，也不要回答“复用同一条连接发送多个 HTTP 请求”。名字相似，问题完全不是一个层面的。

还有一个常被放在一起讨论的概念：业务心跳。比如即时通信、游戏、物联网设备上报，经常会在应用层定时发送 ping、pong 或 heartbeat 消息。它和 TCP KeepAlive 的目标有重叠，都能帮助发现断开的连接，但粒度不同。

TCP KeepAlive 只知道 TCP 连接是否还有响应，它不理解用户是否在线、会话是否过期、设备状态是否正常。业务心跳可以带用户 ID、会话版本、设备状态、最后活动时间，也能顺便做续期和状态同步。对于需要实时感知在线状态的系统，业务心跳通常不能被 TCP KeepAlive 完全替代。

不过业务心跳也不能乱设。间隔太短，会带来大量空包和服务端压力；间隔太长，掉线发现慢。移动端还要考虑省电和弱网。实际应用中，经常是 HTTP Keep-Alive 负责请求复用，TCP KeepAlive 兜底检测死连接，业务心跳负责应用语义上的在线状态。

如果你看到接口延迟偶尔很高，可以先确认是不是每次请求都在重新建连。抓包里频繁出现 SYN、SYN-ACK、ACK，再跟着 FIN、ACK、FIN、ACK，说明连接没有被有效复用。也可以看客户端连接池、服务端 access log、反向代理的 keepalive 配置。

如果问题是“连接明明断了，服务端很久才发现”，重点就不是 HTTP Keep-Alive，而是 TCP KeepAlive 或业务心跳。比如客户端断网后没有发送 FIN，服务端连接还保持 ESTABLISHED，应用层也没有读写动作，这时只能等探测、心跳或下一次业务读写暴露错误。

如果问题是服务器连接数过高，就要反过来看长连接资源。空闲超时时间是不是太长，客户端是否保持了过多连接，代理到上游的连接池是否没有回收，最大请求数是否缺失。这类问题不能简单地说“开 Keep-Alive 就好”，要在性能和资源之间取一个合适的值。

如果被问 HTTP Keep-Alive，可以这样讲：它是 HTTP 应用层的长连接机制，让多个 HTTP 请求和响应复用同一条 TCP 连接，减少重复三次握手和四次挥手带来的开销。HTTP/1.0 通常需要显式配置，HTTP/1.1 默认使用长连接。

如果被问 TCP KeepAlive，可以这样讲：它是 TCP 层的保活机制，由操作系统协议栈在连接空闲一段时间后发送探测包，用来判断对端是否仍然存活。收到 ACK 说明连接还可用，连续无响应则认为连接失效。

最后补一句区别就很稳：HTTP Keep-Alive 关注连接复用和性能，TCP KeepAlive 关注空闲连接存活检测和资源回收。它们可以同时存在，但不能互相替代。业务系统如果还需要在线状态、会话续期、设备健康检查，通常还要设计应用层心跳。