📌 项目地址：cloudflare/quiche | ⭐ 11,952 颗星 | 🔧 Rust | 📜 未标注
项目地址 | 11,952 star | Rust | BSD-2-Clause
先把定位说透
quiche 是 Cloudflare 开源的 QUIC 传输协议和 HTTP/3 实现，按 IETF 规范写的，Rust 语言，许可证 BSD-2-Clause。
它的定位是低层 API。quiche 只做两件事：解析 QUIC 数据包，维护连接状态。socket 的读写、事件循环、定时器，全部由应用自己负责。README 原话就是这么写的。
这是刻意的设计，不是功能缺失。写这个库的人，目标用户也是写网络服务的人。如果你只是想发一个 HTTP/3 请求，这篇文章看个开头就够了，curl 直接能满足你。
谁在用它
三个使用方，每个都分量十足：
Cloudflare。自家边缘网络的 HTTP/3 支持跑在 quiche 上，全球流量在喂它。还开了个 cloudflare-quic.com 测试站，可以随时验证。
Android。系统级 DNS 解析器用 quiche 实现了 DNS over HTTP/3。一个第三方库能进 Android 系统组件，内存安全和跨平台这两关肯定过了。Google 的安全博客 2022 年专门写过一篇介绍。
curl。官方文档里给出了基于 quiche 的 HTTP/3 集成方案，照着做就能给 curl 加上 HTTP/3。
我觉得 Android 这个案例最有说服力。系统组件对依赖的挑剔程度远高于普通应用，能过审的库，质量不会差。
五分钟跑起来
仓库里附带 quiche-apps，提供客户端和服务端两个命令行工具。官方明确说了：不适合生产环境，体验协议用。
客户端一行命令，直接访问 Cloudflare 的测试站：
cargo run --bin quiche-client -- https://cloudflare-quic.com/
服务端用仓库自带的自签名证书就能起：
cargo run --bin quiche-server -- --cert apps/src/bin/cert.crt --key apps/src/bin/cert.key
提醒一句，这个证书是自签的，生产环境别碰。每个工具加 --help 可以看完整参数。
代码长什么样
建 QUIC 连接的第一步是创建 Config 对象：
let mut config = quiche::Config::new(quiche::PROTOCOL_VERSION)?;
config.set_application_protos(&[b"example-proto"]);
// Additional configuration specific to application and use case...
Config 管着连接的核心属性：QUIC 版本、ALPN、流控、拥塞控制、空闲超时。
有一个设计决定值得单独讲。QUIC 是通用传输协议，很多配置项没有合理的默认值。README 举的例子是并发流的数量上限，这个数完全取决于你的应用怎么用 QUIC，库层面给不出统一答案。
所以用 quiche 之前，你得先懂 QUIC 本身。它不会替你做决定。
这种设计换来的东西很直接：传输层的控制权全在你手里。Cloudflare 拿它跑全球边缘网络，Android 拿它做 DNS over HTTP/3，这些都不是标准 HTTP/3 客户端的用法，只有低层 API 才撑得住这种自由度。
结论
一句话：适合要在自有服务里集成 QUIC/HTTP/3、愿意自己管 I/O 的人。想找个现成 HTTP 客户端的，去用 curl。
API 文档在 docs.rs/quiche。设计背景可以读 Cloudflare 博客那篇《Enjoy a Slice of Quic… and Rust》，讲了这个库怎么来的，以及一些设计上的取舍。