requests.Session()连接池原理与限制详解

Python的`requests.Session()`确实能通过HTTP/1.1 keep-alive机制复用TCP连接，显著减少重复建连带来的三次握手与TLS开销，但这种复用并非无条件成立——它高度依赖服务端支持（如返回`Connection: keep-alive`、合理配置`keepalive_timeout`）、客户端配置（如显式调大`pool_maxsize`以匹配并发量）、协议/域名严格一致、以及网络环境稳定性；一旦遇到服务端主动关闭、重定向跳转至不同host、手动设置`Connection: close`、异常中断或SSL上下文不兼容等情况，连接池就会失效；真正验证复用效果不能只看代码逻辑，而需结合Wireshark抓包、urllib3调试日志或压测数据——因为DNS解析、TLS协商、服务端处理延迟等环节常掩盖连接复用的实际收益，理解其“尽力而为”的本质，才能在高并发场景中做出可靠优化。

requests.Session() 真的能复用 TCP 连接吗？

能，但只在满足 HTTP/1.1 持久连接（keep-alive）前提下生效。Session 默认启用 Connection: keep-alive，且底层 urllib3 的 PoolManager 会缓存空闲连接到连接池中，后续相同 host + port 的请求可复用已有 TCP 连接，避免三次握手和 TLS 握手开销。

关键限制在于：连接复用需服务端也支持 keep-alive，并返回 Connection: keep-alive 响应头；若服务端主动关闭连接（如 Nginx 默认 keepalive_timeout 75s），或响应中含 Connection: close，urllib3 会立即标记该连接为“不可复用”，下次请求将新建连接。

实操建议：

• 用 curl -v 或 Wireshark 观察实际 TCP 连接数变化，比看代码更可靠
• 服务端未显式关闭时，同一 Session 发起 10 次请求，通常只有 1 次 TCP 握手（首次）
• 若请求间间隔超过服务端 keepalive_timeout，连接大概率已被回收，复用失效

为什么复用了连接，但性能提升不明显？

常见原因是 DNS 解析、TLS 握手、服务端排队或网络延迟掩盖了连接复用收益。TCP 连接复用仅省去建连阶段，不加速请求处理本身。

尤其注意 TLS 复用：urllib3 默认启用 TLS session resumption（通过 ssl.SSLContext.set_session_cache_mode），但依赖服务端配合；若服务端不支持或证书变更，仍需完整 TLS 握手。

实操建议：

• 启用 requests.adapters.HTTPAdapter(pool_connections=10, pool_maxsize=10) 显式控制连接池大小，避免默认值（10）过小导致频繁换连接
• 对高并发场景，pool_maxsize 应 ≥ 并发请求数，否则 urllib3 会阻塞等待空闲连接
• 禁用 SSL 验证（verify=False）会跳过证书链校验，但不跳过 TLS 握手，性能提升有限且不安全

哪些情况会导致 Session 连接池完全失效？

连接池失效 ≠ Session 无效，而是连接无法复用。典型触发条件包括：

• 请求 URL 的 host 或 port 不同（哪怕只是子域名差异，如 api.example.com vs www.example.com）
• 使用了不同协议（http:// 和 https:// 分属不同池）
• 手动设置了 Connection: close 请求头
• 请求抛出异常（如超时、连接中断）后，urllib3 可能将对应连接标记为损坏并丢弃
• 显式调用 session.close() 或 Session 对象被垃圾回收

一个易忽略点：重定向（302）后的新请求，若跳转到不同 host，不会复用原连接——urllib3 按最终目标地址分池，不是按初始请求地址。

如何验证当前 Session 是否真的在复用连接？

最直接方式是抓包看 TCP 流数量，或通过 urllib3 日志确认连接获取行为：

import logging
logging.basicConfig(level=logging.DEBUG)
requests.packages.urllib3.add_stderr_logger()

日志中出现 Starting new HTTPS connection 表示新建连接，而 Resetting dropped connection 或 Retrying 则意味着复用失败或重试。

更轻量的检查方法是观察连接池状态：

s = requests.Session()
s.get('https://httpbin.org/get')
# 查看连接池中活跃连接数
print(len(s.adapters['https://'].poolmanager.pools))

注意：pools 是字典，key 为 (host, port) 元组，值为 HTTPConnectionPool 实例；其 num_connections 属性不暴露，需靠日志或调试器观察内部 _new_conn() 调用频次。

真正复杂的点在于：连接复用是“尽力而为”，受客户端配置、服务端策略、中间代理、网络抖动共同影响，不能当作强保证。高频调用前务必结合真实网络环境做压测，而非仅依赖文档描述。

好了，本文到此结束，带大家了解了《requests.Session()连接池原理与限制详解》，希望本文对你有所帮助！关注golang学习网公众号，给大家分享更多文章知识！