Python HTTP 客户端 requests 的实现原理-Python教程-PHP中文网

requests 底层基于 urllib3 而非 urllib，由 urllib3 管理连接池、重试、SSL 验证和 HTTP/1.1 流水线；它不支持 HTTP/2 和异步，重试需手动配置 HTTPAdapter。

python http 客户端 requests 的实现原理

requests 底层用的是 urllib3，不是 urllib

requests 本身不直接操作 socket，它把网络请求的细节全交给了 urllib3。这个库负责连接池、重试、SSL 验证、HTTP/1.1 流水线等核心逻辑。你调用 requests.get() 时，实际是 urllib3.PoolManager 在背后管理连接、复用 TCP 连接、自动处理 Connection: keep-alive。

常见误解是 requests 封装了标准库的 urllib.request，其实完全无关——requests 早期确实基于它，但 2013 年起就彻底切换到 urllib3（一个独立维护的第三方库），因为后者支持连接池、更可控的超时、更好的错误分类。

requests.Session() 对应一个 urllib3.PoolManager 实例，所以复用 Session 才能真正复用连接池
如果你禁用连接池（比如传 pool_connections=0），urllib3 会退化为每次新建连接，性能骤降
requests.adapters.HTTPAdapter 是你和 urllib3 之间的胶水层，所有自定义行为（如重试策略、池大小）都通过它配置

HTTP/2 和异步不是 requests 的事

requests 是同步阻塞式 HTTP 客户端，不支持 HTTP/2，也不支持 async/await。它发请求时会卡住当前线程，直到响应头收完（或超时）。这意味着：

即使服务端支持 HTTP/2，requests 也只走 HTTP/1.1 —— 它压根没实现 HTTP/2 帧解析
想并发发 100 个请求？靠 threading 或 multiprocessing 硬扛，不是靠 requests 本身“变快”
真正的异步替代方案是 aiohttp 或 httpx（后者 sync/async 双模式，底层用 httpcore 而非 urllib3）

SSL 验证和证书路径由 urllib3 控制，但 requests 提供快捷入口

证书验证逻辑在 urllib3.util.ssl_.create_urllib3_context() 里，它默认加载系统 CA 包（如 certifi），但你可以绕过或替换：

Session Handoff

创建全面的交接文档，使新AI代理能够无缝继续工作，消除歧义。解决上下文耗尽问题。时机：(1)用户请求保存交接，(2)上下文即将满，(3)主要任务完成，(4)会话结束，(5)恢复工作时。关键词：保存状态、创建交接、上下文已满、暂停、从...恢复、加载交接、保存进度、会话转移、交接

下载

设 verify=False 会跳过全部 SSL 校验，同时 suppress InsecureRequestWarning
传路径如 verify="/path/to/cert.pem"，urllib3 会用它作为 CA bundle，而非系统默认
环境变量 REQUESTS_CA_BUNDLE 或 CERT_PATH 会影响 urllib3 加载位置，但优先级低于代码中显式传入的 verify=
自签名证书场景下，别只改 verify=False；更安全的做法是导出证书、用 verify="mycert.crt"

重试机制必须手动打开，且只对部分状态码生效

requests 默认不重试任何请求。要启用重试，得配 HTTPAdapter 并挂到 Session 上：

from requests.adapters import HTTPAdapter
from urllib3.util.retry import Retry

retry_strategy = Retry(
    total=3,
    status_forcelist=[429, 500, 502, 503, 504],
    allowed_methods=["HEAD", "GET", "OPTIONS"]
)
adapter = HTTPAdapter(max_retries=retry_strategy)
session = requests.Session()
session.mount("https://", adapter)

注意几个关键点：