网络网页爬虫后端【免费下载链接】curl_cffiPython binding for curl-impersonate fork via cffi. A http client that can impersonate browser tls/ja3/http2 fingerprints.项目地址https://gitcode.com/gh_mirrors/cu/curl_cffi点击查看免费下载本篇技术指南聚焦于curl_cffi浏览器模拟能力中一个关键且容易被忽视的细节——TLSpre_shared_keyPSK扩展编号 41扩展。文章从 RFC 8446 的协议定义出发解释 PSK 扩展在真实浏览器访问中的出现规律、它与 HTTP Session Cookie 的机制类比以及在使用旋转代理时可能引发的 IP 关联风险随后结合仓库源码深入讲解curl_cffi 0.12.0引入的proxy_credential_no_reuse选项如何将 TLS 会话缓存与代理用户名、出口 IP 绑定。读完本文你将理解 PSK 扩展为何不能由客户端强行注入、curl_cffi 为什么建议让客户端自动管理该扩展并掌握在高并发代理抓取场景下规避 TLS 会话泄漏的配置思路。什么是 TLS PSK(41) 扩展PSK 是Pre-Shared Key预共享密钥的缩写其语义定义在 RFC 8446TLS 1.3第 2.2 节Once a handshake has completed, the server can send the client a PSK identity that corresponds to a unique key derived from the initial handshake (see Section 4.6.1). The client can then use that PSK identity in future handshakes to negotiate the use of the associated PSK.简单来说当一次 TLS 握手完成后服务器可以向客户端下发一个与该连接派生的密钥对应的 PSK 身份标识identity客户端在后续握手时携带该身份即可协商复用之前建立的会话密钥从而跳过完整的密钥交换过程实现会话恢复session resumption。在 IANA 的 TLS 扩展类型表中该扩展的编号为41即pre_shared_key与之配套的还有编号 45 的psk_key_exchange_modesPSK 密钥交换模式以及编号 42 的early_data0-RTT 早期数据。curl_cffi在 curl_cffi/requests/impersonate.py 中维护了完整的 TLS 扩展名映射表其中明确列出了41: pre_shared_key, 42: early_data, 45: psk_key_exchange_modes,同时在 TLS_CIPHER_NAME_MAP 中也能看到 PSK 相关的密码套件例如0x008C: TLS_PSK_WITH_AES_128_CBC_SHA, 0x008D: TLS_PSK_WITH_AES_256_CBC_SHA, 0xC035: TLS_ECDHE_PSK_WITH_AES_128_CBC_SHA, 0xC036: TLS_ECDHE_PSK_WITH_AES_256_CBC_SHA, 0xCCAC: TLS_ECDHE_PSK_WITH_CHACHA20_POLY1305_SHA256,PSK 扩展的出现规律首次访问没有二次访问出现PSK 扩展不是每次握手的固定成员它的出现取决于客户端是否持有可复用的会话密钥。典型规律如下首次访问一个网站时客户端没有可用的 PSK因此在 ClientHello 的扩展列表中不会出现pre_shared_key短时间内再次访问同一个网站时客户端可以基于服务器之前下发的 PSK 身份发起会话恢复此时扩展列表中就会携带 PSK。你可以通过访问https://tls.peet.ws/api/all亲身体验这一行为第一次打开时观察返回的 TLS 指纹 JSON扩展列表中通常没有 PSK随后刷新页面pre_shared_key扩展就会出现在列表中。这是验证 PSK 行为最直接、无需额外工具的观测方法。要正确实现 PSK 扩展客户端必须在内存中或磁盘上持久化某种形式的会话缓存session cache。所有主流浏览器在很早之前就内置了这一能力这是它们看起来像真实浏览器的众多指纹细节之一。PSK 与 HTTP Session Cookie 的机制类比文档给出了一个非常到位的类比PSK 的机制与行为就像 HTTP 会话 Cookie。维度HTTP Session CookieTLS PSK服务器下发首次响应时下发 Set-Cookie首次握手后下发 PSK 身份标识客户端回传后续请求自动携带 Cookie后续握手自动携带 PSK 扩展用途恢复断开的 HTTP 会话恢复断开的 TLS 会话语义证明你之前来过证明你之前建立过连接服务器在下发 PSK 时有可能将来源 IP 与密钥的映射关系保存下来。这意味着 PSK 不是纯匿名的会话凭据——它隐式携带了这个密钥是从哪个 IP 发起的握手中派生的这一关联信息。旋转代理场景下的隐患IP 变了PSK 没变既然服务器可能维护 IP 与 PSK 的映射那么在使用旋转代理rotating proxies时复用 TLS 会话就会引发问题。文档中给出了一个直观的时序图┌───────────┐ ┌───────────┐ │ │ │ │ │ │ IP: 10.0.0.1 │ │ │ ┼─────────────TLS─Hello──────────────► │ │ │ │ │ │ ◄─────────────PSK:─xxx───────────────┼ │ │ │ │ │ │ │ │ │ │ │ │ Server │ │ Client │ IP: 10.0.0.2 │ │ │ ┼─────────────TLS─with─PSK───────────► │ │ │ │ │ │ ◄─────────────Blocked────────────────┼ │ │ │ │ │ │ │ PSK: xxx was │ │ │ │ associated with │ │ │ │ 10.0.0.1, not │ │ └───────────┘ 10.0.0.2 └───────────┘整个流程可以拆解为三步客户端通过出口 IP10.0.0.1例如某个代理节点完成首次握手服务器下发了 PSKxxx并记录该密钥与10.0.0.1的关联客户端切换代理出口 IP 变为10.0.0.2但 TLS 会话缓存仍然有效于是它带着 PSKxxx发起握手服务器发现该 PSK 关联的源 IP 是10.0.0.1而非10.0.0.2于是判定异常并直接阻断连接。这就是TLS 会话与旋转代理冲突的核心风险会话恢复本是降低握手开销的优化机制但在代理轮换场景下它反而成了暴露客户端行为异常的信号。proxy_credential_no_reuse将会话缓存绑定到代理凭据幸运的是curl_cffi从0.12.0版本起新增了名为proxy_credential_no_reuse的选项。启用后TLS 会话缓存将基于代理用户名和 IP 进行绑定只有当代理用户名与出口 IP 都匹配时会话才允许被复用。从服务器的视角看效果是Pre-Shared Key被锁定在与它最初建立握手相同的源 IP 上不会再在不同的出口节点之间跳跃。在源码层面该选项的实现位置清晰可查选项本身定义在 curl_cffi/const.pyPROXY_CREDENTIAL_NO_REUSE 0 1022属于CurlOpt枚举在 curl_cffi/requests/utils.py 的代理配置段中只要检测到proxies配置非空就会自动启用该选项if proxies: # Turn on proxy_credential_no_reuse, which has the following benefits: # 1. New connection will be made when proxy username changed # 2. New TLS session will be created based on proxy address, i.e. when accessing # the same site with different proxies, TLS session wont leak previous IP. c.setopt(CurlOpt.PROXY_CREDENTIAL_NO_REUSE, 1)这段代码注释清晰地说明了启用后的两个直接收益代理用户名变化时建立新连接——不再复用旧的底层连接基于代理地址创建新的 TLS 会话——使用不同代理访问同一站点时TLS 会话不会泄漏之前的 IP 关联信息。这意味着在使用requests.Session配合代理访问时你无需手动干预 PSK 行为curl_cffi会自动完成会话缓存与代理凭据的绑定。文档同时提到未来版本可能在启用代理时默认开启该选项这也符合抓取与反检测场景的安全默认值取向。我应该如何启用 PSK 扩展结论是你不需要也不应该手动启用它。请先阅读上面的机制解释——一般来说客户端应自行管理该扩展并在第二次请求时自动提供它。以下几点是文档给出的明确建议不要强行注入随机 PSK从服务器角度看如果你强行携带一个随机值的 PSK 扩展就像携带了一个无效 Cookie 值是你不是真实访客的明显信号。真实浏览器绝不会发送一个毫无来源的 PSK。不要试图完全禁用 PSK如果你出于伪装成首次访客的目的而希望不发送 PSK 扩展当前版本不支持这一行为。可选的替代方案是回退到更早版本的curl_cffi或者在每次请求时创建新的 Session新的 Session 自然没有可复用的会话缓存也就不会携带 PSK。让客户端决定值得注意的是一些同样面向浏览器模拟的 HTTP 客户端会暴露添加或不添加 PSK的控制开关但如果你的目标是模拟真实浏览器应当让客户端自己决定何时发送 PSK而不是手动干预。小结TLS PSK(41) 扩展是浏览器 TLS 指纹中一个低频但关键的细节它由客户端会话缓存驱动首次访问不出现、二次访问自动出现是会话恢复机制的体现它与 HTTP Session Cookie 机制同构但服务器可能维护 IP 与密钥的映射因此旋转代理 复用 TLS 会话 被识别的风险curl_cffi自0.11.0libcurl 8.13.0起在底层支持 PSK 扩展自0.12.0起通过proxy_credential_no_reuse选项将 TLS 会话缓存与代理用户名、出口 IP 绑定规避会话在代理节点间漂移的问题正确姿势是不手动注入、不强行禁用让客户端基于真实会话状态自动管理该扩展。相关实现与文档可以在仓库的 curl_cffi/requests/utils.py、curl_cffi/requests/impersonate.py、curl_cffi/const.py 以及 docs/impersonate/psk.rst 中进一步查阅。赞分享网络网页爬虫后端【免费下载链接】curl_cffiPython binding for curl-impersonate fork via cffi. A http client that can impersonate browser tls/ja3/http2 fingerprints.项目地址https://gitcode.com/gh_mirrors/cu/curl_cffi点击查看免费下载相关推荐CANN ops-transformer 算子解析aclnnMoeTokenPermuteGrad 接口详解与 MoE Token Permute 反向传播实现CANN ops transformer 算子解析aclnnMoeTokenPermuteGrad 接口详解与 MoE Token Permute 反向传播实网络网页爬虫后端轻松下载B站视频解锁4K大会员画质的完整指南轻松下载B站视频解锁4K大会员画质的完整指南 你是否遇到过这样的困扰看到B站上精彩的教程视频想要离线学习但网络不稳定无法流畅观看或者身为大会员想要保存4网络网页爬虫后端kube-state-metrics 中 VolumeAttachment 指标详解从指标清单到源码实现kube state metrics 中 VolumeAttachment 指标详解从指标清单到源码实现 kube state metrics 通过内置的 v网络网页爬虫后端上一篇react-native-snap-carousel 实现图片压缩减少网络传输与内存占用下一篇PersistentWindows常见问题解决方案从图标变红到窗口无响应的完整排查手册创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考