Keep-Alive 通常指 HTTP 持久连接:一次 TCP 连接在处理完一个请求/响应后不立即关闭,后续请求可继续使用它,节省重复握手和连接建立成本。HTTP/1.1 默认采用持久连接语义,除非连接被关闭或协商/策略另有要求;HTTP/1.0 时代常通过 Connection: keep-alive 扩展实现。
HTTP/1.1 持久连接本身不等于 HTTP/2 多路复用。HTTP/1.1 通常同一连接上的请求按序处理,流水线支持有限且响应顺序约束会造成队头等待;浏览器和客户端经常建立多个连接。HTTP/2 可在一个连接中交错多个流,但底层 TCP 丢包仍可能影响该连接的所有流。连接池则是客户端管理多个可复用连接的实现机制,不是 HTTP 头部本身。
长连接仍需管理空闲超时、最大请求数、服务端连接数及负载均衡设备的空闲连接回收。若代理先关闭空闲连接,客户端连接池可能拿到失效连接,因此需设置协调的超时、健康检查和失败重试策略;重试非幂等请求前必须判断请求是否可能已被处理。
HTTP/1.1 连接复用还要求消息边界能够可靠确定,常通过 Content-Length 或分块传输编码界定响应体;错误的长度或中间设备异常可能导致连接无法安全复用。服务端完成响应后可选择继续保持连接,也可发送关闭信号。客户端应遵守协议并处理服务器主动断开,而非假设连接总能复用。
常见追问
Keep-Alive 能减少什么开销?
它可减少重复 TCP 建连与关闭的开销;HTTPS 场景也可避免为每个请求重新完成 TLS 握手。收益取决于连接复用率和连接维护成本。
Keep-Alive 等于 WebSocket 吗?
不等于。Keep-Alive 复用请求响应连接;WebSocket 握手升级后使用双向消息帧进行全双工通信,交互模型不同。
持久连接会永远不关闭吗?
不会。客户端、服务端或中间代理可按空闲超时、资源上限和策略关闭连接,客户端需要正确处理断连和重建。
HTTP/2 是否还需要连接池?
HTTP/2 可在单连接多路复用请求,但客户端仍可能管理连接生命周期或按源、代理、负载等策略建立连接;不能简单认为连接池概念消失。