requests库底层实现原理解析

亲爱的编程学习爱好者，如果你点开了这篇文章，说明你对《requests 库的底层实现原理解析》很感兴趣。本篇文章就来给大家详细解析一下，主要介绍一下，希望所有认真读完的童鞋们，都有实质性的提高。

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

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），但你可以绕过或替换：

• 设 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)

注意几个关键点：

• total 是总尝试次数（含首次），不是“额外重试几次”
• status_forcelist 必须显式列出要重试的状态码；400、401、403、404 默认不重试
• allowed_methods 默认不含 POST，因为非幂等方法重试有风险；若真要重试 POST，得明确加上
• 重试间隔默认是指数退避，但不会 sleep 主线程——urllib3 在每次重试前会调用 time.sleep()，这点容易被忽略

底层超时（connect / read）和重试是两套独立机制，别以为设了 timeout=(3, 30) 就自动带重试。

今天关于《requests库底层实现原理解析》的内容就介绍到这里了，是不是学起来一目了然！想要了解更多关于的内容请关注golang学习网公众号！