XQUIC: Alibaba's QUIC and HTTP/3 stack, and where its standardization stops

A client and server stack for QUIC v1 and draft-29

XQUIC is what the project calls a cross-platform implementation of QUIC and HTTP/3, written in C and released by Alibaba. It is both ends of the protocol: the repository ships a server and a client, and the `demo/` directory holds `demo_client.c` and `demo_server.c` alongside a higher level HQ layer built from `xqc_hq_conn.c`, `xqc_hq_ctx.c` and `xqc_hq_request.c`.

The version story is worth reading carefully, because it is the first thing that will decide whether you can talk to your peers. The README states that supported QUIC versions are v1 and draft-29. draft-29 is an old snapshot of the specification, kept alongside the finished v1. A client that only speaks v1 is the normal choice in 2026; a stack that still negotiates draft-29 exists to interoperate with older deployments, and that compatibility surface is a maintenance cost, not a feature.

The intended user is an engineer embedding a QUIC stack inside a product, not someone who wants a command line HTTP/3 client. Most of the code is used in Alibaba's own products, and the README says it has been tested at scale on Android and iOS apps as well as servers.

What is standardized and what is still a draft

The feature list separates cleanly into three tiers, and the boundary is the useful part.

Standardized: the full set of big features conforming with RFC 9000 (transport), RFC 9001 (TLS), RFC 9002 (loss detection and congestion control), RFC 9114 (HTTP/3) and RFC 9204 (QPACK), including the interface between QUIC and TLS, 0-RTT connection establishment, HTTP/3 and QPACK. ALPN negotiation per RFC 7301 is also listed as standardized.

Not yet standardized: Multipath QUIC and QUIC-LB, the load balancer architecture for QUIC servers. The README links Multipath QUIC at draft-ietf-quic-multipath-04 in the feature body, and the feature badges also list QUIC-LB at draft-ietf-quic-load-balancers-13 and qlog main schema draft-07. These will change under you. Draft numbers move, fields get renumbered, and code written against one revision needs revisiting.

Interoperability is tested against other QUIC implementations through a public interop runner, which is the mechanism that keeps the draft features honest.

Two CCM cipher suites are excluded on purpose

XQUIC documents exactly three TLS 1.3 cipher suites as supported for QUIC packet protection: TLS_AES_128_GCM_SHA256 with AES-ECB (128-bit) header protection, TLS_AES_256_GCM_SHA384 with AES-ECB (256-bit), and TLS_CHACHA20_POLY1305_SHA256 with ChaCha20 header protection.

Two are listed as not supported, and the README explains why rather than leaving it implicit. TLS_AES_128_CCM_SHA256 is skipped because the CCM-based suites have significantly lower confidentiality and integrity limits, given as 2^21.5 against GCM at 2^23 or 2^52 and ChaCha20-Poly1305. TLS_AES_128_CCM_8_SHA256 is skipped for a harder reason: RFC 9001 excludes it from QUIC usage because no header protection scheme is defined for it.

For most deployments this costs nothing. It does mean a peer configured with CCM-only policy will fail to negotiate with XQUIC, which is worth knowing before you debug a handshake that never completes.

Pluggable congestion control and TLS backends

Two extension points are called out as library features. Congestion control is pluggable, with NewReno, Cubic, BBR and BBRv2 named as the available algorithms. Cryptography is pluggable too, with integration with BoringSSL and BabaSSL (Tongsuo).

Those two choices determine how much of your deployment you own. Picking BBR or BBRv2 moves the pacing and bandwidth estimation decisions into your build, and the interop and conformance testing you would otherwise get from a stack with one opinion is yours to arrange. Picking BabaSSL versus BoringSSL decides whether your FIPS posture and patch stream come from one tree or two.

Neither extension point is documented in the README with an API name, so the concrete configuration surface has to be read from the headers under `include/` or from the documentation site at https://doc.xquic.org.cn.

Building the library with CMake and BoringSSL

The README states the build requirements: CMake, plus BoringSSL or BabaSSL. Running the test cases adds libevent and CUnit. The repository root carries a CMakeLists.txt, a cmake/ directory, and a `xqc_build.sh` script at the top level, next to `xqc_configure.h.in`, which is where the generated configuration header comes from.

The documented quick start begins by installing the build dependencies and fetching the source:

sudo apt-get install -y build-essential libevent-dev

# get XQUIC source code
git clone https://github.com/alibaba/xquic.git; cd xquic

After that, follow the current README for the BoringSSL source and build steps. Running the demo is a separate step through the `demo/` directory, and the interop work lives under `interop/`.

Apache-2.0 licensing and what an upgrade actually costs

XQUIC is Apache-2.0, with the licence file at the repository root alongside CONTRIBUTING.md, CODE_OF_CONDUCT.md, SECURITY.md and AGENTS.md. For an embedder the practical licence question is attribution and notice, not restriction, and this is not legal advice.

The upgrade cost is driven by the C surface and the draft features. The repository is not archived and the last push was on 2026-10-15, with v1.9.7 released on 2026-09-10, v1.9.6 on 2026-08-28 and v1.9.5 on 2026-08-11. That is a monthly-ish patch line on a 1.x series, which means API movement between minors is possible and a vendored copy needs a defined update rhythm.

At the same time, tracking every release is optional. A deployment pinned to QUIC v1, the three supported cipher suites and one congestion control algorithm is using the standardized portion of the code, and that portion has the least reason to change underneath you. The risk concentrates in the parts you enabled for a reason: multipath and QUIC-LB.

Editorial conclusion

XQUIC fits teams that need to embed QUIC and HTTP/3 directly into an application, particularly mobile clients on Android or iOS, and that are willing to track a library the vendor describes as still in active development. It does not fit a team that needs standardized multipath or QUIC-LB, since both remain IETF drafts here, nor one that wants only the three standardized TLS 1.3 cipher suites' worth of configuration freedom, because CCM suites are excluded by design. Verify first that your peer implementations interoperate against your target QUIC version, then build with `xqc_build.sh` in a tree where CMake and BoringSSL or BabaSSL are present, since the test suite additionally needs libevent and CUnit.

Frequently asked questions

Official sources

1. alibaba/xquic on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases