赛题解读 | 南京大学&开放原子* CCF开源创新大赛,近6w激励金,ylong_http期待你的贡献!

一、赛题速览卡

二、赛题激励

三、这道题，我们为什么要出？

（背景解读）

ylong_http 是用 Rust 编写的高性能模块化 HTTP 库，为系统服务层网络协议栈提供 HTTP 协议支持。当前已构建完整的 HTTP/1.1 和 HTTP/2 协议能力，支持同步与异步双模式 API，覆盖 TLS 安全传输（OpenSSL FFI）、连接池管理、DNS 解析及拦截器扩展机制。

然而，ylong_http 在 HTTP 代理功能上存在明确缺失：当前仅支持基础 HTTP 代理和 CONNECT 隧道，对于企业环境中广泛使用的 HTTPS 代理（客户端与代理服务器之间启用 TLS 加密），尚未提供完整支持。在企业内网穿透、防火墙穿越等场景中，这一能力缺口直接限制了 ylong_http 的可用性。

随着零信任安全架构的普及，HTTPS 代理已从"可选增强"变为"基础设施刚需"。一个现代化的 HTTP 客户端库若缺少 HTTPS 代理支持，将难以满足企业级部署需求。同时，Rust 凭借其内存安全和零成本抽象特性，正在系统编程领域快速崛起，OpenHarmony 生态选择 Rust 构建核心网络库也正是这一趋势的体现。

我们希望通过这道赛题，让参赛者具体解决 ylong_http HTTPS 代理能力缺失的问题，并在这个过程中深入理解 HTTP CONNECT 隧道、TLS 握手协议、OpenSSL FFI 封装等核心技术，同时锻炼在大型 Rust 代码库中进行模块化架构设计的能力。优胜方案有望通过 PR 合入 ylong_http 社区主线，直接服务于 OpenHarmony 生态建设。

四、任务拆解：你到底要做什么？

基础目标

实现 ylong_http 客户端的 HTTPS 代理功能。具体包括：依赖 OpenSSL 实现 TLS 能力（基于 c_openssl FFI 层扩展，复用 AsyncSslStream，支持 ALPN 协商）；支持代理服务器的 TLS 单向证书验证；支持代理服务器的 TLS 双向证书验证（mTLS）；提供完整的 TLS 配置能力（客户端证书路径、私钥路径、算法套件、TLS 版本范围、ALPN 协议列表配置）。

进阶挑战

在实现基础功能的前提下，对代理功能进行模块化重构：结合已有的 CONNECT 隧道代理能力进行重构扩展；将代理逻辑从 HttpConnector 中分离，抽取为独立的代理模块；设计 Proxy trait 统一接口，保证新代理协议的可扩展性。

终极挑战

在模块化架构基础上进行性能优化，与 libcurl 进行公平对比测试。覆盖不同并发度、不同 Payload 大小、不同网络延迟的综合场景，核心指标包括吞吐量（RPS）、延迟（Latency）、P99 分位值。目标：HTTPS 代理场景下 HTTP 性能较 libcurl 提升 20%+。

例外内容

由于当前仓库部分功能还在持续开发中，不要求对http3、sync两个feature进行适配。不影响原有功能接口即可。

五、解题思路点拨

克隆仓库，配置环境变量并构建：

git clone https://github.com/openharmony/commonlibrary_rust_ylong_http

cd commonlibrary_rust_ylong_http

export OPENSSL_LIB_DIR=/[openssl路径]

cargo build -p ylong_http_client --features "async,http1_1,tokio_base,tls_default"cargo build -p ylong_http_client --features "async,http1_1,http2,ylong_base,tls_default"

运行测试确认环境正常：

cargo test -p ylong_http_client --features "async,http1_1,http2,ylong_base,tls_default"

按以下顺序阅读核心代码，重点关注 connector/mod.rs 中的代理连接建立逻辑：

async_impl/client.rs — Client 入口与配置

● async_impl/pool.rs — 连接池复用机制

● async_impl/connector/mod.rs — 连接器核心（赛题主要修改区域）

● util/dispatcher.rs — 协议分发逻辑

先通读 connector/mod.rs 中现有的 HTTP 代理和 CONNECT 隧道实现，理解代理连接是如何建立的。在此基础上，增加一个 TLS 握手分支：当检测到代理配置为 HTTPS 时，先与代理服务器建立 TLS 连接，再在其上发起 CONNECT 请求。这条路线风险最低，能让你快速看到成果。（思路仅供参考，不一定最优）

如果你熟悉设计模式，可以优先进行模块化设计。定义 Proxy trait，将地址解析、连接建立、请求转发封装为标准接口。让 HttpConnector 通过 trait 对象统一调用代理逻辑，实现代理模块与连接器的解耦。HttpProxy、HttpsProxy 分别实现该 trait，后续扩展 SOCKS5 也会非常自然。（思路仅供参考，不一定最优）

直接挑战性能目标。在实现基础功能时就考虑优化点：TLS 会话恢复（Session ID / Ticket）减少握手开销、连接复用策略优化、零拷贝数据传输等。建议先搭建 criterion benchmark 框架，每做一个优化都量化其收益。（思路仅供参考，不一定最优）

六、评审标准深度解读：怎么样能拿高分？

七、资源与支持：你不是一个人在战斗

八、常见疑问集中解答（FAQ）

九、写在最后