AWH — ANYKS Web Hub
Our own networking foundation, from the memory allocator to HTTP/3. One library instead of a stack of four dozen third-party ones. Written from scratch against the text of the standards, running on twelve operating systems, measured against the reference implementations of its field.
The foundation networked software is built on
Any program that talks over a network — a website, a banking app, a telecom system, an industrial controller — is made of the same layers: memory handling, data parsing, encryption, exchange protocols.
Usually these layers are taken ready-made from different authors and stacked like a construction kit. AWH is the same set of layers, written entirely by us as one whole: one style, one error contract, one way of handling memory across the whole stack.
| Layer | What it does | Lines |
|---|---|---|
| Networking and engines | data exchange with the operating system | 476,777 |
| Codecs | JSON, XML, YAML, TOML, INI, CSV, CEF, SysLog, ABC | 181,032 |
| Protocols | HTTP/1, HTTP/2, HTTP/3, QUIC, SOCKS5 | 91,835 |
| System layer | threads, fibers, signals, time, files | 56,237 |
| Encodings | UTF-8, conversions, hashes | 53,772 |
| Regular expressions | our own PCRE2 replacement with code generation | 51,319 |
| Encryption | GOST, TLS, key storage | 48,734 |
| Numbers and memory | big-number arithmetic, our own allocator | 47,421 |
| Ready-made nodes | DNS, NTP, ICMP, tunnels, cluster, timers | 45,510 |
One part instead of forty
This is a list, not an estimate: every one of these libraries physically sits in the repository as a benchmark reference and runs on the same data as our code. The replacement is proven by numbers, not claimed.
Protocols
Data parsing
Foundation
Only compression libraries stay external — zlib, zstd, lz4, brotli, lzma, bz2. They are narrow, interchangeable, and carry neither protocol logic nor cryptography.
The cost of building from other people's parts
More expensive
Forty libraries mean forty styles, type systems and memory ownership rules. Every security update to one of them is a separate compatibility check against all the others. Forty licences, some restricting distribution.
Slower
Data is copied between layers because neighbouring libraries use incompatible representations. One blocks the thread, another doesn't; one allocates memory, another expects someone else's. A bug at the seam belongs to nobody.
Riskier
Updates come from outside and can stop at any moment. Auditing forty foreign code bases for backdoors is unrealistic. A vulnerability in one library is a vulnerability in the whole product, fixed on someone else's schedule.
A single foundation: protocol parsing reads straight from the input buffer with no copies, one decision log and one test system cover the whole stack, and we fix a bug in any layer ourselves, on our own schedule.
HTTP/3 and HTTP/2: share of the reference implementation
One hundred percent is the reference: nghttp3 and nghttp2, which run a large part of the internet. Right of the line means we are faster. Measured with each side's own drivers on the same machine, Release build.
HTTP/3 · vs nghttp3
HTTP/2 · vs nghttp2
Header encoding is a known weakness of both implementations: broken down step by step, seven changes have already improved it, the remainder is measured. Reports live in benchmark/proto/*/COMPARISON.md.
Predictability matters more than peak speed
The memory allocator is called millions of times per second. We are not the fastest, but we are the same on every system, while competitors scatter by two or three orders of magnitude. For telecoms, embedded and real-time systems evenness is worth more than a record: it lets you plan for the worst case, not the average.
Nanoseconds per operation, log scale. Bar width is the spread across operating systems. More about the allocator →
| Measure | Result |
|---|---|
| Regex vs PCRE2 | machine code faster in 37 of 41 scenarios, interpreter behind in none of 45; median ratios 1.18 and 1.46 |
| HTTP/1: body parsing | 1st of 6 — 20,607 MB/s |
| HTTP/1: headers | 3rd of 6 — twice as fast as nginx, http-parser and Beast |
| HTTP/1: allocations | zero per message, with a stronger contract |
| GOST vs gost-engine | correctness proven against the reference's numbers |
Where we fall behind and why
Nothing below is hidden: each item is measured, and its cause is established and written down.
| Weakness | Size | Cause and lever |
|---|---|---|
| QUIC vs ngtcp2 | 1.05× / 1.38× | copying on receive vs zero-copy hand-off; the lever is known and the work is planned |
| HTTP/2 header encoding | 70 % | analysed step by step, seven changes already gained; the rest is measured |
| HTTP/3 encoding | 82 % | same cause as HTTP/2 |
| Allocator vs tcmalloc | 7–15 % | the price of predictability and fault-address analysis; jemalloc and system allocators beaten everywhere |
| Regex compilation | 0.44 of PCRE2 | a one-off operation outside the hot path; the price of two programs — forward and reverse — and deeper analysis of the expression |
How the risks are covered: 6,091 tests on each of twelve systems, runs under memory and undefined-behaviour sanitizers, fuzzers on protocol and data parsing, and a log of deliberate decisions where every departure from the obvious is recorded with its reasoning and pinned by a test.
Five kernel mechanisms behind one contract
| System | Engine | Architecture |
|---|---|---|
| Astra Linux, Alt Linux | epoll / io_uring | x86-64 |
| Debian, Ubuntu, Fedora, openSUSE, Alpine | epoll / io_uring | x86-64 · ARM64 |
| macOS | kqueue | x86-64 · ARM64 |
| FreeBSD, NetBSD, OpenBSD | kqueue | x86-64 · ARM64 |
| DragonFly BSD | kqueue | x86-64 |
| Solaris 11.4, OpenIndiana | event ports | x86-64 |
| OpenWRT (musl) | epoll | x86-64 |
| Windows · MSVC and MinGW | IOCP | x86-64 · ARM64 |
| iOS, Android | kqueue / epoll | ARM64 |
| Elbrus Linux 8.1 | epoll / io_uring | e2k · port in progress |
Application code does not depend on the system. Five different kernel mechanisms — kqueue, epoll, io_uring, event ports and IOCP — sit behind one contract: porting to a new system means a new engine at the bottom, not a rewrite of the product.
- Works in isolation. Neither the build nor the runtime needs internet access or external repositories.
- Long product life. Rare and old systems without rewriting application code.
- Process cluster, even on Windows. The master accepts connections and hands them to workers.
- Static and shared builds — one CMake option.
The Elbrus port is under way, and the results are already good
Russian platforms get first-priority support, and AWH is now being ported to Elbrus-8C2 (Elbrus Linux 8.1, lcc compiler). The memory allocator, fibers and system modules already run, and the regular-expression code generator speaks the e2k instruction set.
The PCRE2 reference has no machine code for Elbrus at all and cannot get any: its code generator doesn't know the architecture. So on Elbrus our machine code is compared with its interpreter — and beats it almost everywhere.
| Comparison on Elbrus-8C2 | Result |
|---|---|
| Our machine code vs PCRE2 | ahead in 39 of 41 scenarios, 6.6× at the median |
| Interpreter vs interpreter | ahead in 22, level in 23, behind in none; median 1.36 |
| Best rows with code | up to 34× faster than the reference |
Cryptography follows the same path: A-NTS on Elbrus already runs in full and is several times faster than OpenSSL in places.
What is built on AWH
Ready to assemble today
- Web server and API gateway — HTTP/1, HTTP/2, HTTP/3 and QUIC
- Load balancer — cluster and hand-off of accepted connections
- VPN and secure tunnels — TUN devices, SCTP, QUIC
- Proxy server — SOCKS5 included
- Network services — our own DNS, NTP, ICMP, portmap
Next step
- Content delivery node on our own HTTP/3
- Message broker on our own transport
- Traffic and log analysis — regex and Grok
- Industrial telemetry gateway
- Embedded devices
Already being built
- ACU — format conversion
- AWF — web project platform
- ABS — backup
- Crisper's smart container
- A-NTS — will replace BoringSSL
Separate pages on parts of AWH
awh::alloc
Takes over memory allocation for the whole process, lock-free fast path, fault address analysis, guard pages and a secrets store.
awh::regex and Grok
Five execution strategies, machine code generation, a store of compiled expressions and log parsing.