DEV Community: zhuweiye

libuvcpp v1.9.0: Redefining the C++ Network Stack with Raw Performance

zhuweiye — Thu, 29 Oct 2026 03:51:00 +0000

libuvcpp v1.9.0 is a "fill-the-gaps" release. Instead of introducing new top-level modules, this version meticulously patches up HTTP consistency, finalizes h3/WebTransport support, enhances TLS/WS server capabilities, and adds much-needed QUIC observability.

More importantly, in the latest authoritative HttpArena benchmarks, libuvcpp just delivered a performance report card that demands the C++ community's attention: it ranks #1 among all C++ frameworks and sits firmly in the global top tier across all three core protocols: HTTP/1.1, HTTP/2, and HTTP/3.

Performance: Dominating the Authoritative Benchmarks

HttpArena is one of the most comprehensive HTTP open-source benchmarking platforms, covering HTTP/1.1, HTTP/2, HTTP/3, gRPC, and WebSocket scenarios.

HTTP/1.1: Composite Score 7064 (Global #7, C++ #1)

Among the 81 frameworks tested in the HTTP/1.1 benchmark, libuvcpp ranked #7 globally with a composite score of 7064, making it the highest-ranked C++ framework. It sits right behind a handful of frameworks hyper-optimized for raw speed, like dusty (Zig), tako (Rust), and actix (Rust).

HTTP/2: Composite Score 4339 (Global #1)

HTTP/2 is where libuvcpp truly shines. With a composite score of 4339, it took the #1 spot globally, followed by OCaml's aaraara (4188) and Mojo's flare (3870). libuvcpp performs exceptionally well across all HTTP/2 sub-configurations (baseline, static, h2c).

HTTP/3: Composite Score 2188 (Global #1)

In the latest HTTP/3 benchmarks, libuvcpp also claimed #1 with a composite score of 2188, beating bun (TS, 1775) and flare (Mojo, 1770). HTTP/3, built on QUIC, is notoriously difficult to implement. Winning here proves that libuvcpp's investment in modern transport protocols has paid off.

The Global Perspective

Looking at the combined leaderboards, libuvcpp is one of the few frameworks to break into the global top 10 across all three protocol families. And in HTTP/2 and HTTP/3, it goes straight to the top.

Note: Benchmark results are influenced by hardware, configuration, and testing methodologies. However, for libuvcpp to consistently land in the top tier across multiple independent protocol benchmarks speaks volumes about the strength of its underlying performance.

What’s New in v1.9.0?

Version 1.9.0 folds the development line from 1.8.11 to 1.8.15 into one release, focusing on four main areas: HTTP consistency, h3/WebTransport finalization, TLS & WebSocket server capabilities, and QUIC observability.

HTTP Consistency is the most "unsexy but critical" part of this update. The response side of h2/h3 now validates content-length—responses lying about their length will no longer be treated as successfully completed. Trailers in h1 finally go through a real chunked stream (send_trailers() / set_trailers()). Status codes like 1xx/204/304 no longer redundantly append content-length: 0. Clients can also opt-in to follow redirects (same-origin only, with a hop limit).

h3 / WebTransport: The webapp now supports h3 trailers and streaming responses (begin_chunked → write_chunk → end). WebTransport establishment timing, on_open delivery, Close/Drain capsules, and SESSION_GONE stream resets have all been aligned.

TLS & WebSocket Server Capabilities: Two practical gaps were filled: Server Name Indication (SNI) multi-certificates (wildcard, exact match priority, fallback to default), and server-side WS subprotocol selection (App config on h1, returning the first subprotocol on h2/h3).

Observability: uvcpp_quic_connection::stats() now gives you direct access to RTT, cwnd, packet loss, and send/receive counts—QUIC is no longer a black box.

⚠️ Breaking Changes: v1.9.0 introduces breaking changes: send_trailers() error code semantics on h1 have changed, and the C API's expected_body() behavior has been corrected. Public classes have new members/methods, so users compiling against older headers must recompile. The repository does not guarantee binary layout compatibility across versions.

More Than a Wrapper: Modular Architecture and WebApp

libuvcpp is organized in layers, from bottom to top: core → handle/req → net → ssl → http2 → web → webapp, with QUIC and HTTP/3 integrated as parallel transport layers.

The bottom layer is a RAII encapsulation of libuv handles and requests. Classes like uvcpp_loop, uvcpp_tcp, uvcpp_timer, and uvcpp_write give event loops and async operations clear C++ ownership semantics. The Net layer provides uvcpp_tcp_client/server and uvcpp_udp_client/server, where the TCP client is a dual-mode API: asynchronous callbacks, or synchronous wait() with timeouts.

The Web layer covers HTTP/1.1, WebSocket, and HTTP/2 (via nghttp2). All optional features are opt-in: zlib/brotli compression, OpenSSL, nghttp2, QUIC, HTTP3, and yyjson are independently toggleable. Enabling UVCPP_BUILD_WEB=ON won't silently drag in a pile of dependencies.

The WebApp Framework is a higher-level application abstraction. You write handlers, not wire formats:

uvcpp_web_app app;
app.set_port(8080)
   .use(web_middleware_access_log())
   .use(web_middleware_cors());

app.get("/hello", [](uvcpp_web_request& req, uvcpp_web_response& resp, uvcpp_web_next next) {
    resp.json_str("{\"hello\":\"world\"}");
    resp.end();
});

app.websocket("/echo", [](uvcpp_web_ws_request& ws) {
    auto* c = ws.connection();
    c->on_text([c](const std::string& m) { c->send_text(m.c_str(), m.size()); });
});

app.start();
app.join();

This snippet covers routing, middleware, JSON responses, and a WebSocket echo server—in the raw libuv C API, this would require a significant amount of boilerplate just to reach the same starting line. WebApp also comes with static file serving (ETag, Range, SPA fallback), streaming multipart uploads, request body streaming, and a WebSocket client with auto-reconnect.

For cross-language scenarios, libuvcpp provides a C ABI (uvcpp_c_*). By version 1.5.3, it had 402 functions covering foundation, net, webapp, HTTP/2, QUIC, HTTP/3, and db. The repository even includes a C# binding.

Getting Started

Prebuilt packages cover six platforms: Windows x64/arm64 (MSVC and MinGW), and Linux x64/arm64 (GCC). Each package includes both Release and Debug libraries, public headers, uvcpp.pc, and CMake package configs—no need to carry around DLLs or .so files manually.

System-level installation is straightforward:

# Debian / Ubuntu
sudo apt install libuvcpp-dev

# Fedora / RHEL
sudo dnf install libuvcpp-devel

Build requirements are C++11 or higher, CMake ≥ 3.20, MSVC 2019+ / GCC 7+ / Clang 5+. If libuv isn't found on the system, it will automatically fetch it via FetchContent.

Final Thoughts

libuv's performance has been proven repeatedly. What the C++ ecosystem truly lacks isn't another event loop, but a wrapper that doesn't sacrifice performance while feeling natural to C++ developers.

The value of libuvcpp 1.9.0 lies in how it layers on "production-grade details" one by one—HTTP consistency, HTTP/3/WebTransport, TLS SNI, WS subprotocols, QUIC metrics—while expanding its usability from a low-level library to an application stack via the WebApp framework and C ABI.

If you're already using libuv, or if you're looking for a C++ async networking solution beyond Boost.Asio, v1.9.0 deserves a spot on your comparison list. And the fact that it swept the #1 spots for both HTTP/2 and HTTP/3 on HttpArena is proof that this project's performance foundation can withstand independent scrutiny.

GitHub: https://github.com/Antruly/libuvcpp
v1.9.0 Release: https://github.com/Antruly/libuvcpp/releases/tag/v1.9.0
HttpArena Benchmarks: https://www.http-arena.com/
Documentation: Module-by-module guides in the doc/ directory; all code examples are compiled and verified by CI.

uvscope: the Swiss Army knife of web debugging

zhuweiye — Wed, 28 Oct 2026 11:20:19 +0000

Debugging a request that crosses HTTP → WebSocket → raw TCP usually means juggling four or five tools: a REST client, a socket client, nc, a proxy, and a terminal. Every switch costs you context — headers here, frames there, logs somewhere else.

uvscope is my attempt to collapse that stack into one place — a Swiss Army knife for web debugging. It puts HTTP, WebSocket, TCP, UDP, TLS, SOAP/WSDL and managed reverse proxies behind a single Vue 3 control plane, backed by a C++ daemon that owns the event loop, the SQLite store, authentication and all outbound network traffic. The browser only renders state and sends commands.

Why another debugging tool?

Most tools stop at request/response. uvscope is built around the whole handshake:

One workbench for every protocol — HTTP/1.1 and HTTP/2, WebSocket, raw TCP/UDP, X.509 and WSDL-driven SOAP, with the same history, telemetry and export model.
A real gateway, not a mock — reverse proxies with routing rules, weighted upstreams, retries, health checks, circuit breaking and WebSocket pass-through, with live traffic in view.
Long-lived services without a second stack — TCP/UDP listeners, SOCKS5 servers, reverse proxies and terminal PTYs run in child processes under one desired-state supervisor.
Local-first — SQLite, server-side sessions, PBKDF2 password hashing, RBAC and a first-run admin flow. No telemetry, no cloud account, no external database.
One network stack — every target connection is driven by libuvcpp 1.8.2, from socket to UI.
A UI that keeps context — collapsible navigation, cached multi-tab workspaces, live telemetry and an offline command library built with Vue 3, Pinia and Vite.

What's inside

HTTP and APIs

Capability	Status
HTTP/1.1 + HTTPS debugger with headers, body, timing and history	Stable
Body modes: raw, form-urlencoded, multipart with files	Stable
cURL / HAR / OpenAPI / Postman import and export	Stable
Environments with `{{variables}}`, pre-request and post-response scripts	Stable (browser-side)
HTTP/2 over TLS with ALPN, stream IDs, GOAWAY and frame summary	Stable
gzip / deflate / brotli decoding with a raw-body toggle	Stable
Streaming download with progress, cancel and Range resume	Stable
Response preview: sandboxed HTML, images, audio, video and PDF	Stable (scripts opt-in)
SOAP 1.1 + WSDL operation discovery	Stable
HTTP/3 and raw QUIC probes	Supported in QUIC-enabled builds

Realtime and transports

Capability	Status
WebSocket console: daemon-side backend sessions and browser-native mode	Stable
Backend WebSocket headers, subprotocols, frames, ping/pong, close codes	Stable
One-shot TCP and UDP probes (text / hex)	Stable
Persistent TCP sessions with repeated sends and event logs	Stable
TCP / UDP server listeners with sessions, datagrams and replies	Stable
SOCKS5 client and server (CONNECT / BIND / UDP ASSOCIATE)	Stable
Virtual terminal (Unix PTY / Windows ConPTY) with offline command library	Stable — off by default

Gateway and long-lived services

Capability	Status
Reverse proxy: exact / prefix / regex rules, redirects and rewrites	Stable
Header / method / host conditions, weighted upstreams, retries	Stable
Active upstream health checks, per-upstream circuit breaker, QPS/latency metrics	Stable
Proxy config hot reload with runtime config versions	Stable
WebSocket pass-through in the reverse proxy	Stable
Child-process isolation for proxies, listeners, SOCKS5 servers and terminals	Stable
Unified desired-state supervisor with restart, backoff and event log	Stable
Managed TLS certificates, local CA, CA-signed certs and in-place renewal	Stable

Operations and security

Capability	Status
SQLite persistence, first-run setup, local auth, RBAC (admin / operator / viewer)	Stable
Server-side sessions, active-session revocation, audit log	Stable
Backup download and staged restore	Stable
Module toggles, factory reset, update check, about/help	Stable
Chinese / English UI with browser-language detection and manual switch	Stable
Dark / light / follow-system theme	Stable
Linux tar/deb/rpm, Windows zip + installer, macOS tar.gz	Stable

Quick start

Requirements

C++17 compiler, CMake ≥ 3.20, Ninja
Node.js 20+ and npm
libuv, zlib, SQLite and OpenSSL development headers
Linux, macOS, or Windows with MSYS2 MinGW-w64

On Debian/Ubuntu:

sudo apt install build-essential cmake ninja-build libuv1-dev zlib1g-dev \
  libssl-dev libsqlite3-dev git curl

Build from source

git clone https://github.com/Antruly/uvscope.git
cd uvscope
./scripts/build.sh
./build/uvscope --port 8787 --open

build.sh clones the libuvcpp v1.8.2 release into .deps/, applies one minimal upstream patch shipped in patches/upstream/ (WebSocket handshake headers), builds the frontend, then builds uvscope and runs --self-check.

If you already have a libuvcpp 1.8.2 SDK:

npm --prefix web ci && npm --prefix web run build
cmake -S . -B build -G Ninja -DCMAKE_BUILD_TYPE=Release \
  -DUVCPP_ROOT=/path/to/libuvcpp
cmake --build build -j
./build/uvscope --self-check

Open http://127.0.0.1:8787. The first visit creates the administrator account. Runtime state lives in the data directory printed at startup (~/.local/share/uvscope on Linux by default; override with --data-dir).

CLI

uvscope [options]

  --host <addr>       Listen address (default 127.0.0.1)
  --port <port>       Listen port (default 8787, 0 picks a free port)
  --data-dir <path>   SQLite and runtime data
  --web-root <path>   Built frontend directory
  --tls-cert <pem>    Serve the workbench UI over HTTPS
  --tls-key <pem>     Private key paired with --tls-cert
  --open              Open the workbench in the default browser
  --self-check        Run offline smoke tests and exit
  --version           Print version and exit

Hidden child modes (--proxy-child, --listener-child, --socks5-child, --terminal-child, --ipc-child) are spawned by the daemon and are not meant to be invoked by hand.

Architecture

Vue 3 SPA (multi-tab, cached workspaces)
        │ same-origin HTTP + WebSocket + cookies
        ▼
uvscope daemon (C++17 / libuvcpp)
  ├─ auth + RBAC + SQLite + audit + backup
  ├─ HTTP API and static asset server
  ├─ probes, debug sessions and terminal sessions
  ├─ desired-state supervisor
  └─ optional child processes (isolated services)
        ├─ reverse proxy runtime
        ├─ TCP/UDP listener runtime
        ├─ SOCKS5 server runtime
        └─ terminal PTY / ConPTY
              │
              └─ libuvcpp → libuv → sockets

The daemon is the only process that serves the UI and owns SQLite. In the default in-process mode it also owns every outbound socket; with isolation enabled, a service opens its own sockets inside its child process. The WebSocket view additionally offers a browser-native mode, because origin, mixed-content and certificate prompts are part of what is being debugged.

Isolation and supervision

Proxies, TCP/UDP listeners, SOCKS5 servers and virtual terminals accept isolated: true. The parent process keeps the API state, scrollback and ownership metadata; the service runs in a child process and talks to the parent over a length-prefixed JSON IPC channel.

All four service kinds are registered with one desired-state supervisor:

a crashed child is restarted with exponential backoff (2–60 s) and a new PID;
restart counts and events are visible in /api/supervisor and /api/supervisor/events;
stopping a service clears its desired state, so the watchdog leaves it down;
deleting a service unregisters it before teardown;
a normal terminal exit is not a crash — the child stays alive so scrollback and the exit code remain readable. A crashed terminal is respawned with a fresh shell, and attached WebSocket clients receive a reset frame before the new output.

Security model

Default bind is 127.0.0.1. Do not expose uvscope to an untrusted network without an authenticating proxy.
Passwords are PBKDF2-HMAC-SHA256 (210,000 iterations); sessions are server-side and stored as SHA-256 token hashes. Cookies are HttpOnly + SameSite=Lax.
Anyone who can authenticate can reach the host network, start listeners/proxies, and — when the terminal module is enabled — obtain a shell as the daemon user. Treat access as equivalent to code execution on that host.
Isolated services run as the same OS user; isolation is a fault boundary, not a security sandbox.
Use the TLS Inspector and “Allow insecure TLS” only against systems you control.

Platforms and downloads

Prebuilt v1.0.1 assets are on the Releases page, shipped with SHA256SUMS, a Sigstore keyless signature and a generated SPDX SBOM.

Platform	Release	Notes
Linux x64	tar.gz, deb, rpm	Primary CI and smoke matrix
Linux arm64	tar.gz, deb, rpm	Release build and self-check
Windows x64 (MinGW)	zip, setup.exe	CI build, self-check and ConPTY smoke
macOS arm64	tar.gz	CI build, self-check and HTTP/2 runtime check
HTTP/3 / QUIC	QUIC-enabled builds	Requires OpenSSL 3.6+; default assets keep QUIC off

Verify a download with:

sha256sum -c SHA256SUMS
cosign verify-blob --bundle SHA256SUMS.sigstore.json \
  --certificate-identity-regexp 'https://github.com/Antruly/uvscope/.*' \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com \
  SHA256SUMS

Wrapping up

uvscope is MIT-licensed and the docs live at https://antruly.github.io/uvscope/ — including the HTTP API, architecture notes, event schema and roadmap.

If it saves you a debugging session, a star on GitHub helps other protocol wranglers find it.