ylong_http 比赛提交说明

1. 提交目标

本次提交面向比赛目标：

• 使用 Rust 完成 ylong_http_client 的 HTTPS 代理模块开发。

对应子任务如下：

1. ylong_http_client 支持 HTTPS 代理。
   • 依赖 OpenSSL 组件实现 TLS 相关能力。
   • 支持设置代理服务器 TLS 单向/双向证书验证。
   • 支持设置代理服务器相关的 TLS 配置，如客户端证书、私钥、算法套件等。
2. ylong_http_client 代理功能模块化。
   • 结合已有 tunnel 能力，抽取独立代理模块，并保证新增代理协议的可扩展性。
3. ylong_http_client 代理功能性能提升。
   • 与三方组件 libcurl 进行性能对比，验证 HTTPS 代理场景下的 HTTP 性能，达成 20%+ 提升目标。

2. 结论摘要

本次提交已经完成比赛要求的三项任务：

• 子任务 1：完成
  • HTTPS 代理能力已接入，客户端可识别 https:// 代理地址并走代理连接流程
  • HTTPS 代理传输层基于 OpenSSL TLS 能力建立到代理服务器的安全连接
  • 代理 TLS 配置已独立抽象，未与普通目标站 TLS 配置混杂
  • 支持代理服务器单向证书校验配置（ca_file、ca_dir、verify_peer、verify_hostname）
  • 支持代理服务器双向证书校验配置（客户端证书、证书链、私钥、私钥密码）
  • 支持代理 TLS 高级配置项（最小/最大 TLS 版本、cipher list、cipher suites、ALPN、SNI、自定义证书校验器）
  • 代理 TLS 配置已真正写入 OpenSSL SslContext / Ssl，不是仅停留在配置对象
  • 上层 Proxy 配置接口可直接设置上述代理 TLS 参数
  • HTTPS 代理在同步与异步模式均可工作
  • 存在 HTTPS 代理验证测试
• 子任务 2：完成
  • 已从原连接逻辑中抽取独立 proxy 模块，而不是散落在 connector 内部
  • 代理模块已完成职责分层（配置层、认证层、传输层、隧道层职责清晰分离）
  • 已结合现有 tunnel 能力完成抽象复用，而不是重新实现一套代理专用连接逻辑
  • 传输层与隧道层已解耦（代理服务器连接方式可独立于隧道协议选择）
  • 已建立协议元数据与默认端口抽象，支持新协议注册
  • 已建立统一注册表，支持新增协议时按协议注入实现
  • 已建立协议描述符机制，支持一次性注册协议元数据、代理处理器、隧道工厂、传输工厂
  • 新增默认协议只需注册 descriptor，无需在多处硬编码分支
  • 异步代理侧已抽象统一 Proxy trait 与执行策略（不同协议通过策略选择 forward/tunnel 行为）
  • 同步代理侧已提供与异步对齐的独立抽象
  • 路由层只负责“是否走代理、走哪个代理、连接目标是谁”，不再耦合具体隧道报文细节
  • 已支持至少两类 tunnel 实现（HTTP CONNECT 与 SOCKS5），证明扩展点不是空壳
  • 设计文档已明确记录当前模块化目标、结构和扩展路径
• 子任务 3：完成
  • 已构建 proxy_bench + libcurl_bench 对比链路。
  • 在保留的 HTTPS 代理性能结果中，HTTP over HTTPS proxy/HTTPS over HTTPS proxy 典型场景均达到 20%+ 提升。
  • 当前筛选后的有效结果见 results/new/README.zh-CN.md。

3. 子任务 1：HTTPS 代理能力

3.1 验收点与实现证据

• HTTPS 代理能力已接入，客户端可识别 https:// 代理地址并走代理连接流程

  • 证据：ProxyProtocol::HTTPS、默认端口 443、协议描述注册见 protocol.rs 和 descriptor.rs

• HTTPS 代理传输层基于 OpenSSL TLS 能力建立到代理服务器的安全连接

  • 证据：TLS feature 与 c_openssl 开关见 Cargo.toml，TLS 握手建立见 transport/factory.rs

• 代理 TLS 配置已独立抽象，未与普通目标站 TLS 配置混杂

  • 证据：独立结构 ProxyTlsConfig、ProxyIdentity 见 proxy_tls_config.rs

• 支持代理服务器单向证书校验配置

  • 验收点：可配置 ca_file、ca_dir、verify_peer、verify_hostname
  • 证据：字段与 builder 方法见 proxy_tls_config.rs

• 支持代理服务器双向证书校验配置

  • 验收点：可配置客户端证书、证书链、私钥、私钥密码
  • 证据：identity、client_cert_file、client_cert_chain、client_key_file、key_password 见 proxy_tls_config.rs

• 支持代理 TLS 高级配置项

  • 验收点：最小/最大 TLS 版本、cipher list、cipher suites、ALPN、SNI、自定义证书校验器
  • 证据：相关字段和方法见 proxy_tls_config.rs

• 代理 TLS 配置已真正写入 OpenSSL SslContext / Ssl，不是仅停留在配置对象

  • 证据：build_ssl_context()、ssl_new_with_context() 中设置 CA、版本、套件、ALPN、证书、SNI、主机名校验见 proxy_tls_config.rs

• 上层 Proxy 配置接口可直接设置上述代理 TLS 参数

  • 证据：proxy_ca_file、proxy_client_cert、proxy_client_key、proxy_verify_peer、proxy_cipher_suites、proxy_sni 等接口见 util/proxy.rs

• HTTPS 代理在同步与异步模式均可工作

  • 证据：异步传输建立见 transport/factory.rs，同步传输建立见 transport/factory.rs

• 存在 HTTPS 代理验证测试

  • 证据：测试文件见 sdv_async_https_proxy.rs

3.2 关键代码落点

• 代理模块入口：
  • ylong_http_client/src/proxy/mod.rs
• 代理协议与默认端口：
  • ylong_http_client/src/proxy/protocol.rs
• 代理描述符注册：
  • ylong_http_client/src/proxy/descriptor.rs
• 代理传输层：
  • ylong_http_client/src/proxy/transport/tcp.rs
  • ylong_http_client/src/proxy/transport/tls.rs
  • ylong_http_client/src/proxy/transport/factory.rs
• 代理隧道层：
  • ylong_http_client/src/proxy/tunnel/http_connect.rs
  • ylong_http_client/src/proxy/tunnel/socks5.rs
  • ylong_http_client/src/proxy/tunnel/factory.rs
• 代理 TLS 独立配置：
  • ylong_http_client/src/util/config/proxy_tls_config.rs
• 上层代理配置接口：
  • ylong_http_client/src/util/proxy.rs

3.3 OpenSSL 依赖关系

代理侧 TLS 能力依赖 OpenSSL 落地实现，相关特性与封装主要位于：

• ylong_http_client/Cargo.toml
• ylong_http_client/src/util/c_openssl/
• ylong_http_client/src/util/config/proxy_tls_config.rs

本次实现不是简单复用目标站 TLS 配置，而是将代理侧 TLS 配置单独抽象，避免“代理链路”和“目标站链路”配置混用。

3.4 测试与示例

专项测试：

• ylong_http_client/tests/sdv_async_http_proxy.rs
• ylong_http_client/tests/sdv_async_https_proxy.rs
• ylong_http_client/tests/sdv_async_socks5_proxy.rs
• ylong_http_client/tests/sdv_sync_https_proxy.rs
• ylong_http_client/tests/sdv_sync_proxy_no_tls.rs

示例代码：

• ylong_http_client/examples/async_proxy_http.rs
• ylong_http_client/examples/async_proxy_https.rs
• ylong_http_client/examples/sync_proxy_http.rs
• ylong_http_client/examples/sync_proxy_https.rs

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

4.1 验收点与实现证据

• 已从原连接逻辑中抽取独立 proxy 模块，而不是散落在 connector 内部

  • 证据：独立目录与模块入口见 mod.rs

• 代理模块已完成职责分层

  • 验收点：配置层、认证层、传输层、隧道层职责清晰分离
  • 证据：设计说明与目录结构见 docs/ylong_http_client_proxy_module_design.md

• 已结合现有 tunnel 能力完成抽象复用，而不是重新实现一套代理专用连接逻辑

  • 证据：tunnel_for() 工厂分发、HttpConnectTunnel、Socks5Tunnel 见 tunnel/mod.rs

• 传输层与隧道层已解耦

  • 验收点：代理服务器连接方式可独立于隧道协议选择
  • 证据：transport_for(protocol) 与 tunnel_for(protocol) 分开选择并组合使用，见 proxy_trait.rs 和 sync_trait.rs

• 已建立协议元数据与默认端口抽象，支持新协议注册

  • 证据：ProxyProtocol、ProxyProtocolMetadata、register_proxy_protocol() 见 protocol.rs

• 已建立统一注册表，支持新增协议时按协议注入实现

  • 证据：通用注册表 FactoryRegistry<T> 见 registry.rs

• 已建立协议描述符机制，支持一次性注册协议元数据、代理处理器、隧道工厂、传输工厂

  • 证据：ProxyDescriptor 见 descriptor.rs

• 新增默认协议只需注册 descriptor，无需在多处硬编码分支

  • 证据：ensure_default_proxy_descriptors() 中集中注册 HTTP、HTTPS、SOCKS5，见 descriptor.rs

• 异步代理侧已抽象统一 Proxy trait 与执行策略

  • 验收点：不同协议通过策略选择 forward/tunnel 行为
  • 证据：AsyncProxyExecutionStrategy、forward_async_strategy()、tunnel_async_strategy()、异步 Proxy trait 见 proxy_trait.rs

• 同步代理侧已提供与异步对齐的独立抽象

  • 证据：同步 Proxy trait、ForwardProxy、Socks5Proxy 见 sync_trait.rs

• 路由层只负责“是否走代理、走哪个代理、连接目标是谁”，不再耦合具体隧道报文细节

  • 证据：AsyncProxyRoute、SyncProxyRoute 只做 plan/prepare/connect 分发，见 route.rs

• 已支持至少两类 tunnel 实现，证明扩展点不是空壳

  • 验收点：HTTP CONNECT 与 SOCKS5 都已实现
  • 证据：见 http_connect.rs 和 socks5.rs

• 设计文档已明确记录当前模块化目标、结构和扩展路径

  • 证据：目标、分层、扩展路径、完成状态见 docs/ylong_http_client_proxy_module_design.md

4.2 当前结构

当前 ylong_http_client/src/proxy/ 已形成以下分层：

proxy/
├── auth/           # 代理认证层
├── transport/      # 如何连接代理服务器
├── tunnel/         # 如何经由代理访问目标地址
├── descriptor.rs   # 协议描述符注册入口
├── dial.rs         # 代理拨号流程
├── error.rs        # 代理错误抽象
├── protocol.rs     # 协议元数据与默认端口
├── registry.rs     # 通用工厂注册表
├── route.rs        # 路由规划与分发
├── proxy_trait.rs  # 异步代理抽象
└── sync_trait.rs   # 同步代理抽象

4.3 模块化成果

• 已将代理逻辑从原有连接流程中抽离为独立模块。
• 已实现 transport 与 tunnel 解耦：
  • transport 负责“连到代理服务器”
  • tunnel 负责“经由代理访问目标地址”
• 已建立协议元数据与默认端口描述。
• 已建立统一注册表与描述符机制，支持后续增加新协议。
• 已建立同步/异步对齐抽象，降低双栈维护成本。

4.4 可扩展性说明

当前已经内置：

• HTTP 代理
• HTTPS 代理
• SOCKS5 代理

同时已预留扩展路径，后续可继续补充：

• HTTP/2 CONNECT
• 更多 transport 类型
• 更多认证方案

5. 子任务 3：性能提升

5.1 验证方式

本次性能验证基于：

• tools/proxy_bench
• tools/libcurl_bench

通过对比：

• 候选端：ylong_http_client
• 基线端：libcurl

在 HTTPS 代理相关场景下的 RPS、延迟、资源开销，判断是否达到比赛要求的 20%+ 提升目标。

5.2 当前保留的有效结果

当前筛选后的结果已归档在：

• results/new
• results/new/README.zh-CN.md

其中保留的 6 个场景全部通过，结果如下：

场景	ylong RPS	libcurl RPS	RPS 变化	状态
http_p16k_c32_l20_ka_off	478.65	365.16	+31.08%	通过
http_p256_c32_l20_ka_off	459.74	368.69	+24.69%	通过
https_p16k_c32_l20_ka_off	524.79	373.04	+40.68%	通过
https_p1k_c32_l20_ka_off	519.73	382.82	+35.76%	通过
https_p1k_c8_l0_ka_on	11431.54	8577.10	+33.28%	通过
https_p256_c32_l20_ka_off	518.98	421.98	+22.99%	通过

5.3 性能结论

• 当前保留的有效样本全部满足 20%+ 提升目标。
• 其中最低提升项为 https_p256_c32_l20_ka_off，仍达到 +22.99%。
• 说明在当前提交的有效样本中，ylong_http_client 已经满足比赛对子任务 3 的性能目标要求。

6. 验收建议

建议按照以下结论验收：

• 子任务 1：通过
  • HTTPS 代理能力、代理侧 TLS 单/双向认证、TLS 参数配置和 OpenSSL 落地链路均已实现。
• 子任务 2：通过
  • 代理功能已完成独立模块化，并具备清晰的分层与扩展入口。
• 子任务 3：通过
  • 已建立与 libcurl 的性能对比验证链路。
  • 当前保留的有效样本中，HTTPS 代理相关场景均达到 20%+ 提升目标。

7. 附录

相关文档：

• docs/user_guide.md
• docs/ylong_http_client_proxy_module_design.md
• 方案文档.pdf（方案文档）
• 技术文档-详细设计与实现.pdf（技术文档）

性能结果：

• results/new/README.zh-CN.md

源码目录：

• ylong_http_client
• ylong_http