ylong_http

简介

ylong_http 构建了完整的 HTTP 能力，支持用户使用 HTTP 能力完成通信场景的需求。

ylong_http 使用 Rust 编写，为 OpenHarmony 的 Rust 能力构筑提供支持。

本分支 (https_impl) 在原 ylong_http 基础上新增了完整的 HTTPS 代理客户端功能，包括代理层 TLS 支持、代理功能模块化重构、以及与 libcurl 的性能对比基准。详见”HTTPS 代理模块开发（赛事修改）“章节。

ylong_http 在 OpenHarmony 中的位置

ylong_http 向 OpenHarmony 系统服务层中的网络协议栈模块提供 HTTP 协议支持，经由网络协议栈模块帮助上层应用建立 HTTP 通信能力。

以下是对于上图关键字段的描述信息：

• APP：需要使用上传下载能力的直接面向用户的上层应用。
• request：提供上传下载能力的系统组件。
• netstack：提供网络协议栈功能的系统组件。
• ylong_http：提供 HTTP 能力的系统组件。
  • ylong_http_client：ylong_http 下的模块之一，提供 HTTP 客户端能力。
  • ylong_http:ylong_http 下的模块之一，提供 HTTP 的基础能力。
• ylong_runtime：ylong 提供的 Rust 异步运行时库。
• tokio：业界常用的第三方 Rust 异步运行时库。
• OpenSSL：业界常用的第三方 TLS 实现库。

ylong_http 的内部架构:

ylong_http 内部当前分为两个主要模块：ylong_http_client 客户端模块和 ylong_http 协议组件模块。

ylong_http_client 模块负责提供 HTTP 客户端功能，能够支持用户发送 HTTP 请求，并接收 HTTP 响应，内部又分为三个主要部分:

• sync_impl：同步的 HTTP 客户端实现，该客户端实现不依赖于任何运行时，可以直接在线程模型上运行，但是整体使用同步阻塞策略。
• async_impl：异步的 HTTP 客户端实现，该客户端实现需要使用 Rust 的异步运行时组件。异步 HTTP 客户端利用 Rust 的异步能力，具有优异的性能表现。
• Util：同步和异步的 HTTP 客户端部分实现共通，例如自动重定向、HTTP 代理等。

sync_impl 和 async_impl 接口原型基本一致（主要是 Rust 异步语法与同步语法的差异），所以用户可以在较小的代码改动量下完成同步和异步逻辑的切换。

sync_impl 和 async_impl 的整体架构相同，分为如下模块：

• Client：对外提供 HTTP 客户端的基本接口，例如配置客户端的相关选项，发送 HTTP 请求等。
• ConnectionPool：主要负责大量连接管理，管理所有 Dispatcher 的生命周期，包括启动、运行、停止。HTTP 协议是基于连接的通信协议，涉及连接复用、连接管理等功能。
• Dispatcher：主要负责单一连接管理，管理单个连接的启动、运行、停止、传输。每个连接都被一个 Dispatcher 管辖，由 Dispatcher 决定当前待发送的请求是不是使用它管理的连接。
• Connections：连接对象，可以是 TCP 连接、TLS 连接或者是更加泛化的连接对象，在该连接上进行消息传输和接收，是 Client 和 HTTP 协议的底座。
• Connector：负责创建连接对象。Connector 也是一个 trait，用户可以使用它来定义创建连接时的行为。

Util 中包含了同步和异步的 HTTP 客户端共通的能力，例如：

• Redirect：HTTP 自动重定向能力。当 HTTP 响应返回重定向相关的状态码时，HTTP 客户端会进行自动重定向，并自动发送新的请求到下一跳。
• Proxy：HTTP 代理能力。发送 HTTP 请求时，向代理发送而非直接发送给原始服务器，然后由代理服务器返回原始服务器的响应。本分支在此基础上新增了完整的 HTTPS 代理 TLS 支持。
• Proxy (HTTPS)：（新增） HTTPS 代理客户端完整支持，包括代理层 TLS 单/双向证书验证、H1/H2 CONNECT 隧道、代理连接池隔离等。
• Pool：通用连接池实现，支持多个同步或异步连接的管理，便于上层同步或异步客户端复用已有连接，减少连接重复创建次数，提高性能。
• OpenSSL_adapter：HTTPS 需要在 HTTP 的基础上使用 TLS 能力，在 OpenHarmony 上使用的是 OpenSSL，所以需要对 OpenSSL 的接口进行 Rust 封装。

ylong_http 模块负责提供 HTTP 的基础能力，例如 HTTP2 的 HPACK、HTTP3 的 QPACK 等，主要包含以下关键模块：

• Request：HTTP 请求基础能力，根据 RFC9110 规定实现了 HTTP 请求的所有内容和行为。HTTP 请求主要用于向指定服务器发送请求。
• Response：HTTP 响应基础能力，根据 RFC9110 规定实现了 HTTP 响应的所有内容和行为。HTTP 响应主要是服务器针对客户端请求的回应。
• Body： HTTP 消息体能力，根据 RFC9110 规定实现了 HTTP 消息体的所有内容和行为。HTTP 消息体保存主要数据内容，以便客户端和服务器通信。 HTTP 消息体在协议中有多种形式，在 ylong_http 库中有对应实现，例如 EmptyBody 对应于空消息体，TextBody 对应于明文消息体，ChunkBody 对应于分块消息体，Mime 对应于 Multipart 消息体。
• H1：HTTP1 的所有基础能力，例如 HTTP1 格式的请求和响应的编码器和解码器等。
• H2：HTTP2 的所有基础能力，例如 HTTP2 格式的请求和响应的编码器和解码器、HTTP2 帧编码器和解码器、HPACK等。
• H3：HTTP3 的所有基础能力，例如 HTTP3 格式的请求和响应的编码器和解码器、QPACK 等。

HTTPS 代理模块开发

本章节描述基于原项目为竞赛新增的 HTTPS 代理功能模块。

赛事任务概述

本分支完成了 ylong_http 客户端 HTTPS 代理模块开发，目标任务如下：

子任务	内容	状态
子任务1：HTTPS 代理支持	依赖 OpenSSL 实现 TLS 能力；支持单/双向证书验证；支持代理服务器 TLS 配置项（客户端证书、私钥、算法套件等）	✅ 完成
子任务2：代理功能模块化	结合已有 tunnel 代理能力，抽取独立代理模块，保证新增代理协议的可扩展性	✅ 完成
子任务3：性能对比提升	与 libcurl 进行 HTTP 性能对比，目标在 HTTPS 代理场景下性能提高 20%+	⏳ 部分达成

子任务1：HTTPS 代理支持

双层 TLS 架构

HTTPS 代理在已有 HTTP 能力之上新增了代理层的 TLS 加密，形成”代理 TLS + 目标 TLS”的双层安全通道：

Client ──[Proxy TLS]──▶ Proxy Server ──[Origin TLS]──▶ Origin Server
                             │                                │
                             └── CONNECT 隧道 ────────────────┘

执行流程：

1. 客户端与代理服务器建立 Proxy TLS 连接
2. 通过加密通道发送 CONNECT host:port 请求建立隧道
3. 代理与目标服务器建立 Origin TLS 连接
4. 双层加密隧道建立完成，开始 HTTP 通信

Proxy TLS 与 Origin TLS 是两套完全独立的配置，互不污染。连接池 Key 会区分 proxy endpoint、认证身份和 proxy TLS identity，避免不同配置的 TLS 会话混淆。

新增代理 TLS 配置项（共 18 个）

所有配置方法均通过 HttpProxyBuilder 提供，以 proxy_ 为前缀：

配置方法	功能说明
proxy_tls_config	设置完整的代理 TLS 配置对象
proxy_ca_file	指定验证代理服务器证书的 CA 证书文件路径
proxy_ca_path	指定 OpenSSL hashed CA 目录路径
proxy_add_root_certificate	添加自定义根证书
proxy_client_certificate_file	客户端向代理出示的证书文件（mTLS）
proxy_client_certificate_chain_file	客户端证书链文件
proxy_client_private_key_file	客户端私钥文件
proxy_client_private_key_file_with_password	带密码的客户端私钥文件
proxy_min_tls_version	最低 TLS 版本（如 TLS 1.2）
proxy_max_tls_version	最高 TLS 版本（如 TLS 1.3）
proxy_cipher_list	TLS 1.2 加密算法列表
proxy_cipher_suite	TLS 1.3 加密算法套件
proxy_http1_alpn	启用 HTTP/1.1 ALPN 协商
proxy_alpn_protocols	自定义 ALPN 协议列表
proxy_sni	控制是否发送 SNI 扩展
proxy_verify_hostname	控制是否验证代理主机名
proxy_tls_session_reuse	控制代理 TLS 会话复用
proxy_danger_accept_invalid_certs	跳过代理证书验证（仅测试）

使用示例

use ylong_http_client::HttpProxy;

// 单向验证：验证代理服务器证书
let proxy = HttpProxy::all("https://proxy.example.com:8443")
    .proxy_ca_file("proxy-ca.crt")
    .build()
    .unwrap();

// 双向验证（mTLS）：客户端出示证书
let proxy = HttpProxy::all("https://proxy.example.com:8443")
    .proxy_ca_file("proxy-ca.crt")
    .proxy_client_certificate_file("client.crt", TlsFileType::PEM)
    .proxy_client_private_key_file("client.key", TlsFileType::PEM)
    .build()
    .unwrap();

// 完整企业级配置
let proxy = HttpProxy::all("https://proxy.example.com:8443")
    .proxy_ca_file("enterprise-ca.crt")
    .proxy_client_certificate_chain_file("client-chain.crt")
    .proxy_client_private_key_file("client.key", TlsFileType::PEM)
    .proxy_min_tls_version(TlsVersion::TLS1_2)
    .proxy_cipher_suite("ECDHE-ECDSA-AES256-GCM-SHA384")
    .proxy_alpn_protocols(AlpnProtocolList::from(&["h2", "http/1.1"]))
    .proxy_sni(true)
    .proxy_tls_session_reuse(true)
    .build()
    .unwrap();

差异化错误处理

代理 TLS 错误提供精确的上下文定位，区分两种错误类型：

• proxy_tls_setup_error：TLS 配置加载失败（证书/私钥文件不存在、格式错误等）
• proxy_tls_handshake_error：TLS 握手阶段失败（证书验证失败、算法套件不匹配等）

错误信息包含代理地址、错误原因和完整错误上下文，便于快速排查问题。

独立计时体系

新增 proxy_tls_start / proxy_tls_end 计时点，独立于 origin TLS 计时。配合原有的 TimeGroup 体系，可完整追踪从建立代理连接到完成请求的全链路耗时：

proxy_tls_start → proxy_tls_end → origin_tls_start → origin_tls_end → TTFB

子任务2：代理功能模块化

模块架构

将原有松散的代理逻辑重构为清晰的三层模块架构：

util/proxy/
├── mod.rs          # 管理层：Proxies 容器，统一入口 & 规则匹配
├── route.rs        # 抽象层：ProxyRoute trait + 三种具体路由类型
├── http.rs         # 规则层：HttpProxyRule、Intercept、ProxyInfo
├── tls.rs          # 代理 TLS 配置：ProxyTlsConfig & identity 隔离
├── tunnel.rs       # CONNECT 隧道：请求构建 & 响应解析
└── no_proxy.rs     # 豁免列表：IP/域名匹配

ProxyRoute trait — 核心路由抽象

pub(crate) trait ProxyRoute: Send + Sync {
    fn is_proxied(&self) -> bool;
    fn is_no_proxy(&self) -> bool;
    fn is_tunnel(&self) -> bool;
    fn target(&self) -> Option<&ProxyTarget>;
    fn connect_addr(&self, origin: &Uri) -> String;
    fn prepare_headers(&self, headers: &mut Headers) -> Result<(), HttpClientError>;
    fn request_target_form(&self) -> RequestTargetForm;
}

三种具体路由实现：

路由类型	说明	is_proxied	is_tunnel	使用场景
DirectRoute	直连或 no-proxy 命中	false	false	不需要代理的请求
HttpForwardRoute	HTTP 正向代理转发	true	false	HTTP origin 通过代理
HttpTunnelRoute	HTTPS CONNECT 隧道	true	true	HTTPS origin 通过代理

一次选路，多组件共享

整个请求生命周期中 match_route 只执行一次，路由结果通过 ProxyRouteRef（Arc<dyn ProxyRoute>）在 Client、Pool、Connector 之间共享，消除重复匹配：

Client::match_route(uri) → ProxyRouteRef ──→ PoolKey::from_route()
                                          ──→ ConnectContext
                                          ──→ connector.connect_route()

可扩展性设计

新增代理协议（如 SOCKS5）无需改动 Client、Pool、H1 encoder 等核心组件，只需：

1. 实现 ProxyRoute trait 定义路由行为
2. 在 connector 层增加对应的协议握手逻辑
3. 在 Proxies 中注册新规则

重构对比（以闭合 enum 方案 vs trait 多态方案）：

修改点	重构前（enum）	重构后（trait）
Client	需修改	不变
ConnPool	需修改	不变
H1 encoder	需修改	不变
Connector	需修改多处 match	新增一个函数

显式化 H1 Request Target Form

新增 RequestTargetForm 枚举，显式区分 H1 请求的两种目标形式：

• Origin：GET /path HTTP/1.1（直连和隧道场景）
• Absolute：GET http://origin/path HTTP/1.1（HTTP 代理转发场景）

消除了 H1 encoder 中基于 is_proxy && scheme == HTTP 的隐式推断，提升代码可读性和正确性。

子任务3：性能对比

实验环境与测试设置

被测与对照：

• 被测：ylong_http_client（async，TLS = c_openssl_3_0）
• 对照：OpenSSL libcurl（“–require-libcurl-openssl”gate，同机同构建 profile）
• 驱动：tools/proxy_perf_driver 内置本地拓扑；--mode both 同参数双侧采集

测试拓扑：

driver → Client（ylong / libcurl） → 本地 HTTPS proxy → 本地 origin

正式矩阵参数（Stage121 aligned）：

• 连接模式：warm_client_per_worker（每 worker 常驻 Client，目标 100% 连接复用）
• 并发：c8 / c32 / c128
• 请求：get_1kb
• warmup：不计入 measured wall time
• 主指标：RPS；辅指标：Latency P50 / P99、TTFB；错误率须为 0
• 提升公式：improvement = (ylong_rps - libcurl_rps) / libcurl_rps；正式目标 ≥ +20%

测试场景：

• https-proxy-forward：HTTP origin via HTTPS proxy（Forward*，参考口径）
• https-proxy-connect：HTTPS origin via HTTPS proxy CONNECT（正式矩阵）
• https-proxy-mtls：HTTPS proxy 要求客户端证书（正式矩阵）

口径说明：

• 正式结论仅采用 CONNECT / mTLS 场景的 Stage121 稳定度量结果
• Forward 模式仅作参考，不纳入 +20% 性能提升考核（ylong 连接复用完整而 libcurl 在 HTTP-via-HTTPS-proxy forward 路径不复用）

占优场景总览

• **Forward***（参考口径）：RPS +1025%、P50 -91.6% — 路径优势显著
• 正式矩阵：c32 mTLS RPS +19.4%；c32 CONNECT P99 -46.4%；c8 CONNECT 全链路领先

RPS 优势 — 吞吐量领先 libcurl

场景	ylong RPS	libcurl RPS	提升
c8 Forward*	23,276	2,070	+1025%
c8 CONNECT	25,803	23,205	+11.2%
c8 mTLS	25,381	24,128	+5.2%

为什么 RPS 更高？

• 连接复用：PoolKey 精确区分 proxy / auth / TLS identity，warm 路径 100% 命中
• Worker 对齐：常驻 OS worker + current-thread runtime，消除 per-request spawn
• Forward* 参考：ylong 复用完整，libcurl 在 HTTP-via-HTTPS-proxy forward 路径不复用

P50 优势 — 中位延迟更低（c8）

场景	ylong P50	libcurl P50	ylong 更快
c8 CONNECT	0.273 ms	0.292 ms	-6.5%
c8 mTLS	0.276 ms	0.290 ms	-4.8%

为什么 P50 更低？

• 连接已复用，每请求跳过 proxy TLS + CONNECT + origin TLS 三次握手
• aligned worker 减少 SwitchToThread / ready event，单请求调度开销更低
• 模块化架构零额外开销：一次 match_route + trait 多态直达 connector

P99 优势 — 尾部延迟控制（CONNECT）

场景	ylong P99	libcurl P99	ylong 优势
c8 CONNECT	0.634 ms	0.703 ms	-9.8%
c32 CONNECT	2.128 ms	3.972 ms	-46.4%

为什么 P99 尾部更稳？

• c32 高并发下 ylong P99 2.1 ms vs libcurl 4.0 ms — 相对 libcurl 延迟降低 46.4%
• 连接池 + identity 隔离避免高并发下的错误复连和锁竞争
• Stage122：c8 ready events 已与 libcurl 持平，减少 wake-to-running 尾部抖动
• Profiling 排除 H1 encode/decode 瓶颈，差距在 runtime readiness 而非协议层

优化策略总结

① 连接复用与 Pool 精确命中

• warm_client_per_worker：每 worker 常驻 Client，CONNECT/mTLS 100% connection reuse
• PoolKey 区分 proxy endpoint、Basic auth、proxy TLS identity、mTLS 证书
• 避免 libcurl 侧可能出现的复用不一致（如 forward 场景 0/500 reused）

② Stage121 aligned worker 热路径优化

• 优化前：per-request spawn → c8 CONNECT RPS 落后 libcurl 约 53%
• 优化后：常驻 OS worker + current-thread Tokio → c8 CONNECT RPS +11.2%
• ready events / switch-in 成本下降，c8 已与 libcurl 持平

③ 模块化架构不拖累性能

• util/proxy 抽取后仍是一次 match_route + ProxyRoute trait 多态
• proxy TLS 与 origin TLS 完全分离，pool identity 清晰
• connector 直接消费 ProxyRouteRef，无 HttpProxyExecutor 等过渡 wrapper

性能分析工具链

工具	用途
tools/proxy_perf_driver	本地 topology + ylong/libcurl 双端对照 + r20000 长样本
trigger-elevated-wpr-profile.ps1	计划任务触发 elevated WPR 或 VTune profiling
export-xperf-*.ps1/py	xperf/WPA 导出（ready latency、module、stack、symbol）
analyze-vtune-client-tids.ps1	VTune client OS TID 归因

编译构建

若使用 GN 编译工具链, 在 BUILD.gn 的 deps 段下添加依赖。添加后使用 GN 进行编译和构建：

deps += ["//example_path/ylong_http_client:ylong_http_client"]

若使用 Cargo 编译工具链, 在 Cargo.toml 下添加依赖。添加后使用 cargo 进行编译和构建：

[dependencies]
ylong_http_client = { path = "/example_path/ylong_http_client" } # 请使用路径依赖

Feature 配置

Feature	说明
sync	同步接口
async	异步接口
http1_1	HTTP/1.1 支持
http2	HTTP/2 支持
tokio_base	使用 tokio 运行时
c_openssl_3_0	通过 C-OpenSSL 3.0 FFI 使用 TLS（默认）
c_openssl_1_1	通过 C-OpenSSL 1.1 FFI 使用 TLS
c_boringssl	使用 BoringSSL
__tls	内部标记，开发者专用

常用编译命令：

# 检查异步编译（含 HTTP/1.1 + HTTP/2 + OpenSSL 3.0）
cargo check -p ylong_http_client --features "async http1_1 http2 tokio_base c_openssl_3_0"

# 检查同步编译
cargo check -p ylong_http_client --features "sync http1_1 tokio_base c_openssl_3_0"

测试

SDV 功能验证

# 运行 HTTPS 代理完整 SDV 测试（17 个用例）
cargo test -p ylong_http_client --features "async http1_1 http2 tokio_base c_openssl_3_0" --test sdv_async_https_proxy -- --nocapture

覆盖场景：

• HTTP request via HTTPS proxy forward（H1 / H2）
• HTTPS request via HTTPS proxy CONNECT tunnel（H1 / H2）
• Proxy TLS 单向验证与不安全证书覆盖
• Proxy mTLS 双向证书验证与连接池隔离
• TLS 1.2 cipher list / TLS 1.3 ciphersuite 组合验证
• 企业代理证书链矩阵
• H2 CONNECT backpressure 流控
• Proxy builder 完整 API surface

库级单测

# 代理模块单元测试（路由、no-proxy、auth、pool key）
cargo test -p ylong_http_client --features "async http1_1 http2 tokio_base c_openssl_3_0" --lib proxy -- --nocapture

性能测试

# 编译性能测试驱动
cargo build --release --manifest-path tools/proxy_perf_driver/Cargo.toml --features __tls,libcurl_windows_openssl

# 运行 warm_client_per_worker CONNECT/mTLS 对比
tools/proxy_perf_driver/target/release/proxy_perf_driver.exe --mode both --connection-mode warm_client_per_worker --concurrency 8 --requests 500 --require-libcurl-openssl

目录

ylong_http
├── docs                        # ylong_http 用户指南
├── figures                     # ylong_http 图片资源
├── patches                     # ylong_http 门禁使用的补丁资源
├── tools
│   └── proxy_perf_driver       # （新增）性能测试驱动 & profiling 脚本
├── ylong_http
│   ├── examples                # ylong_http 基础组件库代码示例
│   ├── src                     # ylong_http 基础组件库源码
│   │   ├── body                # Body trait 定义和扩展 Body 类型
│   │   ├── h1                  # HTTP/1.1 相关组件实现
│   │   ├── h2                  # HTTP/2 相关组件实现
│   │   ├── h3                  # HTTP/3 相关组件实现
│   │   ├── huffman             # Huffman 编解码实现
│   │   ├── request             # Request 定义和实现
│   │   └── response            # Response 定义和实现
│   └── tests                   # ylong_http 基础组件库测试目录
│
└── ylong_http_client
    ├── examples                # ylong_http_client 库代码示例
    ├── src                     # ylong_http_client 库源码
    │   ├── async_impl          # ylong_http_client 异步客户端实现
    │   │   ├── conn            # 异步连接层
    │   │   │   └── proxy.rs    # （新增）异步代理 TLS/CONNECT 执行
    │   │   ├── connector       # 连接器
    │   │   │   ├── proxy.rs    # （新增）Proxy TLS 握手 & CONNECT
    │   │   │   └── stream.rs   # Stream 封装
    │   │   ├── downloader      # 异步下载器实现
    │   │   ├── ssl_stream      # 异步 TLS 适配层
    │   │   └── uploader        # 异步上传器实现
    │   ├── sync_impl           # ylong_http_client 同步客户端实现
    │   │   └── conn            # 同步连接层
    │   └── util                # ylong_http_client 组件实现
    │       ├── c_openssl       # OpenSSL 封装层
    │       │   ├── ffi         # ffi 封装层
    │       │   ├── ssl         # SSL 适配层（含 Proxy role 支持）
    │       │   └── adapter.rs  # TlsConfig / TlsConfigBuilder
    │       ├── config          # 配置选项实现
    │       │   ├── settings.rs # （修改）HttpProxyBuilder + 18 个 proxy TLS 方法
    │       │   └── tls         # TLS 选项实现
    │       ├── proxy           # （新增模块）代理路由核心
    │       │   ├── mod.rs      # Proxies 管理器
    │       │   ├── route.rs    # ProxyRoute trait + 三种路由
    │       │   ├── http.rs     # HttpProxyRule 规则定义
    │       │   ├── tls.rs      # ProxyTlsConfig 代理 TLS
    │       │   ├── tunnel.rs   # CONNECT 隧道协议
    │       │   └── no_proxy.rs # NO_PROXY 豁免匹配
    │       └── monitor
    │           └── time_group.rs  # （修改）新增 proxy_tls_start/end 计时
    └── tests                       # ylong_http_client 库测试目录
        ├── sdv_async_https_proxy.rs  # （新增）HTTPS 代理 SDV 17 用例
        └── ...

修改记录

本分支在原始代码基础上做了如下关键修改（共 20 个 curated commit）：

#	Commit	内容概述
1	feat: establish HTTPS proxy foundation	建立 proxy route、target、TLS、CONNECT tunnel 模块和初始 HTTPS proxy wiring
2	test: harden HTTPS proxy baseline coverage	加入 perf driver 初版、pool key 覆盖和 async/sync HTTPS proxy SDV
3	feat: complete proxy TLS and timing controls	完成 proxy/origin timing、错误上下文、mTLS key、TLS1.3 ciphersuite、session reuse
4	tools: build proxy performance harness gates	扩展 perf driver 指标、调度、local topology、OpenSSL libcurl gate
5	test: close proxy verification and DNS boundaries	补齐 proxy CA path、verification boundary、P0 SDV helper
6	feat: modularize async proxy executor and H2 tunnel	抽出 async proxy executor，支持 H2 proxy forward 和 H2 CONNECT tunnel
7	perf: align OpenSSL proxy benchmark baseline	建立 local HTTPS proxy topology、OpenSSL matrix、H2 failure/buffering 测试
8	perf: evaluate H1 warm path candidates	评估 H1 origin-form head、response decode、scratch/timing/interceptor/pool
9	tools: add proxy tracing and elevated WPR harness	H1 timing trace、elevated WPR harness、Tokio worker probe
10	test: close HTTPS proxy follow-up matrix	H2 backpressure、proxy executor route、TLS1.3 cipher、企业证书链矩阵
11	tools: add WPR/xperf and SSL role diagnostics	WPA/xperf exporter、SSL/BIO trace、libcurl trace、TLS role split
12	tools: expand CPU stack profiling exports	no-trace、SSL poll/body read、CPU verbose stack、stack module/symbol export
13	docs: record runtime and readiness boundary analysis	SSL auto-retry、Tokio/threaded worker、ready latency、runtime stack
14	tools: add async worker diagnostics	threaded runtime、request thread ID、async worker loop/prelude/stagger
15	docs: consolidate profiling refresh and scaling matrix	c8/c32 profiling refresh、trace cache rollback、mTLS stack profiling
16	tools: add VTune client thread attribution	first-read SSL counters、elevated VTune、WANT_READ split、client TID analyzer
17	perf: align warm worker benchmark and final profiling evidence	warm_client_per_worker 对齐、TMA、client-TID、CPU.light、runtime/distribution 证据
18	docs: add HTTPS proxy product report	产品报告、10700 真实 endpoint、最终 profiling archive 和 driver tooling 增量
19	docs: map curated proxy history nodes	提交历史映射文档
20	refactor: restructure https proxy routing	Proxy trait 重构、route 类型拆分、H1 request target form 显式化

核心新增文件

文件	说明
ylong_http_client/src/util/proxy/route.rs	ProxyRoute trait + DirectRoute / HttpForwardRoute / HttpTunnelRoute
ylong_http_client/src/util/proxy/tls.rs	ProxyTlsConfig 代理层 TLS 配置
ylong_http_client/src/util/proxy/tunnel.rs	CONNECT 隧道请求构建与响应解析
ylong_http_client/src/util/proxy/http.rs	HttpProxyRule、Intercept 规则定义
ylong_http_client/src/util/proxy/no_proxy.rs	NO_PROXY IP/域名匹配
ylong_http_client/src/util/proxy/mod.rs	Proxies 管理器统一入口
ylong_http_client/src/async_impl/connector/proxy.rs	异步代理 TLS 握手 & CONNECT 执行
ylong_http_client/tests/sdv_async_https_proxy.rs	HTTPS 代理 SDV 测试（17 用例）
tools/proxy_perf_driver/	性能测试驱动 & profiling 脚本集

核心修改文件

文件	修改内容
ylong_http_client/src/util/config/settings.rs	HttpProxyBuilder 新增 18 个 proxy TLS 配置方法；新增 Proxy trait、HttpProxy
ylong_http_client/src/util/monitor/time_group.rs	新增 proxy_tls_start/end 计时点
ylong_http_client/src/async_impl/client.rs	一次 match_route + ConnectContext 传递
ylong_http_client/src/async_impl/pool.rs	PoolKey 区分 proxy/auth/TLS identity
ylong_http_client/src/util/pool.rs	连接池 key 新增 proxy endpoint 维度
ylong_http_client/src/util/c_openssl/ssl/stream.rs	新增 SslTraceRole::Proxy 区分代理与目标 TLS

用户指南

详细内容请见用户指南

许可证

本项目基于 Apache License 2.0 协议开源。