curl 的 HTTP/3QUIC支持完全指南从源码构建、命令行使用到本地测试环境搭建【免费下载链接】curlA command line tool and library for transferring data with URL syntax, supporting DICT, FILE, FTP, FTPS, GOPHER, GOPHERS, HTTP, HTTPS, IMAP, IMAPS, LDAP, LDAPS, MQTT, MQTTS, POP3, POP3S, RTSP, SCP, SFTP, SMB, SMBS, SMTP, SMTPS, TELNET, TFTP, WS and WSS. libcurl offers a myriad of powerful features项目地址: https://gitcode.com/GitHub_Trending/cu/curl本指南以 curl 官方文档 docs/HTTP3.md 为骨架讲解如何在 curl 中启用并验证基于 QUIC 协议的 HTTP/3 能力。文章将带你走通两条主线一是分别借助ngtcp2 nghttp3搭配 OpenSSL 系、GnuTLS 或 wolfSSL 三种 TLS 后端以及quicheCloudflare实验性从源码构建支持 HTTP/3 的 curl二是掌握--http3、--http3-only、--alt-svc等命令行开关的行为差异包括 HTTPS eyeballing 回退策略并利用 nghttpx、Caddy 搭建本地 HTTP/3 反向代理进行联调与验证。读完本文你可以独立完成构建一个自带 HTTP/3 的 curl并对其内部 QUIC 库选型、TLS 适配与连接过滤器架构形成清晰的认知。HTTP/3 与 curl 的关系概述HTTP/3 是建立在 QUIC 传输协议之上的 HTTP 版本它不再使用 TCP而是运行在 UDP 之上并把 TLS 1.3 握手内嵌进 QUIC 的握手过程。对 curl 这样用 URL 语法传输数据的命令行工具与 libcurl 库来说支持 HTTP/3 意味着两件事传输层换成 QUICUDP 数据报收发、连接迁移、0-RTT/1-RTT 握手等都由底层的 QUIC 库完成HTTP 语义层换成 HTTP/3帧封装、头部压缩QPACK、流控等由 nghttp3 或 quiche 提供。从 lib/vquic 目录的源码结构可以清晰看到这一分层。curl 并没有自己实现 QUIC 协议栈而是定义了统一的连接过滤器接口把不同 QUIC 库作为后端插拔进来cf-ngtcp2.c、cf-ngtcp2-cmn.c —— ngtcp2 后端的 HTTP/3 连接过滤器实现其中Curl_cft_http3见 cf-ngtcp2.c是暴露给上层连接系统使用的过滤器类型cf-quiche.c —— quiche 后端的实现整体文件处于USE_QUICHE宏保护下vquic-tls.c —— 把 TLS 库OpenSSL/BoringSSL/GnuTLS/wolfSSL 等的握手回调桥接到 QUIC 库的公共 TLS 适配层vquic.c —— QUIC 后端的公共入口UDP socket 管理、数据收发、通用流程。这些源码都编译进USE_HTTP3宏保护的范围中参见 vquic.c。在 configure 阶段是否定义USE_NGTCP2/USE_QUICHE/USE_NGHTTP3直接决定最终产物里启用哪条 QUIC 路径。官方推荐的外部资源在深入构建之前curl 官方在 docs/HTTP3.md 中推荐了两份背景资料HTTP/3 Explained由 curl 作者 Daniel Stenberg 撰写的在线免费书籍系统讲解 QUIC 与 HTTP/3 涉及的协议演进、动机与技术细节quicwg.orgQUIC 与 HTTP/3 官方协议草案的所在地是查阅 RFC 演进如从 IETF draft 到 RFC 9000 / RFC 9114的第一手资料。curl 使用的 QUIC 库curl 在 docs/HTTP3.md 中明确列出了当前正在使用的 QUIC 实现QUIC 库提供方curl 中的状态ngtcp2ngtcp2 项目配套 nghttp3 实现 HTTP/3 层非实验性官方主推quicheCloudflareEXPERIMENTAL实验性需要特别强调状态差异只有 ngtcp2 后端的 HTTP/3 支持被 curl 官方视为非实验性使用 quiche 的 HTTP/3 支持直到进一步通知前都处于EXPERIMENTAL标记之下。curl 官方在 docs/HTTP3.md 中还给出了移除实验性标记的前提条件To fix before we remove the experimental label所依赖的 QUIC 库自身需要从 beta 阶段毕业不再自称 beta允许保留个别后端为实验性也就是说即使 quiche 仍带实验标签ngtcp2 后端也可以先被转正。HTTP/3 功能的后续开发与调优都发生在 curl master 分支以普通 pull-request 的形式演进与其它功能开发流程无异。从源码看后端选型从编译期宏可以反推出选型逻辑。autotools 构建体系在 configure.ac 中通过--with-ngtcp2、--with-nghttp3、--with-quiche等参数来启用对应后端并据此定义USE_NGTCP2、USE_QUICHE等宏CMake 构建体系则对应提供USE_NGTCP2、USE_QUICHE、USE_NGHTTP3三个开关见 CMakeLists.txt并在链接期通过 CMake/FindNGTCP2.cmake、CMake/FindNGHTTP3.cmake、CMake/FindQuiche.cmake 寻找依赖。构建完成后curl --version输出的特性列表会列出HTTP3字样CMake 侧由 CMakeLists.txt 的curl_add_if(HTTP3 USE_NGTCP2 OR USE_QUICHE)决定。使用 ngtcp2 构建 curl含三种 TLS 组合构建 ngtcp2 版 curl 需要3 个组件ngtcp2 本身、nghttp3以及一个支持 QUIC 的 TLS 库。文档 docs/HTTP3.md 覆盖的 TLS 组合有OpenSSL 及其 forkOpenSSL v3.5.0、quictls、BoringSSL、AWS-LC、LibreSSLGnuTLSwolfSSL。版本提示任何 v1.0.0 起的 ngtcp2 与 nghttp3 版本都被预期可工作但使用最新版本通常会带来功能与性能改进。另外OpenSSL v3.5.0 要求 ngtcp2 v1.12.0 以上更早的 ngtcp2 无法搭配新 OpenSSL 使用。通用前提依赖的构建顺序无论选哪种 TLS 后端都必须先依次构建好三层依赖再构建 curl。下面以 OpenSSL 组合为例给出完整命令文中用$NGHTTP3_VERSION、$NGTCP2_VERSION作为你要构建的版本号占位符/path/to/...请替换为你的实际安装前缀。组合一OpenSSL v3.5.0或 quictls / BoringSSL / AWS-LC / LibreSSL第 1 步构建 OpenSSL v3.5.0或 forkgit clone --depth 1 --branch openssl-$OPENSSL_VERSION https://github.com/openssl/openssl cd openssl ./config --prefix/path/to/openssl --libdirlib make make install第 2 步构建 nghttp3cd .. git clone --depth 1 --branch $NGHTTP3_VERSION https://github.com/ngtcp2/nghttp3 cd nghttp3 git submodule update --init autoreconf -fi ./configure --prefix/path/to/nghttp3 --enable-lib-only make make install--enable-lib-only表示只构建库本身不构建其附带的示例程序。第 3 步构建 ngtcp2cd .. git clone --depth 1 --branch $NGTCP2_VERSION https://github.com/ngtcp2/ngtcp2 cd ngtcp2 autoreconf -fi # 若使用 AWS-LC 或 BoringSSL把 --with-openssl 换成 --with-boringssl ./configure PKG_CONFIG_PATH/path/to/openssl/lib/pkgconfig:/path/to/nghttp3/lib/pkgconfig LDFLAGS-Wl,-rpath,/path/to/openssl/lib \ --prefix/path/to/ngtcp2 --enable-lib-only --with-openssl make make install这里通过PKG_CONFIG_PATH把 OpenSSL 与 nghttp3 的.pc文件暴露给 configure用--with-openssl声明 QUIC 的 TLS 加密后端来自 OpenSSL。第 4a 步用 autotools 构建 curlcd .. git clone --depth 1 https://github.com/curl/curl cd curl autoreconf -fi ./configure PKG_CONFIG_PATH/path/to/openssl/lib/pkgconfig LDFLAGS-Wl,-rpath,/path/to/openssl/lib \ --with-openssl/path/to/openssl --with-ngtcp2/path/to/ngtcp2 --with-nghttp3/path/to/nghttp3 make make install第 4b 步用 CMake 构建 curlcd .. git clone --depth 1 https://github.com/curl/curl cd curl PKG_CONFIG_PATH/path/to/openssl/lib/pkgconfig:/path/to/ngtcp2/lib/pkgconfig:/path/to/nghttp3/lib/pkgconfig cmake -B bld \ -DOPENSSL_ROOT_DIR/path/to/openssl -DUSE_NGTCP2ON cmake --build bldCMake 路径只需显式开启-DUSE_NGTCP2ONnghttp3 与 TLS 的探测会自动完成相关逻辑见 CMakeLists.txt。注意若选用 ngtcp2 v1.12.0CMake 会自动按 openssl/quictls/BoringSSL/wolfSSL 等组件做匹配CMakeLists.txt 还会做 ngtcp2 ≥ 1.12.0 的版本校验。组合二GnuTLS第 1 步构建 GnuTLSgit clone --depth 1 https://gitlab.com/gnutls/gnutls cd gnutls ./bootstrap ./configure --prefix/path/to/gnutls make make install第 2 步构建 nghttp3与 OpenSSL 组合相同cd .. git clone --depth 1 --branch $NGHTTP3_VERSION https://github.com/ngtcp2/nghttp3 cd nghttp3 git submodule update --init autoreconf -fi ./configure --prefix/path/to/nghttp3 --enable-lib-only make make install第 3 步构建 ngtcp2TLS 后端切换为 GnuTLScd .. git clone --depth 1 --branch $NGTCP2_VERSION https://github.com/ngtcp2/ngtcp2 cd ngtcp2 autoreconf -fi ./configure PKG_CONFIG_PATH/path/to/gnutls/lib/pkgconfig:/path/to/nghttp3/lib/pkgconfig LDFLAGS-Wl,-rpath,/path/to/gnutls/lib \ --prefix/path/to/ngtcp2 --enable-lib-only --with-gnutls make make install第 4a 步autotools 构建 curlcd .. git clone --depth 1 https://github.com/curl/curl cd curl autoreconf -fi ./configure PKG_CONFIG_PATH/path/to/gnutls/lib/pkgconfig --with-gnutls/path/to/gnutls --with-ngtcp2/path/to/ngtcp2 --with-nghttp3/path/to/nghttp3 make make install第 4b 步CMake 构建 curlcd .. git clone --depth 1 https://github.com/curl/curl cd curl PKG_CONFIG_PATH/path/to/gnutls/lib/pkgconfig:/path/to/ngtcp2/lib/pkgconfig:/path/to/nghttp3/lib/pkgconfig cmake -B bld -DCURL_USE_GNUTLSON -DUSE_NGTCP2ON cmake --build bld组合三wolfSSL第 1 步构建 wolfSSL需显式开启 QUIC 相关能力git clone --depth 1 https://github.com/wolfSSL/wolfssl cd wolfssl autoreconf -fi ./configure --prefix/path/to/wolfssl --enable-quic --enable-session-ticket --enable-earlydata --enable-psk --enable-harden --enable-altcertchains make make installQUIC 依赖 session ticket会话恢复、early data0-RTT、PSK预共享密钥与 altcertchains 等能力所以上述 configure 开关缺一不可。第 2 步构建 nghttp3同上cd .. git clone --depth 1 --branch $NGHTTP3_VERSION https://github.com/ngtcp2/nghttp3 cd nghttp3 git submodule update --init autoreconf -fi ./configure --prefix/path/to/nghttp3 --enable-lib-only make make install第 3 步构建 ngtcp2TLS 后端切换为 wolfSSLcd .. git clone --depth 1 --branch $NGTCP2_VERSION https://github.com/ngtcp2/ngtcp2 cd ngtcp2 autoreconf -fi ./configure PKG_CONFIG_PATH/path/to/wolfssl/lib/pkgconfig:/path/to/nghttp3/lib/pkgconfig LDFLAGS-Wl,-rpath,/path/to/wolfssl/lib \ --prefix/path/to/ngtcp2 --enable-lib-only --with-wolfssl make make install第 4a 步autotools 构建 curlcd .. git clone --depth 1 https://github.com/curl/curl cd curl autoreconf -fi ./configure PKG_CONFIG_PATH/path/to/wolfssl/lib/pkgconfig --with-wolfssl/path/to/wolfssl --with-ngtcp2/path/to/ngtcp2 --with-nghttp3/path/to/nghttp3 make make install第 4b 步CMake 构建 curlcd .. git clone --depth 1 https://github.com/curl/curl cd curl PKG_CONFIG_PATH/path/to/wolfssl/lib/pkgconfig:/path/to/ngtcp2/lib/pkgconfig:/path/to/nghttp3/lib/pkgconfig cmake -B bld -DCURL_USE_WOLFSSLON -DUSE_NGTCP2ON cmake --build bldCMake 侧-DCURL_USE_WOLFSSLON对应 CMakeLists.txt 的开关它与-DUSE_NGTCP2ON组合时FindNGTCP2.cmake 会按wolfSSL组件探测 QUIC 加密后端见 CMakeLists.txt。三种组合的差异速览组合curl configure 关键开关ngtcp2 的 TLS 开关CMake 关键选项OpenSSL 及 fork--with-openssl...--with-ngtcp2...--with-nghttp3...--with-opensslBoringSSL/AWS-LC 用--with-boringssl-DOPENSSL_ROOT_DIR... -DUSE_NGTCP2ONGnuTLS--with-gnutls...--with-ngtcp2...--with-nghttp3...--with-gnutls-DCURL_USE_GNUTLSON -DUSE_NGTCP2ONwolfSSL--with-wolfssl...--with-ngtcp2...--with-nghttp3...--with-wolfssl-DCURL_USE_WOLFSSLON -DUSE_NGTCP2ON使用 quiche 构建 curl实验性quiche 是 Cloudflare 用 Rust 实现的 QUIC 库curl 官方在 docs/HTTP3.md 明确标注其支持为EXPERIMENTAL。由于 quiche 的构建会自己管理依赖curl 可以直接针对其最新版本构建虽然大概率可以针对 quiche 的 main 分支构建但官方建议遇到问题时优先使用 quiche 的最新 release tag。quiche 依赖 BoringSSLquiche 构建时会自行编译一份因此下面的流程先把 BoringSSL 从 quiche 的构建产物中导出给 curl 使用。以下以 quiche v0.29.1 为例BoringSSL 所在位置会随版本变化。构建 quiche 并导出 BoringSSLgit clone --depth 1 --branch 0.29.1 --recursive https://github.com/cloudflare/quiche cd quiche cargo build --package quiche --release --features ffi,pkg-config-meta,qlog ln -s libquiche.so target/release/libquiche.so.0 mkdir -p boringssl/lib find target/release \( -name libcrypto.a -o -name libssl.a \) -exec ln -vnf -- {} boringssl/lib \; find target/release/build/boring-sys-*/out/boringssl/src -maxdepth 1 \( -name include \) -exec ln -vsf -- ../{} boringssl \;要点说明--features ffi,pkg-config-meta,qlogffi导出 C 接口curl 依赖pkg-config-meta生成.pc文件qlog开启 QUIC 连接日志能力第一组find把构建产物里的静态库libcrypto.a、libssl.a链接进boringssl/lib第二组find把 BoringSSL 的头文件目录链接进boringssl/include通过软链../include指向实际 src 内的 include 目录。构建 curlautotoolscd .. git clone --depth 1 https://github.com/curl/curl cd curl autoreconf -fi ./configure --with-openssl$PWD/../quiche/boringssl --with-quiche$PWD/../quiche/target/release make make installquiche 后端在源码中以 cf-quiche.c 为核心整个文件处于USE_QUICHE宏保护之下cf-quiche.c并直接使用 OpenSSL/BoringSSL 的头文件与 SSL 接口cf-quiche.c这正是 configure 需要同时给出 BoringSSL 位置的原因。若make install报Permission denied在命令前加sudo即可。命令行使用 HTTP/3构建完成后通过以下三种方式让 curl 走 HTTP/3。只用 HTTP/3--http3-onlycurl --http3-only https://example.org:4433/强制使用 HTTP/3不提供任何回退。若 QUIC 连接建立失败curl 直接报错不会自行尝试其它 HTTP 版本。该选项仅对 HTTPS URL 有效对http://URL 会直接触发错误。此选项要求构建时带 HTTP/3 支持Requires: HTTP/3且与--http1.1、--http1.0、--http2、--http2-prior-knowledge、--http3互斥Mutexed详见 docs/cmdline-opts/http3-only.md该选项自 7.88.0 起可用。HTTP/3 优先并可回退--http3curl --http3 https://example.org:4433/尝试 HTTP/3但在连接足够快地失败时回退到更早的 HTTP 版本。具体回退机制参见下文HTTPS eyeballing。该选项允许你在已知/怀疑目标主机与端口支持 HTTP/3、又不想依赖 Alt-Svc 升级路径时使用见 docs/cmdline-opts/http3.md自 7.66.0 起可用。注意curl不能通过任何代理使用 HTTP/3。这意味着需要 HTTP/3 直连目标服务器。通过 Alt-Svc 升级到 HTTP/3--alt-svccurl --alt-svc altsvc.cache https://curl.se/启用 Alt-Svc 解析与缓存若指定的文件已存在则加载其中缓存的alt-svc记录一次传输完成后若缓存有变更会写回该文件。指定空文件名可在内存中处理缓存而不落盘若多次使用--alt-svccurl 会从所有指定文件加载记录但只用最后一个文件做保存。详见 docs/cmdline-opts/alt-svc.md自 7.64.1 起可用。想要验证以上命令效果可以对照社区维护的公共 HTTP/3 服务器清单挑选支持 HTTP/3 的目标站点进行测试。HTTPS eyeballingHTTP/3 的回退策略细节--http3的回退机制与 IPv4/IPv6 双栈的Happy Eyeballs策略异曲同工HTTP/3 连接失败得足够快时curl 会并行尝试早期 HTTP 版本。文档 docs/HTTP3.md 详细描述了这套时序机制。IPv4/6 eyeballing 的默认间隔是200ms可通过--happy-eyeballs-timeout-ms value覆盖默认值 200ms见 docs/cmdline-opts/happy-eyeballs-timeout-ms.mdRFC 6555 建议 150–250ms。由于 HTTP/3 仍较新curl 决定把这个超时也复用于 HTTP eyeballing并加了一个小变化Hard timeout硬超时即--happy-eyeballs-timeout-ms设定的值。超过该时间后curl 会额外开启一条 TLS 连接去协商 HTTP/2 或 HTTP/1.1Soft timeout软超时目前为硬超时的一半。触发条件是在 HTTP/3 连接上完全没有看到来自服务器的任何数据。不指定任何值时硬超时 200ms软超时 100ms。由此可以得到四种典型走向场景行为理想情况整个 QUIC 握手在 100ms 内完成curl 直接拿到 HTTP/3 连接QUIC 不受支持或该网络路径上 UDP 不通收不到任何应答100ms 后启动 HTTP/2 的 TLSTCP 连接最坏情况UDP 应答在 100ms 前开始到达、却迟迟不完成200ms 后启动 TLSTCP 连接QUIC 握手失败立即尝试 TLSTCP。例如 QUIC 服务器出示了错误证书时只有当QUIC 与 TLSTCP 两条路径都握手失败或超时整个传输才会失败。需要注意以上全部过程都叠加在 IP 版本 eyeballing 之上如果服务器域名解析出多个 IPcurl 会逐一尝试直至成功与其它协议一致若同时含 IPv6 与 IPv4这些尝试会延迟后并行进行——这才是真正的 eyeballing。已知问题Known BugsHTTP/3 在 curl 中仍属较新能力官方维护了一份持续更新的 HTTP/3 已知缺陷清单对应 docs/HTTP3.md 中的相关链接亦可在 curl 官方 knownbugs 页面按 HTTP3 分类查看。在深入使用或给 curl 提交 HTTP/3 相关 issue 之前建议先核对清单避免重复报告已知问题。搭建本地 HTTP/3 测试服务器官方在 docs/HTTP3.md 中提供了在本机搭建 HTTP/3 反向代理做开发与试验的完整指引明确说明这不是生产部署建议。推荐拓扑是一个现成的本地 HTTP/1.1 服务器 一个 HTTP/3 反向代理客户端经 QUIC 访问代理、代理再以 HTTP/1.1 回源。前置条件一个已存在的、负责托管文件的本地 HTTP/1.1 服务器。最好准备一些大文件例如用稀疏文件快速造一个超大文件truncate -s8G 8GB这个 8GB 文件是稀疏的大洞不占多少实际磁盘空间。Debian 系可直接安装 apache2它监听 80 端口文档根目录为/var/www/html随后验证回源下载curl localhost/8GB -o dev/null下面分别给出 nghttpx 与 Caddy 两种反向代理方案可任选其一或两者都用。方案 Anghttpxnghttp2 项目自带代理先按前文步骤构建并安装 quictls、nghttp3、ngtcp2再构建 nghttp2注意要用--enable-http3开启其 HTTP/3 前端能力git clone --depth 1 https://github.com/nghttp2/nghttp2 cd nghttp2 autoreconf -fi PKG_CONFIG_PATH$PKG_CONFIG_PATH:/path/to/quictls/lib/pkgconfig:/path/to/nghttp3/lib/pkgconfig:/path/to/ngtcp2/lib/pkgconfig \ LDFLAGS-L/path/to/quictls/lib CFLAGS-I/path/to/quictls/include ./configure --enable-maintainer-mode \ --prefix/path/to/nghttp2 --disable-shared --enable-app --enable-http3 --without-jemalloc --without-libxml2 --without-systemd make make install随后在9443端口启动本地 HTTP/3 服务把所有流量反代到 localhost 的 80 端口 HTTP/1.1 服务器。本地试验可以直接复用 curl 测试目录里现成的测试证书CERT/path/to/stunnel.pem $HOME/bin/nghttpx $CERT $CERT --backendlocalhost,80 \ --frontendlocalhost,9443;quicnghttpx第一个参数是服务器证书、第二个是私钥文件--frontendlocalhost,9443;quic表示该前端监听 QUICUDP即对外提供 HTTP/3。方案 BCaddy安装 Caddy 后建议把二进制放入 PATH 或当前目录创建一个Caddyfilelocalhost:7443 { respond Hello, world! you are using {http.request.proto} }启动 Caddy./caddy start此时访问https://localhost:7443应答内容里的{http.request.proto}会告诉你实际使用的协议版本——如果浏览器/客户端协商成功你会看到HTTP/3.0。需要更贴近真实场景时把respond替换为reverse_proxy或file_server例如reverse_proxy localhost:80即可把 Caddy 变成一个 HTTP/3 反向代理回源到本地 HTTP/1.1 服务器。与仓库测试体系对应curl 自带测试套件已包含多组 HTTP/3 用例可作为你本地验证的参考实现。例如tests/data/test2501标记http/3feature 与http/3服务端执行curl --insecure --http3 ... -d moo的 HTTP/3 POST并校验返回HTTP/3 201与via: 1.1 nghttpx——可见测试服务器正是 nghttpxtests/data/test2500--http3--resolve localhost:%HTTP3PORT的 HTTP/3 GETtests/data/test2503--http3-only结合 header-api 输出%{header_json}的用例。这些用例的features段如 tests/data/test2501 的Debug http http/3说明只有构建出带 HTTP/3 的 curl跑测试时才会选中http/3feature。因此在你按本文构建完成后可以进入仓库 tests 目录运行类似runtests.pl 2501的命令来快速验证本机 HTTP/3 是否真正可用。小结回顾整条路径curl 的 HTTP/3 能力不是单一实现而是围绕 ngtcp2/nghttp3 与 quiche 两套 QUIC 栈、经由USE_NGTCP2/USE_QUICHE等宏在 lib/vquic 目录里完成的连接过滤器接入TLS 侧则可选择 OpenSSL 系、GnuTLS 或 wolfSSL。构建时按依赖 → nghttp3 → ngtcp2 → curl的顺序执行autotools 与 CMake 都有对等选项。使用侧则由--http3-only严格、--http3带回退配合 200ms/100ms 双层 eyeballing 时序与--alt-svc服务端通告式升级三种入口控制。最后nghttpx 或 Caddy 可以作为本地 HTTP/3 反向代理与仓库中的 HTTP/3 测试用例配合快速验证整条链路的正确性。【免费下载链接】curlA command line tool and library for transferring data with URL syntax, supporting DICT, FILE, FTP, FTPS, GOPHER, GOPHERS, HTTP, HTTPS, IMAP, IMAPS, LDAP, LDAPS, MQTT, MQTTS, POP3, POP3S, RTSP, SCP, SFTP, SMB, SMBS, SMTP, SMTPS, TELNET, TFTP, WS and WSS. libcurl offers a myriad of powerful features项目地址: https://gitcode.com/GitHub_Trending/cu/curl创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 curl 的 HTTP/3（QUIC）支持完全指南：从源码构建、命令行使用到本地测试环境搭建
curl 的 HTTP/3QUIC支持完全指南从源码构建、命令行使用到本地测试环境搭建【免费下载链接】curlA command line tool and library for transferring data with URL syntax, supporting DICT, FILE, FTP, FTPS, GOPHER, GOPHERS, HTTP, HTTPS, IMAP, IMAPS, LDAP, LDAPS, MQTT, MQTTS, POP3, POP3S, RTSP, SCP, SFTP, SMB, SMBS, SMTP, SMTPS, TELNET, TFTP, WS and WSS. libcurl offers a myriad of powerful features项目地址: https://gitcode.com/GitHub_Trending/cu/curl本指南以 curl 官方文档 docs/HTTP3.md 为骨架讲解如何在 curl 中启用并验证基于 QUIC 协议的 HTTP/3 能力。文章将带你走通两条主线一是分别借助ngtcp2 nghttp3搭配 OpenSSL 系、GnuTLS 或 wolfSSL 三种 TLS 后端以及quicheCloudflare实验性从源码构建支持 HTTP/3 的 curl二是掌握--http3、--http3-only、--alt-svc等命令行开关的行为差异包括 HTTPS eyeballing 回退策略并利用 nghttpx、Caddy 搭建本地 HTTP/3 反向代理进行联调与验证。读完本文你可以独立完成构建一个自带 HTTP/3 的 curl并对其内部 QUIC 库选型、TLS 适配与连接过滤器架构形成清晰的认知。HTTP/3 与 curl 的关系概述HTTP/3 是建立在 QUIC 传输协议之上的 HTTP 版本它不再使用 TCP而是运行在 UDP 之上并把 TLS 1.3 握手内嵌进 QUIC 的握手过程。对 curl 这样用 URL 语法传输数据的命令行工具与 libcurl 库来说支持 HTTP/3 意味着两件事传输层换成 QUICUDP 数据报收发、连接迁移、0-RTT/1-RTT 握手等都由底层的 QUIC 库完成HTTP 语义层换成 HTTP/3帧封装、头部压缩QPACK、流控等由 nghttp3 或 quiche 提供。从 lib/vquic 目录的源码结构可以清晰看到这一分层。curl 并没有自己实现 QUIC 协议栈而是定义了统一的连接过滤器接口把不同 QUIC 库作为后端插拔进来cf-ngtcp2.c、cf-ngtcp2-cmn.c —— ngtcp2 后端的 HTTP/3 连接过滤器实现其中Curl_cft_http3见 cf-ngtcp2.c是暴露给上层连接系统使用的过滤器类型cf-quiche.c —— quiche 后端的实现整体文件处于USE_QUICHE宏保护下vquic-tls.c —— 把 TLS 库OpenSSL/BoringSSL/GnuTLS/wolfSSL 等的握手回调桥接到 QUIC 库的公共 TLS 适配层vquic.c —— QUIC 后端的公共入口UDP socket 管理、数据收发、通用流程。这些源码都编译进USE_HTTP3宏保护的范围中参见 vquic.c。在 configure 阶段是否定义USE_NGTCP2/USE_QUICHE/USE_NGHTTP3直接决定最终产物里启用哪条 QUIC 路径。官方推荐的外部资源在深入构建之前curl 官方在 docs/HTTP3.md 中推荐了两份背景资料HTTP/3 Explained由 curl 作者 Daniel Stenberg 撰写的在线免费书籍系统讲解 QUIC 与 HTTP/3 涉及的协议演进、动机与技术细节quicwg.orgQUIC 与 HTTP/3 官方协议草案的所在地是查阅 RFC 演进如从 IETF draft 到 RFC 9000 / RFC 9114的第一手资料。curl 使用的 QUIC 库curl 在 docs/HTTP3.md 中明确列出了当前正在使用的 QUIC 实现QUIC 库提供方curl 中的状态ngtcp2ngtcp2 项目配套 nghttp3 实现 HTTP/3 层非实验性官方主推quicheCloudflareEXPERIMENTAL实验性需要特别强调状态差异只有 ngtcp2 后端的 HTTP/3 支持被 curl 官方视为非实验性使用 quiche 的 HTTP/3 支持直到进一步通知前都处于EXPERIMENTAL标记之下。curl 官方在 docs/HTTP3.md 中还给出了移除实验性标记的前提条件To fix before we remove the experimental label所依赖的 QUIC 库自身需要从 beta 阶段毕业不再自称 beta允许保留个别后端为实验性也就是说即使 quiche 仍带实验标签ngtcp2 后端也可以先被转正。HTTP/3 功能的后续开发与调优都发生在 curl master 分支以普通 pull-request 的形式演进与其它功能开发流程无异。从源码看后端选型从编译期宏可以反推出选型逻辑。autotools 构建体系在 configure.ac 中通过--with-ngtcp2、--with-nghttp3、--with-quiche等参数来启用对应后端并据此定义USE_NGTCP2、USE_QUICHE等宏CMake 构建体系则对应提供USE_NGTCP2、USE_QUICHE、USE_NGHTTP3三个开关见 CMakeLists.txt并在链接期通过 CMake/FindNGTCP2.cmake、CMake/FindNGHTTP3.cmake、CMake/FindQuiche.cmake 寻找依赖。构建完成后curl --version输出的特性列表会列出HTTP3字样CMake 侧由 CMakeLists.txt 的curl_add_if(HTTP3 USE_NGTCP2 OR USE_QUICHE)决定。使用 ngtcp2 构建 curl含三种 TLS 组合构建 ngtcp2 版 curl 需要3 个组件ngtcp2 本身、nghttp3以及一个支持 QUIC 的 TLS 库。文档 docs/HTTP3.md 覆盖的 TLS 组合有OpenSSL 及其 forkOpenSSL v3.5.0、quictls、BoringSSL、AWS-LC、LibreSSLGnuTLSwolfSSL。版本提示任何 v1.0.0 起的 ngtcp2 与 nghttp3 版本都被预期可工作但使用最新版本通常会带来功能与性能改进。另外OpenSSL v3.5.0 要求 ngtcp2 v1.12.0 以上更早的 ngtcp2 无法搭配新 OpenSSL 使用。通用前提依赖的构建顺序无论选哪种 TLS 后端都必须先依次构建好三层依赖再构建 curl。下面以 OpenSSL 组合为例给出完整命令文中用$NGHTTP3_VERSION、$NGTCP2_VERSION作为你要构建的版本号占位符/path/to/...请替换为你的实际安装前缀。组合一OpenSSL v3.5.0或 quictls / BoringSSL / AWS-LC / LibreSSL第 1 步构建 OpenSSL v3.5.0或 forkgit clone --depth 1 --branch openssl-$OPENSSL_VERSION https://github.com/openssl/openssl cd openssl ./config --prefix/path/to/openssl --libdirlib make make install第 2 步构建 nghttp3cd .. git clone --depth 1 --branch $NGHTTP3_VERSION https://github.com/ngtcp2/nghttp3 cd nghttp3 git submodule update --init autoreconf -fi ./configure --prefix/path/to/nghttp3 --enable-lib-only make make install--enable-lib-only表示只构建库本身不构建其附带的示例程序。第 3 步构建 ngtcp2cd .. git clone --depth 1 --branch $NGTCP2_VERSION https://github.com/ngtcp2/ngtcp2 cd ngtcp2 autoreconf -fi # 若使用 AWS-LC 或 BoringSSL把 --with-openssl 换成 --with-boringssl ./configure PKG_CONFIG_PATH/path/to/openssl/lib/pkgconfig:/path/to/nghttp3/lib/pkgconfig LDFLAGS-Wl,-rpath,/path/to/openssl/lib \ --prefix/path/to/ngtcp2 --enable-lib-only --with-openssl make make install这里通过PKG_CONFIG_PATH把 OpenSSL 与 nghttp3 的.pc文件暴露给 configure用--with-openssl声明 QUIC 的 TLS 加密后端来自 OpenSSL。第 4a 步用 autotools 构建 curlcd .. git clone --depth 1 https://github.com/curl/curl cd curl autoreconf -fi ./configure PKG_CONFIG_PATH/path/to/openssl/lib/pkgconfig LDFLAGS-Wl,-rpath,/path/to/openssl/lib \ --with-openssl/path/to/openssl --with-ngtcp2/path/to/ngtcp2 --with-nghttp3/path/to/nghttp3 make make install第 4b 步用 CMake 构建 curlcd .. git clone --depth 1 https://github.com/curl/curl cd curl PKG_CONFIG_PATH/path/to/openssl/lib/pkgconfig:/path/to/ngtcp2/lib/pkgconfig:/path/to/nghttp3/lib/pkgconfig cmake -B bld \ -DOPENSSL_ROOT_DIR/path/to/openssl -DUSE_NGTCP2ON cmake --build bldCMake 路径只需显式开启-DUSE_NGTCP2ONnghttp3 与 TLS 的探测会自动完成相关逻辑见 CMakeLists.txt。注意若选用 ngtcp2 v1.12.0CMake 会自动按 openssl/quictls/BoringSSL/wolfSSL 等组件做匹配CMakeLists.txt 还会做 ngtcp2 ≥ 1.12.0 的版本校验。组合二GnuTLS第 1 步构建 GnuTLSgit clone --depth 1 https://gitlab.com/gnutls/gnutls cd gnutls ./bootstrap ./configure --prefix/path/to/gnutls make make install第 2 步构建 nghttp3与 OpenSSL 组合相同cd .. git clone --depth 1 --branch $NGHTTP3_VERSION https://github.com/ngtcp2/nghttp3 cd nghttp3 git submodule update --init autoreconf -fi ./configure --prefix/path/to/nghttp3 --enable-lib-only make make install第 3 步构建 ngtcp2TLS 后端切换为 GnuTLScd .. git clone --depth 1 --branch $NGTCP2_VERSION https://github.com/ngtcp2/ngtcp2 cd ngtcp2 autoreconf -fi ./configure PKG_CONFIG_PATH/path/to/gnutls/lib/pkgconfig:/path/to/nghttp3/lib/pkgconfig LDFLAGS-Wl,-rpath,/path/to/gnutls/lib \ --prefix/path/to/ngtcp2 --enable-lib-only --with-gnutls make make install第 4a 步autotools 构建 curlcd .. git clone --depth 1 https://github.com/curl/curl cd curl autoreconf -fi ./configure PKG_CONFIG_PATH/path/to/gnutls/lib/pkgconfig --with-gnutls/path/to/gnutls --with-ngtcp2/path/to/ngtcp2 --with-nghttp3/path/to/nghttp3 make make install第 4b 步CMake 构建 curlcd .. git clone --depth 1 https://github.com/curl/curl cd curl PKG_CONFIG_PATH/path/to/gnutls/lib/pkgconfig:/path/to/ngtcp2/lib/pkgconfig:/path/to/nghttp3/lib/pkgconfig cmake -B bld -DCURL_USE_GNUTLSON -DUSE_NGTCP2ON cmake --build bld组合三wolfSSL第 1 步构建 wolfSSL需显式开启 QUIC 相关能力git clone --depth 1 https://github.com/wolfSSL/wolfssl cd wolfssl autoreconf -fi ./configure --prefix/path/to/wolfssl --enable-quic --enable-session-ticket --enable-earlydata --enable-psk --enable-harden --enable-altcertchains make make installQUIC 依赖 session ticket会话恢复、early data0-RTT、PSK预共享密钥与 altcertchains 等能力所以上述 configure 开关缺一不可。第 2 步构建 nghttp3同上cd .. git clone --depth 1 --branch $NGHTTP3_VERSION https://github.com/ngtcp2/nghttp3 cd nghttp3 git submodule update --init autoreconf -fi ./configure --prefix/path/to/nghttp3 --enable-lib-only make make install第 3 步构建 ngtcp2TLS 后端切换为 wolfSSLcd .. git clone --depth 1 --branch $NGTCP2_VERSION https://github.com/ngtcp2/ngtcp2 cd ngtcp2 autoreconf -fi ./configure PKG_CONFIG_PATH/path/to/wolfssl/lib/pkgconfig:/path/to/nghttp3/lib/pkgconfig LDFLAGS-Wl,-rpath,/path/to/wolfssl/lib \ --prefix/path/to/ngtcp2 --enable-lib-only --with-wolfssl make make install第 4a 步autotools 构建 curlcd .. git clone --depth 1 https://github.com/curl/curl cd curl autoreconf -fi ./configure PKG_CONFIG_PATH/path/to/wolfssl/lib/pkgconfig --with-wolfssl/path/to/wolfssl --with-ngtcp2/path/to/ngtcp2 --with-nghttp3/path/to/nghttp3 make make install第 4b 步CMake 构建 curlcd .. git clone --depth 1 https://github.com/curl/curl cd curl PKG_CONFIG_PATH/path/to/wolfssl/lib/pkgconfig:/path/to/ngtcp2/lib/pkgconfig:/path/to/nghttp3/lib/pkgconfig cmake -B bld -DCURL_USE_WOLFSSLON -DUSE_NGTCP2ON cmake --build bldCMake 侧-DCURL_USE_WOLFSSLON对应 CMakeLists.txt 的开关它与-DUSE_NGTCP2ON组合时FindNGTCP2.cmake 会按wolfSSL组件探测 QUIC 加密后端见 CMakeLists.txt。三种组合的差异速览组合curl configure 关键开关ngtcp2 的 TLS 开关CMake 关键选项OpenSSL 及 fork--with-openssl...--with-ngtcp2...--with-nghttp3...--with-opensslBoringSSL/AWS-LC 用--with-boringssl-DOPENSSL_ROOT_DIR... -DUSE_NGTCP2ONGnuTLS--with-gnutls...--with-ngtcp2...--with-nghttp3...--with-gnutls-DCURL_USE_GNUTLSON -DUSE_NGTCP2ONwolfSSL--with-wolfssl...--with-ngtcp2...--with-nghttp3...--with-wolfssl-DCURL_USE_WOLFSSLON -DUSE_NGTCP2ON使用 quiche 构建 curl实验性quiche 是 Cloudflare 用 Rust 实现的 QUIC 库curl 官方在 docs/HTTP3.md 明确标注其支持为EXPERIMENTAL。由于 quiche 的构建会自己管理依赖curl 可以直接针对其最新版本构建虽然大概率可以针对 quiche 的 main 分支构建但官方建议遇到问题时优先使用 quiche 的最新 release tag。quiche 依赖 BoringSSLquiche 构建时会自行编译一份因此下面的流程先把 BoringSSL 从 quiche 的构建产物中导出给 curl 使用。以下以 quiche v0.29.1 为例BoringSSL 所在位置会随版本变化。构建 quiche 并导出 BoringSSLgit clone --depth 1 --branch 0.29.1 --recursive https://github.com/cloudflare/quiche cd quiche cargo build --package quiche --release --features ffi,pkg-config-meta,qlog ln -s libquiche.so target/release/libquiche.so.0 mkdir -p boringssl/lib find target/release \( -name libcrypto.a -o -name libssl.a \) -exec ln -vnf -- {} boringssl/lib \; find target/release/build/boring-sys-*/out/boringssl/src -maxdepth 1 \( -name include \) -exec ln -vsf -- ../{} boringssl \;要点说明--features ffi,pkg-config-meta,qlogffi导出 C 接口curl 依赖pkg-config-meta生成.pc文件qlog开启 QUIC 连接日志能力第一组find把构建产物里的静态库libcrypto.a、libssl.a链接进boringssl/lib第二组find把 BoringSSL 的头文件目录链接进boringssl/include通过软链../include指向实际 src 内的 include 目录。构建 curlautotoolscd .. git clone --depth 1 https://github.com/curl/curl cd curl autoreconf -fi ./configure --with-openssl$PWD/../quiche/boringssl --with-quiche$PWD/../quiche/target/release make make installquiche 后端在源码中以 cf-quiche.c 为核心整个文件处于USE_QUICHE宏保护之下cf-quiche.c并直接使用 OpenSSL/BoringSSL 的头文件与 SSL 接口cf-quiche.c这正是 configure 需要同时给出 BoringSSL 位置的原因。若make install报Permission denied在命令前加sudo即可。命令行使用 HTTP/3构建完成后通过以下三种方式让 curl 走 HTTP/3。只用 HTTP/3--http3-onlycurl --http3-only https://example.org:4433/强制使用 HTTP/3不提供任何回退。若 QUIC 连接建立失败curl 直接报错不会自行尝试其它 HTTP 版本。该选项仅对 HTTPS URL 有效对http://URL 会直接触发错误。此选项要求构建时带 HTTP/3 支持Requires: HTTP/3且与--http1.1、--http1.0、--http2、--http2-prior-knowledge、--http3互斥Mutexed详见 docs/cmdline-opts/http3-only.md该选项自 7.88.0 起可用。HTTP/3 优先并可回退--http3curl --http3 https://example.org:4433/尝试 HTTP/3但在连接足够快地失败时回退到更早的 HTTP 版本。具体回退机制参见下文HTTPS eyeballing。该选项允许你在已知/怀疑目标主机与端口支持 HTTP/3、又不想依赖 Alt-Svc 升级路径时使用见 docs/cmdline-opts/http3.md自 7.66.0 起可用。注意curl不能通过任何代理使用 HTTP/3。这意味着需要 HTTP/3 直连目标服务器。通过 Alt-Svc 升级到 HTTP/3--alt-svccurl --alt-svc altsvc.cache https://curl.se/启用 Alt-Svc 解析与缓存若指定的文件已存在则加载其中缓存的alt-svc记录一次传输完成后若缓存有变更会写回该文件。指定空文件名可在内存中处理缓存而不落盘若多次使用--alt-svccurl 会从所有指定文件加载记录但只用最后一个文件做保存。详见 docs/cmdline-opts/alt-svc.md自 7.64.1 起可用。想要验证以上命令效果可以对照社区维护的公共 HTTP/3 服务器清单挑选支持 HTTP/3 的目标站点进行测试。HTTPS eyeballingHTTP/3 的回退策略细节--http3的回退机制与 IPv4/IPv6 双栈的Happy Eyeballs策略异曲同工HTTP/3 连接失败得足够快时curl 会并行尝试早期 HTTP 版本。文档 docs/HTTP3.md 详细描述了这套时序机制。IPv4/6 eyeballing 的默认间隔是200ms可通过--happy-eyeballs-timeout-ms value覆盖默认值 200ms见 docs/cmdline-opts/happy-eyeballs-timeout-ms.mdRFC 6555 建议 150–250ms。由于 HTTP/3 仍较新curl 决定把这个超时也复用于 HTTP eyeballing并加了一个小变化Hard timeout硬超时即--happy-eyeballs-timeout-ms设定的值。超过该时间后curl 会额外开启一条 TLS 连接去协商 HTTP/2 或 HTTP/1.1Soft timeout软超时目前为硬超时的一半。触发条件是在 HTTP/3 连接上完全没有看到来自服务器的任何数据。不指定任何值时硬超时 200ms软超时 100ms。由此可以得到四种典型走向场景行为理想情况整个 QUIC 握手在 100ms 内完成curl 直接拿到 HTTP/3 连接QUIC 不受支持或该网络路径上 UDP 不通收不到任何应答100ms 后启动 HTTP/2 的 TLSTCP 连接最坏情况UDP 应答在 100ms 前开始到达、却迟迟不完成200ms 后启动 TLSTCP 连接QUIC 握手失败立即尝试 TLSTCP。例如 QUIC 服务器出示了错误证书时只有当QUIC 与 TLSTCP 两条路径都握手失败或超时整个传输才会失败。需要注意以上全部过程都叠加在 IP 版本 eyeballing 之上如果服务器域名解析出多个 IPcurl 会逐一尝试直至成功与其它协议一致若同时含 IPv6 与 IPv4这些尝试会延迟后并行进行——这才是真正的 eyeballing。已知问题Known BugsHTTP/3 在 curl 中仍属较新能力官方维护了一份持续更新的 HTTP/3 已知缺陷清单对应 docs/HTTP3.md 中的相关链接亦可在 curl 官方 knownbugs 页面按 HTTP3 分类查看。在深入使用或给 curl 提交 HTTP/3 相关 issue 之前建议先核对清单避免重复报告已知问题。搭建本地 HTTP/3 测试服务器官方在 docs/HTTP3.md 中提供了在本机搭建 HTTP/3 反向代理做开发与试验的完整指引明确说明这不是生产部署建议。推荐拓扑是一个现成的本地 HTTP/1.1 服务器 一个 HTTP/3 反向代理客户端经 QUIC 访问代理、代理再以 HTTP/1.1 回源。前置条件一个已存在的、负责托管文件的本地 HTTP/1.1 服务器。最好准备一些大文件例如用稀疏文件快速造一个超大文件truncate -s8G 8GB这个 8GB 文件是稀疏的大洞不占多少实际磁盘空间。Debian 系可直接安装 apache2它监听 80 端口文档根目录为/var/www/html随后验证回源下载curl localhost/8GB -o dev/null下面分别给出 nghttpx 与 Caddy 两种反向代理方案可任选其一或两者都用。方案 Anghttpxnghttp2 项目自带代理先按前文步骤构建并安装 quictls、nghttp3、ngtcp2再构建 nghttp2注意要用--enable-http3开启其 HTTP/3 前端能力git clone --depth 1 https://github.com/nghttp2/nghttp2 cd nghttp2 autoreconf -fi PKG_CONFIG_PATH$PKG_CONFIG_PATH:/path/to/quictls/lib/pkgconfig:/path/to/nghttp3/lib/pkgconfig:/path/to/ngtcp2/lib/pkgconfig \ LDFLAGS-L/path/to/quictls/lib CFLAGS-I/path/to/quictls/include ./configure --enable-maintainer-mode \ --prefix/path/to/nghttp2 --disable-shared --enable-app --enable-http3 --without-jemalloc --without-libxml2 --without-systemd make make install随后在9443端口启动本地 HTTP/3 服务把所有流量反代到 localhost 的 80 端口 HTTP/1.1 服务器。本地试验可以直接复用 curl 测试目录里现成的测试证书CERT/path/to/stunnel.pem $HOME/bin/nghttpx $CERT $CERT --backendlocalhost,80 \ --frontendlocalhost,9443;quicnghttpx第一个参数是服务器证书、第二个是私钥文件--frontendlocalhost,9443;quic表示该前端监听 QUICUDP即对外提供 HTTP/3。方案 BCaddy安装 Caddy 后建议把二进制放入 PATH 或当前目录创建一个Caddyfilelocalhost:7443 { respond Hello, world! you are using {http.request.proto} }启动 Caddy./caddy start此时访问https://localhost:7443应答内容里的{http.request.proto}会告诉你实际使用的协议版本——如果浏览器/客户端协商成功你会看到HTTP/3.0。需要更贴近真实场景时把respond替换为reverse_proxy或file_server例如reverse_proxy localhost:80即可把 Caddy 变成一个 HTTP/3 反向代理回源到本地 HTTP/1.1 服务器。与仓库测试体系对应curl 自带测试套件已包含多组 HTTP/3 用例可作为你本地验证的参考实现。例如tests/data/test2501标记http/3feature 与http/3服务端执行curl --insecure --http3 ... -d moo的 HTTP/3 POST并校验返回HTTP/3 201与via: 1.1 nghttpx——可见测试服务器正是 nghttpxtests/data/test2500--http3--resolve localhost:%HTTP3PORT的 HTTP/3 GETtests/data/test2503--http3-only结合 header-api 输出%{header_json}的用例。这些用例的features段如 tests/data/test2501 的Debug http http/3说明只有构建出带 HTTP/3 的 curl跑测试时才会选中http/3feature。因此在你按本文构建完成后可以进入仓库 tests 目录运行类似runtests.pl 2501的命令来快速验证本机 HTTP/3 是否真正可用。小结回顾整条路径curl 的 HTTP/3 能力不是单一实现而是围绕 ngtcp2/nghttp3 与 quiche 两套 QUIC 栈、经由USE_NGTCP2/USE_QUICHE等宏在 lib/vquic 目录里完成的连接过滤器接入TLS 侧则可选择 OpenSSL 系、GnuTLS 或 wolfSSL。构建时按依赖 → nghttp3 → ngtcp2 → curl的顺序执行autotools 与 CMake 都有对等选项。使用侧则由--http3-only严格、--http3带回退配合 200ms/100ms 双层 eyeballing 时序与--alt-svc服务端通告式升级三种入口控制。最后nghttpx 或 Caddy 可以作为本地 HTTP/3 反向代理与仓库中的 HTTP/3 测试用例配合快速验证整条链路的正确性。【免费下载链接】curlA command line tool and library for transferring data with URL syntax, supporting DICT, FILE, FTP, FTPS, GOPHER, GOPHERS, HTTP, HTTPS, IMAP, IMAPS, LDAP, LDAPS, MQTT, MQTTS, POP3, POP3S, RTSP, SCP, SFTP, SMB, SMBS, SMTP, SMTPS, TELNET, TFTP, WS and WSS. libcurl offers a myriad of powerful features项目地址: https://gitcode.com/GitHub_Trending/cu/curl创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考