一句话定义：连接复用是指客户端和服务器在同一条 TCP 连接上连续发送多个 HTTP 请求和响应，而不是每个请求都重新建立连接。HTTP/1.1 默认开启该行为，早期靠请求头 Connection: keep-alive 显式声明。
为什么值得省：建立一条 TCP 连接需要三次握手，至少一个网络往返；如果使用 HTTPS，还要再进行 TLS 握手，又要多几个往返。跨地域访问时，一次建立连接就可能花掉几十甚至上百毫秒，而一个普通 API 请求本身也许只要几毫秒。打个比方：你打客服电话咨询，每问一个问题就挂断重拨，等待接通的时间比说话还长；连接复用就是“先别挂，我接着问”。
和相邻概念的区别：
| 概念 | 省的是什么 | 关键差异 |
|---|---|---|
| 连接复用 Keep-Alive | 反复建立连接的开销 | 一条连接排队处理多个请求，同一时刻只处理一个 |
| 连接池 Connection Pool | 连接创建和销毁的开销 | 一批连接备着给多个请求轮流借用，池中连接靠复用维持 |
| 多路复用 Multiplexing（HTTP/2） | 同一条连接上的排队等待 | 多个请求真正并发跑在一条连接上，互不阻塞 |
| WebSocket | 不省握手，是换协议 | 目的是双向持续推送，不是为了少握手 |
真正的坑在服务端：复用意味着连接会“挂着不释放”。空闲连接要占用内存和文件描述符，因此服务端必须设置空闲超时（keepalive timeout）和最大连接数。更隐蔽的问题是：中间的负载均衡、NAT 网关也可能悄悄回收空闲连接，而客户端还拿着已失效的连接发送请求，于是出现偶发的 502 或连接重置。经验法则是：客户端的空闲超时应该短于服务端，让客户端主动更换连接。
AI 场景下尤其容易出问题：大模型 API 网关。流式输出（SSE）的一次请求可能持续几十秒，整条连接在这期间被独占。并发一上来，后端连接池被打满，新请求只能排队等一条空闲连接，表现为 P99 延迟飙升、超时率上升。更糟的是，客户端早已断开，后端可能还在继续生成，连接迟迟不释放，形成雪崩。因此网关通常要做几件事：限制并发并按上游容量排队；给不同上游配置独立的池上限；下游断开时及时取消上游请求；把鉴权、计费等短请求和生成类长请求分开管理连接。
对普通人来说，一个实际意义是：你觉得“AI 回答很慢”，有时并非模型在思考，而是你的请求正在网关排队，等一条空闲连接。具体超时与并发参数，各家网关差异很大，以官方文档为准。