长连接与短连接#

HTTP/1.1 默认 Keep-Alive：复用TCP连接发送多个请求

连接池： 数据库/Redis连接池维护长连接复用

心跳： 长连接需要心跳保活（TCP keepalive 或应用层心跳）

短连接是每次请求都建立一个新的TCP连接，请求完就断开，优点是简单不占服务端资源，缺点是频繁建连和断连开销很大，尤其是TCP三次握手和四次挥手的成本以及TIME_WAIT累积问题。长连接是建立一次TCP连接后持续复用，HTTP/1.1默认开启Keep-Alive就是连接复用机制，多个HTTP请求可以在同一个TCP连接上串行发送。在后端开发中，数据库连接池和Redis连接池都是长连接复用的典型实践，预先建好一批连接放在池中，业务线程从池中借用连接，用完归还，避免了每次操作都建连的开销。但长连接需要维护成本：一是心跳保活，TCP层有Keepalive探测机制，应用层也可以自定义心跳包来检测连接是否存活；二是超时管理，连接空闲太久需要回收。选择策略一般是：高频短周期的请求用长连接配连接池，低频临时性的请求用短连接即可。

追问方向：

• “HTTP Keep-Alive 和 TCP Keepalive 区别？”→ Keep-Alive 是 HTTP 层连接复用（复用 TCP 连接发多个请求），Keepalive 是 TCP 层心跳探测（检测连接是否存活，默认 2 小时发一次）
• “连接池的连接过期怎么处理？”→ 定期心跳检测 + 借出时 testOnBorrow 验证 + 空闲超时回收（minEvictableIdleTimeMillis）+ 最大存活时间强制关闭
• “什么时候该用短连接？”→ 低频临时性请求、客户端数量极多但每个请求量少（避免服务端维护大量空闲长连接占资源）的场景

易错点：

• ❌ HTTP/1.1 的 Keep-Alive 就是长连接——只是连接复用不是永久
• ❌ 长连接不需要维护——需要心跳保活和超时管理