用代理跑批量请求时，很多人会发现一个现象：连续发请求很快，隔一阵再发就明显慢一拍。差别往往不在网速，而在连接本身。这篇把 Keep-Alive 和连接复用讲清楚，看完你就知道长连接到底省了什么、轮换代理为什么难享这个好处。
一次连接，成本其实不小
客户端和服务器要通信，先得建立 TCP 连接，这至少要三次握手，一次往返一次确认。如果走的是加密通道，还要额外加一次 TLS 握手，来回次数翻倍。算下来，建立一条全新连接的开销，比很多人想象的大得多——尤其当请求本身很小的时候，握手甚至比传输还耗时。
Keep-Alive 省的是”重复建设”
HTTP/1.1 默认支持长连接：一条连接建立后可以连续发多个请求，不用每个请求都重新握手。这个机制就是 Keep-Alive，也叫连接复用。对”请求多、单次小”的批量任务来说，复用把固定开销摊薄，总耗时能明显下降。
| 对比项 | 短连接 | 长连接（Keep-Alive） |
|---|---|---|
| 连接建立 | 每个请求都重新握手 | 一条连接服务多个请求 |
| 固定开销 | 每次都全额承担 | 摊薄到多个请求 |
| 延迟表现 | 每次都有握手延迟 | 后续请求免握手 |
| 服务器压力 | 连接频繁建立销毁 | 连接数更少更平稳 |
| 适用场景 | 低频偶发请求 | 高频批量请求 |
代理场景下，复用依然成立
走代理时链路更长：客户端连代理、代理再连目标站，两段都有建立成本。好在多数代理服务支持长连接，客户端到代理这一段可以稳定复用，代理到目标站那一段也会尽量保持。批量任务里，复用带来的提速在代理链路上同样成立，甚至更明显。
连接复用省的是握手这类固定开销，不是网速本身。请求越短、越频繁，复用的收益越大；请求又大又少，收益就有限。
轮换代理为什么难享这个好处
动态轮换代理每次切换出口地址，本质上是旧连接作废、新连接重建，等于主动放弃复用。所以需要频繁换 IP 的场景，往往也伴随着较高的连接开销，这是轮换模式的固有代价。反过来说，静态出口、固定线路的代理更适合长连接，能把复用收益吃到手。
怎么把复用用好
- 客户端启用连接池，复用空闲连接，别频繁开关
- 给 keep-alive 设置合理的超时，太长占资源、太短没意义
- 批量任务里别为”求心安”频繁切换出口，稳定才省
- 配合重试机制：复用的连接断了要能自动重连，而不是无限等待
和 IP 代理的关系
连接复用决定的是批量任务的总耗时和稳定性。静态或长连接友好的代理资源，配合客户端连接池，是批量采集、接口调用这类场景的正当优化方式——它降低的是握手开销与连接抖动，不改变请求本身的合法性。理解连接生命周期，选代理、调参数时就能少走弯路。
一句话：Keep-Alive 让一条连接服务多个请求，省的是反复握手的固定开销；轮换代理享受不到这部分红利，静态出口才是长连接的菜。