能，requests.session() 在 http/1.1 keep-alive 下复用 tcp 连接：默认启用 connection: keep-alive，urllib3 通过 poolmanager 缓存空闲连接，相同 host+port 请求可复用，但依赖服务端支持且受超时、关闭头、协议/域名差异等限制。
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 连接复用仅省去建连阶段，不加速请求处理本身。
立即学习“Python免费学习笔记（深入）”；
尤其注意 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.comvswww.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() 调用频次。
真正复杂的点在于：连接复用是“尽力而为”，受客户端配置、服务端策略、中间代理、网络抖动共同影响，不能当作强保证。高频调用前务必结合真实网络环境做压测，而非仅依赖文档描述。
