4、连接复用：HTTP Keep-Alive、连接池管理、最佳复用策略
你有没有遇到过这种情况：SDK 接入后，网络请求一波接一波，但耗时总比别人多那么几十毫秒。翻看抓包，发现每次请求都重新建 TCP 连接，三次握手加 TLS 协商，光握手就占了大半时间。我最早在优化某个广告 SDK 时就被这个问题卡了很久——明明数据量不大，延迟却高得离谱。后来才意识到，连接复用没做好，再快的网络层也是白搭。
4.1 HTTP Keep-Alive 机制解析
HTTP Keep-Alive 是连接复用的基础。说白了，就是让同一个 TCP 连接在请求/响应结束后不被立即关闭，而是保持一段时间，给下一个请求继续使用。
我习惯用一个比喻：短连接就像每次去食堂吃饭都重新买饭票，Keep-Alive 就像办了张月卡，刷一次可以连着打好几份菜。你想想看，食堂窗口没变，但省下了每次掏钱、找零的时间。
在实际项目中，Keep-Alive 通过请求头 Connection: keep-alive 启用（HTTP/1.1 默认开启）。但要注意几个关键参数：
- keepalive_timeout：空闲连接保持时间。设太短，连接容易被回收，复用率低；设太长，占用系统资源。
- keepalive_requests：单个连接能处理的最大请求数。超过后强制关闭，防止连接长期不更新导致负载不均。
我在项目中遇到过一种情况：某个第三方 SDK 的 Keep-Alive 超时设置只有 5 秒，而我们的请求间隔刚好 6 秒，结果每次请求都重新建连，白白浪费了连接。后来我们统一把超时调到 15 秒，连接复用率从 12% 飙升到 78%，接口耗时降了 40%。
4.2 连接池的常见陷阱
仅靠 Keep-Alive 还不够，连接池才是精细化管理的利器。连接池管理连接的创建、复用、回收和健康检查。但很多开发者容易踩坑，我列了几个典型问题：
- 最大连接数设得太小：并发请求多时，新连接被阻塞，导致排队延迟。我曾经遇到过一个推送 SDK，最大连接数只有 2，结果同时涌来 10 个请求，后面 8 个全在等——明明网速很快，但延迟硬生生拖到 500ms。
- 空闲回收策略不当：连接空闲太久不回收，浪费端口资源；回收太激进，刚回收又马上建连，造成震荡。
- 没有做健康检查：服务端可能悄无声息地关闭了连接（比如超时断连），但客户端还认为是可用的，一用就报错。
下面这张表对比了几种常见配置场景下的表现：
| 参数项 | 配置值（太小） | 配置值（太大） | 推荐值（我的经验） |
|---|---|---|---|
| 最大连接数 | 2~5（易阻塞） | 50+（浪费资源） | CPU 核心数 × 2~4，动态调整 |
| 空闲超时 | 3~5 秒（频繁建连） | 60 秒+（占用 socket） | 15~30 秒 |
| 每个路由最大连接数 | 1（无复用空间） | 10+（竞争头部锁） | 2~4 |
| 健康检查间隔 | 关闭（连接假活） | 1 秒（检查开销大） | 5~10 秒，使用 TTL 探测 |
4.3 最佳复用策略：从实践出发
光有理论知识不够，得有一套可落地的复用策略。我把它总结成三个步骤：
- 优先复用已有连接：发起请求前，先从连接池获取空闲连接；如果连接被标记为“健康”，直接复用。
- 保活与探测：在 Keep-Alive 超时前，发送“心跳”或“零窗口探测”确保连接存活。我习惯用应用层的心跳包（比如每隔 10 秒发一次空 GET），而不是完全依赖内核的 TCP Keep-Alive。
- 及时回收不可用连接：一旦连接报错（如 RST、超时），立即从池中移除并关闭，避免后续请求污染。
下面这张图展示了整个决策流程：
你可能会问：复用连接后，会不会出现队头阻塞？确实，HTTP/1.1 的 Keep-Alive 在一个连接上只能串行请求，如果前一个请求慢，后面的就得等。我建议的做法是：
- 多路复用优先考虑 HTTP/2：如果服务端支持，直接上 HTTP/2，它可以在一个连接上并行处理多个流，彻底解决队头阻塞。
- 如果只能用 HTTP/1.1：针对同一个域名准备 2~4 个 Keep-Alive 连接，配合轮询使用，避免单连接阻塞全局。
最后提一下连接健康检查。不要完全信任连接池中的空闲连接，服务端可能因为各种原因（如负载均衡踢掉、防火墙超时）单方面关闭连接。我习惯在复用前先发一个零字节的探测包（类似 TCP keepalive），如果没收到确认就重新建连。探测频率控制在 5~10 秒一次，避免影响正常请求。